• Willkommen im Geoclub - dem größten deutschsprachigen Geocaching-Forum. Registriere dich kostenlos, um alle Inhalte zu sehen und neue Beiträge zu erstellen.

[DEV] Stiefmütterliche Behandlung von Opencaching

jennergruhle

Geoguru
Hi ihr Entwickler,

ich habe den Eindruck, dass der Download von OC recht stiefmütterlich behandelt wird.

Beim OC-Download wird keine Option "Gefundene ausblenden" angezeigt. Aber wenn ich den Code so anpasse, dass die Option eingeblendet wird, funktioniert sie auch, ansonsten bekomme ich immer alle gefundenen und eigenen mit. Was ist die Absicht dahinter?

Wenn niemand anderes hier momentan dran zugange ist, würde ich mir das jetzt mal vornehmen. Es scheint auch, dass oft (wenn nicht sogar in letzter Zeit *immer*) die Beschreibung leer bleibt.

Ciao
jennergruhle
 

TweetyHH

Geomaster
Die Aussage beruhigt mich ... beim Refaktoren für den CacheHound hatte ich genau die Probleme und hatte es erst auf Änderungen von uns geschoben.

Es lag daran, dass das CacheHolderDetail-Objekt zu früh erzeugt wurde, so dass es nicht in die Liste der geladenen CacheHolderDetails aufgenommen wurde ... evtl. könnt ihr bei uns im Code nachschauen, wie ich das gelöst hab.
 

pfeffer

Geowizard
Ich verwende eigentlich regelmäßig opencaching - ok, die letzte Zeit habe ich mich als Internetausdrucker geübt... Also mich wundert sehr, dass da ein Fehler drin ist.
Ich vermute: http://svn.berlios.de/wsvn/cachewolf/?rev=1748&sc=1 als Ursache.

Wäre super, wenn Du das beheben würdest!

(was ich außerdem klasse fände, wäre opencaching.pl, .cz und .org.uk einzubinden. Dann kann man mit CW perfekt OPENcaching machen: opencaching-Datenank, OpenStreetMap als Kartendienst und Cachewolf als GPL-Software :) - ok was dann noch fehlen würde, wäre Geokrety... aber schön eins nach dem anderen).

Gruß,
Pfeffer.
 

pfeffer

Geowizard
OSM-Diskussion abgetrennt nach http://www.geoclub.de/viewtopic.php?f=40&t=37629

Gruß,
Pfeffer.
 

Wutschkow

Geomaster
Das mit der leeren Beschreibung kann ich bestätigen. Ist mir letztens auch passiert (und ich benutze OC nicht gerade häufig). Ich dachte, ich hätte es selbst irgendwie verbockt und habe mich gefragt, wie nur? :D

Stichwort "Stiefmütterlich":
Irre ich mich eigentlich, oder kommt beim Aktualisieren eines OC-Caches immer auch der Dialog für GC hoch. Also auch dann, wenn man nur den einen OC-Cache markiert hat. Ich kriege da immer erst den Dialog wie üblich beim Aktualisieren von GC und dann gleich noch den für OC? Das muss doch vermutlich auch nicht unbedingt sein, oder?
 
OP
jennergruhle

jennergruhle

Geoguru
OK, dann hab ich schon mal ne Idee für die Herangehensweise. Für weitere OC-Domänen müsste man aber vermutlich auch weitere Anmeldungen speichern, oder? Die teilen sich offenbar (noch) nicht die Nutzer-Logins.
Ich fürchte nur, dass der aus allen Nähten platzende Konfigurationsdialog dann noch mehr überfrachtet wird...
Naja, zuerst werd ich's wohl nur manuell in die Konfig schreiben, ohne Dialogverknüpfung.
Ich geh mich erstmal überall registrieren...
 

pfeffer

Geowizard
:)
vielleicht als erstes OC.de reparieren und einchecken, damit wir wieder cachen können :)

Ich habe vor ein paar Tagen im OC.pl Forum einen Thread gestartet: http://forum.opencaching.pl/viewtopic.php?p=64462
Vielleicht ist das auch ein Thema für das internationale Entwicklerforum von Opencaching: http://forum.opencaching.eu/index.php

opencaching.de braucht keinen Nutzernamen/Passwort zum Abruf der Daten über XML, ich weiß nicht, wie das in Polen ist.

Gruß,
Pfeffer.
 
OP
jennergruhle

jennergruhle

Geoguru
pfeffer schrieb:
opencaching.de braucht keinen Nutzernamen/Passwort zum Abruf der Daten über XML, ich weiß nicht, wie das in Polen ist.
Achja klar, man muss nur den OC-Namen im CW hinterlegen, damit er weiß, wer man ist (eigene Caches ausblenden).
 
OP
jennergruhle

