Ocprop

[teiling88]

Hallo,

wie der eine oder andere mitbekommen hat, ist das Entwicklerteam fleißig dabei den Quellcode neu zu strukturieren um den Weg für ein Responsive Webdesign zu ebnen. Dabei ist uns aufgefallen das viel Quellcode verwaltet wird um das Tool Ocprop zu unterstützen. Daher die Frage - Wer nutzt alles Ocprop? Und kann man darauf verzichten?

Viele Grüße
Thomas

[mic@]

Dabei ist uns aufgefallen das viel Quellcode verwaltet wird um das Tool Ocprop zu unterstützen.

Nanu, ich dachte bisher, ocprop simuliert die Eingaben. Aber das unser Code da schon extra
ocprop-Anteile hat, wundert mich doch sehr. Falls dem so ist, würde ich sagen "weg damit".
Auf ocprop braucht man jedenfalls keine Rücksicht zu nehmen. Schliesslich gibt es ja inzwischen
den cmanager, der 1000x schneller und eleganter arbeitet als ocprop.

[following]

Dabei ist uns aufgefallen das viel Quellcode verwaltet wird um das Tool Ocprop zu unterstützen.

Das täuscht. Im Quellcode sind nur alle Stellen markiert, die (auch) von Ocprop genutzt werden.

Von den Ocprop-Nutzern dürfte kaum jemand hier im Forum mitlesen. Laut Webserver-Logfiles haben heute vier verschiedene User Ocprop laufen lassen, gestern fünf und vorgestern auch fünf. Im gleichen Zeitraum haben zwei User den cmanager genutzt.

Auf ocprop braucht man jedenfalls keine Rücksicht zu nehmen. Schliesslich gibt es ja inzwischen
den cmanager, der 1000x schneller und eleganter arbeitet als ocprop.

Der cmanager kann weder Listings abgleichen noch Logbilder. Wenn man Ocprop über Bord wirft, wird es weniger Bilder und mehr ungewartete Doppellistings geben (und damit auch mehr Arbeit für das Datenpflege- und das Supportteam).

Welches von beiden eleganter ist ist Geschmackssache. Bei cmanager muss man jedes kopierte Log einzeln bestätigen, weil er eine Heuristik verwendet die sich irren kann. Ocprop stützt sich nur auf die OC-Wegpunktdatenbank und läuft daher vollautomatisch (mit geringerer Kopierquote).

Dies bitte nur als Argumente für die Diskussion verstehen, was auch immer letztendlich entschieden wird.

[teiling88]

Dabei ist uns aufgefallen das viel Quellcode verwaltet wird um das Tool Ocprop zu unterstützen.

Das täuscht. Im Quellcode sind nur alle Stellen markiert, die (auch) von Ocprop genutzt werden.

Das mag sein - das ändert aber nichts daran das wir, so wie ich das interpretiere die Seiten- und Formularstruktur nicht "verändern" dürfen damit dieses Tool weiterhin funktioniert oder?

[ClanFamily (Mirco)]

Von den Ocprop-Nutzern dürfte kaum jemand hier im Forum mitlesen. Laut Webserver-Logfiles haben heute vier verschiedene User Ocprop laufen lassen, gestern fünf und vorgestern auch fünf. Im gleichen Zeitraum haben zwei User den cmanager genutzt.

Kannst Du mir den Suchstring verraten? Piwik schweigt sich dazu aus. Wir wollten das im Vorfeld nämlich auch schon mal nachvollziehen.

[SammysHP]

Ich bin ein ocprop Nutzer, allerdings nur rund 4x im Jahr. Doppellistings logge ich i.d.R. immer sofort, aber es kommt häufiger vor, dass nachträglich Listings nach OC dupliziert wurden. Mit cmanager hatte ich bislang keine guten Erfahrungen, er hat vieles übersehen und "vergisst" die Bilder. Die Heuristik von ocprop ist schon ziemlich gut gewesen, da konnten sich die Caches deutlich voneinander unterscheiden, auch in den Koordinaten, und wurden trotzdem gefunden.

Allerdings muss ich als geolog/ocprop-Maintainer für Arch Linux sagen, dass beide Programme tot sind, seit Jahren nicht weiterentwickelt wurden und regelmäßig für Probleme sorgen (Abhängigkeiten, Änderungen bei gc.com). Meine Empfehlung ist daher, auf ocprop keine Rücksicht zu nehmen, wenn die Änderungen wirklich Vorteile bringen. Ich würde die Pakete dann aus dem Repository nehmen.