jennergruhle

Geoguru
OK, ich habe schon mal herausgefunden:

die erzeugte URL für den Download der Datei zu einem Cache, z.B.
Code:
http://www.opencaching.de/xml/ocxml11.php?modifiedsince=20090806174449&cache=1&cachedesc=1&picture=1&cachelog=1&removedobject=0&wp=OC88D4&charset=utf-8&cdata=0&session=0
enthält einen Timestamp (modifiedsince=20090806174449) für die Zeit, ab der man Änderungen haben will. Ist der Cache in der DB aber korrupt, ändert sich das nie wieder (es sei denn der Owner bearbeitet den gleich mal), weil OC keine neuen Daten liefert, weil sich seitdem nix geändert hat.
Man müsste also erkennen, dass man einen "leeren" bzw. kaputten Cache in der DB hat, damit der Timestamp auf 2005 oder so gesetzt wird und ein Download auf jeden Fall wieder neue Daten liefert.
 
OP
jennergruhle

jennergruhle

Geoguru
Es wird noch verrückter: Für diesen Cache habe ich gar kein File...
Es gibt einen gleichnamigen GC-Cache zum OC-Cache, aber keine OC-Datei (habe nach Inhalten gesucht), nur die GC-Datei gc1qfc5.xml. Kann es sein, dass der OC-Inhalt doch aus der GC-Datei mitgenommen wird?
Bei einem OC-Only-Cache habe ich dies Phänomen nicht beobachtet, hier gibt es eine XML-Datei mit passendem Inhalt, und alle Informationen sind fehlerfrei vorhanden.
 

pfeffer

Geowizard
jennergruhle schrieb:
enthält einen Timestamp (modifiedsince=20090806174449) für die Zeit, ab der man Änderungen haben will. Ist der Cache in der DB aber korrupt, ändert sich das nie wieder (es sei denn der Owner bearbeitet den gleich mal),
Dafür gibt es die Option "alle neu laden" (oder so). Evtl. könnte man das automatisch machen, wenn Cachewolf erkennt, dass er korrpute OC-Caches hat.
Aber eigentlich würde ich sagen, muss das nicht autoamtisch, schließlich sollten normalerweise keine Caches korrupt sein.

Gruß,
Pfeffer.
 

pfeffer

Geowizard
jennergruhle schrieb:
Es wird noch verrückter: Für diesen Cache habe ich gar kein File...
Es gibt einen gleichnamigen GC-Cache zum OC-Cache, aber keine OC-Datei (habe nach Inhalten gesucht), nur die GC-Datei gc1qfc5.xml. Kann es sein, dass der OC-Inhalt doch aus der GC-Datei mitgenommen wird?
Bei einem OC-Only-Cache habe ich dies Phänomen nicht beobachtet, hier gibt es eine XML-Datei mit passendem Inhalt, und alle Informationen sind fehlerfrei vorhanden.
hmmm - eigentlich sollte es nicht so sein. Es gab aber mal eine Diskussion darüber, ob man nicht OC und GC, die den gleichen Cache beschreiben, nur einmal anzeigt. Ich dachte allerdings, dass die Informationen schon noch getrennt gespeichert würden. Auch dachte ich, dass das nur 1mal anzeigen nicht umgesetzt worden sei, weil wir uns nicht einigen konnten, ob GC oder OC-Beschreibung angezeigt werden sollte und niemand sich dran gesetzt hat und es auswählbar gemacht hat.

Gruß,
Pfeffer.
 
OP
jennergruhle

jennergruhle

Geoguru
Also, einen korrupten Cache neu laden ging jetzt, wenn ich das Häkchen "Alle downloaden" setze. Dann wurde auch die XML-Datei neu angelegt. Das werde ich noch mal testen, ob man hier den Fehler automatisch finden und dann komplett neu laden kann.

Außerdem habe ich die OC-URLs der verschiedenen OC-Domänen statt hartverdrahtet auf oc.de mal variabel gestaltet, mit automatischer Erkennung der Hostnamen anhand der WP-Namen. Habe drei WPs neu angelegt und versucht, neu zu laden, mit sehr durchwachsenen Ergebnissen:

www.opencaching.de: Connect möglich, ein Redirect, dann Ergebnis: ZIP-FIle mit XML drin -> ok.

www.opencaching.pl: Connect ist möglich, aber IOException wegen HTTP-Fehler 403:
URL: http://www.opencaching.pl/xml/ocxml11.php?modifiedsince=20050801000000&cache=1&cachedesc=1&picture=1&cachelog=1&removedobject=0&wp=OP15B1&charset=utf-8&cdata=0&session=0
-> IOException "http response code: 403"
Direkter Abruf der URL im Browser: auch 403.