Bei cmanager muss man jedes kopierte Log einzeln bestätigen, weil er eine Heuristik verwendet die sich irren kann. Ocprop stützt sich nur auf die OC-Wegpunktdatenbank und läuft daher vollautomatisch (mit geringerer Kopierquote).

Hast du die beiden Programme eventuell verwechselt? Dachte, das ist genau anders herum.

[following]

Das mag sein - das ändert aber nichts daran das wir, so wie ich das interpretiere die Seiten- und Formularstruktur nicht "verändern" dürfen damit dieses Tool weiterhin funktioniert oder?

Verändern kann man alles. Wenn es eine Stelle betrifft, die auch von Ocprop genutzt wird - das betrifft ein paar Promille des OC-Programmcodes - muss man ggf. einen Ocprop-Workaround einbauen.

- Templates / Seitenlayout / CSS: Hier gibt es nur wenige Ocprop-Abhängigkeiten (ca. 15 HTML-Codezeilen). Dort schreibt man notfalls den von Ocprop erwarteten Content in einen HTML-Kommentar.

- search.php: Muss bei den Parametern ohnehin 100% abwärtskompatibel bleiben, also Ocprop stört nicht weiter.

- log.php / editlog.php: Hier gibt es keinen Bedarf für eine Umstrukturierung der Formularparameter; log.php wurde auch schonmal komplett neugeschrieben, ohne dass Konflikte mit Ocprop entstanden.

Bleiben noch die übergebenen Parameter für newcache / editcache / newdesc / editdesc. Da müsste man Arbeit in Ocprop-Workarounds investieren bzw. alten Code mitschleppen, falls man die die Logik dieser Seiten überarbeiten möchte.

Kannst Du mir den Suchstring verraten? Piwik schweigt sich dazu aus. Wir wollten das im Vorfeld nämlich auch schon mal nachvollziehen.

Ocprop/2.22 (MSWin32)
Ocprop/2.21 (MSWin32)
Ocprop/2.21 (linux)
Ocprop/2.21 (darwin)
Ocprop/2.20 (MSWin32)
Ocprop/2.18 (linux)

@SammysHP
Da hatte ich was falsch in Erinnerung. Ocprop arbeitet tatsächlich sehr ähnlich wie cmanager. Trotzdem dürfte cmanager in der aktuellen Version eine höhere Zuordnungsquote haben, weil er zusätzlich zur eigenen Heuristik die gewartete Wegpunktdatenbank des OC-Teams nutzt. Die Logbilder könnte man beim cmanager noch nachrüsten.

Bleibt also der Abgleich von Listings - hier gibt es keine Alternative zu Ocprop. Wenn man den alten Ocprop-Zopf abschneidet, geht diese Möglichkeit verloren.

[Slini11]

Die Logbilder könnte man beim cmanager noch nachrüsten.

Das sollte ja jetzt per Okapi klappen, oder?

[teiling88]

- search.php: Muss bei den Parametern ohnehin 100% abwärtskompatibel bleiben, also Ocprop stört nicht weiter.

Wovon wird die search.php denn noch verwendet?

[Slini11]

search.php ist eines der zentralen Elemente (wenn nicht DAS)  von OC und unser großer Vorteil gegenüber GCcom.

Darauf basiert die Suche: https://www.opencaching.de/search.php
Darauf basieren wiederum PocketQueries.
Alle Listen, die angezeigt werden, basieren auf der search.php...auch die Cachelisten.

[following]

- search.php: Muss bei den Parametern ohnehin 100% abwärtskompatibel bleiben, also Ocprop stört nicht weiter.

Wovon wird die search.php denn noch verwendet?

Überall wo Suchen verlinkt wurden. In Cachebeschreibungen, in Forenbeiträgen ...

Außerden landen die Suchparameter fast 1:1 in gespeicherten Suchen (davon gibt es aktuell 8883 Stück), also sie müssen alle weiter ausgewertet werden.

[Bananeweizen]

Aus Sicht eines (unbeteiligten) Software-Architekten lautet meine Antwort: OCDE hat eine stabile und bereits längere Zeit existierende API, nämlich OKAPI. Es ist deshalb objektiv unsinnig, eine zweite API zu haben, die