www.opencaching.cz: Connect möglich, ein Redirect, beim zweiten Connect dann nichtssagende "ewe.io.IOException: Could not connect".
Direkter Abruf der URL
http://www.opencaching.cz/xml/ocxml11.php?modifiedsince=20050801000000&cache=1&cachedesc=1&picture=1&cachelog=1&removedobject=0&wp=OZ016B&charset=utf-8&cdata=0&session=0
im Browser ist möglich, Ergebnis: ZIP-File mit XML drin.

www.opencaching.org.uk: Connect möglich, ein Redirect, beim zweiten Connect dann IOException:
"URL: /download/zip/ocxml11/75522/75522-0-1.zip
http response code: 400"
Direkter Abruf der URL
http://www.opencaching.org.uk/xml/ocxml11.php?modifiedsince=20050801000000&cache=1&cachedesc=1&picture=1&cachelog=1&removedobject=0&wp=OK0050&charset=utf-8&cdata=0&session=0
im Browser ist möglich, Ergebnis: ZIP-File mit XML drin.

Offenbar gibt es also noch Schwierigkeiten - opencaching.pl bockt noch herum, die anderen beiden gehen prinzipiell, aber EWE kann es nicht herunterladen.
Immer von oc.de herunterladen geht natürlich nicht- der kennt ja nur die eigenen Caches, für fremde gibt es eine fast leere Datei zurück.

Hat jemand ne Idee, was ich noch untersuchen könnte? Die fehlschlagende Methode ist in OCXMLImporter die private String fetch(String addr, String fileName ), welche ihrerseits UrlFetcher.fetchByteArray(addr, realurl) aufruft.

Jetzt ist erstmal genug für heute -mal sehen, was ich morgen noch herausfinden kann.
 

pfeffer

Geowizard
.pl:
Die Polen blocken wohl. Ich hoffe, sie heben das auf, schließlich (glaub ich) ist das eine der aktivsten opencaching-communities. Hier habe ich sie grad drum gebeten: http://forum.opencaching.pl/viewtopic.php?p=64331#64331

.cz:
der redirect liefert:
Code:
http://www.opencaching.cz/../download/zip/ocxml11/756/756-0-1.zip
Ich würd' sagen, das haben die nen Fehler: wo soll das "../" denn hinführen?
also: entweder die auf ihren Fehler aufmerksam machen und um Korrektur bitten oder/und Cachwolf toleranter machen. - die richtige redirect adresse ist:
Code:
http://www.opencaching.cz/download/zip/ocxml11/756/756-0-1.zip

.org.uk:
ich weiß nicht, ob es daran liegt: org.uk verwendet http 1.1 mit "keep alive", d.h. erwartet die nächste Anfrage im gleichen Stream. Aber ich denke daran wird es nicht liegen, bestimmt akzeptiert er auch Anfragen in http 1.0 und "connection: close".

Gruß,
Pfeffer.
 
OP
jennergruhle

jennergruhle

Geoguru
pfeffer schrieb:
.cz:
der redirect liefert:
Code:
http://www.opencaching.cz/../download/zip/ocxml11/756/756-0-1.zip
Ich würd' sagen, das haben die nen Fehler: wo soll das "../" denn hinführen?
Eine Ebene höher - also in das Stockwerk über dem Serverraum :)
pfeffer schrieb:
also: entweder die auf ihren Fehler aufmerksam machen und um Korrektur bitten oder/und Cachwolf toleranter machen. - die richtige redirect adresse ist:
Code:
http://www.opencaching.cz/download/zip/ocxml11/756/756-0-1.zip
Am besten beides - ich habe das mal in CW angepasst, so dass /../ in URLs durch / ersetzt wird.
".." hat soviel ich weiß in URLs *NICHTS* verloren. Es sei denn, man ist Skriptkiddie und will alte IIS hacken...

Danke für den Tip, im Eclipse-Debugger habe ich diese URL seltsamerweise nicht sehen können.
Aber nun klappt die Aktualisierung eines oc.cz-Caches.
pfeffer schrieb:
.org.uk:
ich weiß nicht, ob es daran liegt: org.uk verwendet http 1.1 mit "keep alive", d.h. erwartet die nächste Anfrage im gleichen Stream. Aber ich denke daran wird es nicht liegen, bestimmt akzeptiert er auch Anfragen in http 1.0 und "connection: close".
Das habe ich auch noch im Debugger auseinanderklamüsert - es ist so, dass der Redirect eine URI statt einer URL liefert:

http://www.opencaching.org.uk/xml/ocxml11.php?modifiedsince=... -> /download/zip/ocxml11/75603/75603-0-1.zip

Also muss ich den Teil vor der URI aufheben und wenn nötig wieder vor die redirect-URL klatschen.