• technisch deutlich komplexer ist (HTML, Session state, Cookies, HTTP Authentication etc. versus XML, Okapi etc.)
• funktional wesentlich eingeschränkter ist als OKAPI
• Weiterentwicklungen der eigentlichen Funktionalität der Webseite behindert

Wenn man jetzt mal aufräumt, dann

• müssen (zukünftige) Kern-Entwickler nicht mehr wissen, dass es dieses obskure API gibt
• und können es deswegen auch nicht versehentlich kaputt machen
• forciert man die Entwicklung eines anderen/besseren Tools auf Basis des OKAPI
• hat man auf lange Sicht mehr begeisterte Nutzer dieser besseren Tools als man jetzt (wenige) Nutzer des veralteten Tools hat

Strategisch gesehen ist die Entscheidung deshalb aus meiner Sicht sehr klar. Ich weiß selbst, dass man als Entwickler nur ungern Code wegschmeißt, an dem man beteiligt war. Aber da muss man dann mal bewusst den Entwickler-Hut absetzen und den Architekten-Hut stattdessen aufsetzen (und das aus Sicht dieser Rolle betrachten).

[4_Vs]

Aus Sicht eines (unbeteiligten) Software-Architekten lautet meine Antwort: OCDE hat eine stabile und bereits längere Zeit existierende API, nämlich OKAPI. Es ist deshalb objektiv unsinnig, eine zweite API zu haben, die

• technisch deutlich komplexer ist (HTML, Session state, Cookies, HTTP Authentication etc. versus XML, Okapi etc.)
• funktional wesentlich eingeschränkter ist als OKAPI
• Weiterentwicklungen der eigentlichen Funktionalität der Webseite behindert

Wenn man jetzt mal aufräumt, dann

• müssen (zukünftige) Kern-Entwickler nicht mehr wissen, dass es dieses obskure API gibt
• und können es deswegen auch nicht versehentlich kaputt machen
• forciert man die Entwicklung eines anderen/besseren Tools auf Basis des OKAPI
• hat man auf lange Sicht mehr begeisterte Nutzer dieser besseren Tools als man jetzt (wenige) Nutzer des veralteten Tools hat

Strategisch gesehen ist die Entscheidung deshalb aus meiner Sicht sehr klar. Ich weiß selbst, dass man als Entwickler nur ungern Code wegschmeißt, an dem man beteiligt war. Aber da muss man dann mal bewusst den Entwickler-Hut absetzen und den Architekten-Hut stattdessen aufsetzen (und das aus Sicht dieser Rolle betrachten).

+1

[following]

Man kann Ocprop nicht via OKAPI ersetzen, weil man per OKAPI keine Listings hochladen kann. Das in die OKAPI einzubauen wäre sehr kompliziert und wird in den nächsten Jahren sicher nicht kommen, wenn überhaupt.

Ocprop weg => automatischer Listingabgleich weg. Kann man ja in Kauf nehmen, nur bitte bewusst und nicht versehentlich und dann nachher doof dastehen weil man's übersehen hat.

• Weiterentwicklungen der eigentlichen Funktionalität der Webseite behindert
• müssen (zukünftige) Kern-Entwickler nicht mehr wissen, dass es dieses obskure API gibt
• und können es deswegen auch nicht versehentlich kaputt machen

Das trifft eher auf die OKAPI zu als auf die von Ocprop genutzte "API". Die Abhängigkeiten von Ocprop sind relativ gering und sehr gut dokumentiert. Die Verquickungen mit der OKAPI sind groß und undokumentiert. Die Redundanzen zwischen Ocprop-spezifischem und allgemeinem OC-Code liegen in der Größenordnung von einem dutzend Codezeilen; bei der OKAPI ist es eine vierstellige Zahl von Codezeilen.

Also mit diesem Argument müsste man eher die OKAPI rauswerfen. Oder das OC-Backend rauswerfen und durch die OKAPI ersetzen - aber dafür ist die OKAPI noch zu unvollständig.

[hjoe]

Hallo,
ich verstehe nicht viel von Eurer Diskussion, nur soviel, was die Frage zur Nutzung von betrifft OCprop.
Ich habe schon vor einiger Zeit ein kleines Skript nach jedem Caching Tag laufen das geolog.pl und ocprop.pl aufruft.
Da ich in letzter Zeit aber immer einen Doppelfund auf der jeweiligen Web Site Logge, bzw mit c:geo, benötige ich OCprop eigentlich nicht.
Nur auf geolog möchte ich ungern verzichten, wegen der schönen Statistik.

Heinz