Code:
			urltmp = conn.getRedirectTo();
			if(urltmp!=null){
				urltmp = urltmp.replaceAll("/\\.\\./", "/");
				URL eweUrl = new URL(url);
				if(urltmp.indexOf(eweUrl.getHost())<0){
					urltmp = new URL(eweUrl.getProtocol(), eweUrl.getHost(),eweUrl.getPort(), urltmp).url;
				}
			}
Jetzt klappt es auch mit OC.org.uk.

Mal sehen was die Polen nun sagen.

Und jetzt muss ich mal beigehn und die Suche entsprechend anpassen, so dass man die vier Domains auswählen kann. Was, meint ihr, ist besser: Vier Menüpunkte oder ein Dropdown im OC-Dialog?
 

pfeffer

Geowizard
wow! es geht voran! - supi!

drop-down in Dialog evtl. je nach Zentrum der richtige Server vorausgewählt.
Wegen der Polen hast Du ne PN.

Mir scheint Deine Unterscheidung zwischen UI und URL nicht ganz klar ( http://de.wikipedia.org/wiki/Uniform_Resource_Identifier ), aber egal, hauptsache, (ich hätte gesagt: relativen Verweis, statt absoluten) es geht :)
Code:
urltmp = urltmp.replaceAll("/\\.\\./", "/");
Führt natürlich daz, dass korrekte relative Verweise, die ".." enthalten, nicht funktionieren. Aber vielleicht muss das an dieser Stelle auch nicht komplett alle denkbaren Varianten behandeln können (schön, wäre es schon, wenn wir es gleich korrekt machen).

Hast Du eigentlich den Bug, weswegen Du den Thread gestartet hast, gefixt?

Gruß,
Pfeffer.
 
OP
jennergruhle

jennergruhle

Geoguru
pfeffer schrieb:
drop-down in Dialog evtl. je nach Zentrum der richtige Server vorausgewählt.
Astreine Idee! Nur im Grenzgebiet D/PL/CZ wirds etwas knifflig...

pfeffer schrieb:
Mir scheint Deine Unterscheidung zwischen UI und URL nicht ganz klar ( http://de.wikipedia.org/wiki/Uniform_Resource_Identifier ), aber egal, hauptsache, (ich hätte gesagt: relativen Verweis, statt absoluten) es geht :)
Jupp, das hab ich falsch ausgedrückt.

pfeffer schrieb:
Code:
urltmp = urltmp.replaceAll("/\\.\\./", "/");
Führt natürlich daz, dass korrekte relative Verweise, die ".." enthalten, nicht funktionieren. Aber vielleicht muss das an dieser Stelle auch nicht komplett alle denkbaren Varianten behandeln können (schön, wäre es schon, wenn wir es gleich korrekt machen).
Also ich meine, ".." sind im Pfad ganz oben unzulässig. Wikipedia meint: "Die Interpretation (Datei oder Verzeichnis; Textdatei liefern oder Skript ausführen) bleibt dem Server überlassen.".
Aber wie schon geschrieben - wohin soll ein ".." im Pfad ganz oben auch führen? Ich könnte aber auch <hostname>/../ durch <hostname>/ ersetzen, dann bleibt es möglich, mit .. zu navigieren.

pfeffer schrieb:
Hast Du eigentlich den Bug, weswegen Du den Thread gestartet hast, gefixt?
Nee, noch nicht - das andere war viel spannender. Aber das betrifft ja alles den OC-Dialog, das mache ich dann gleich in einem Aufwasch.
 

pfeffer

Geowizard
jennergruhle schrieb:
Ich könnte aber auch <hostname>/../ durch <hostname>/ ersetzen, dann bleibt es möglich, mit .. zu navigieren.
gute Idee!

pfeffer schrieb:
Hast Du eigentlich den Bug, weswegen Du den Thread gestartet hast, gefixt?
Nee, noch nicht - das andere war viel spannender. Aber das betrifft ja alles den OC-Dialog, das mache ich dann gleich in einem Aufwasch.[/quote]ok :) Ich meinte eigentlich leere Cachebeschreibung, oder tritt dieses Problem doch nicht auf?


Ich bin total begeistert, wenn wir bald alle OC-Server abfragen können :)

Gruß,
Pfeffer.
 
OP
jennergruhle

jennergruhle

Geoguru
pfeffer schrieb:
ok :) Ich meinte eigentlich leere Cachebeschreibung, oder tritt dieses Problem doch nicht auf?
Also bei mir war es eine fehlende XML-Datei für den Cache, wobei der Cache noch im Index stand. Also nichts, das man nicht auf übliche Weise reparieren könnte - entweder Update mit "Alles neu laden", dann ist er wieder komplett, oder "Index neu erstellen", dann ist er halt weg.

Jetzt guck ich mal nach dem Import von den anderen Servern...
 
Oben