Änderung im Dateiformat

[greiol]

vollständig wird das ohnehin nicht, da wir von den alten größen auf die erste variante der v2 größen schon information verloren haben.

Welche sollen das denn sein? Wenn noch was fehlt, ist das zwar bedauerlich, aber kein Grund, dafür noch weitere Informationen zu schludern.

das betraf einige informationen aus dem bereich unterschiedlicher nicht physischer "behälter" bei gc.com.

cw konnte damit nie richtig umgehen, aber das war schlimmstenfalls ein anzeige fehler. virtuals wurden z.b. immer als extra large dargestellt - im archiv dürfte sich ein beitrag von mir dazu finden.

mit dem ummappen auf die zahlenwerte wurde alles was cachewolf nicht explizit kannte auf einen catch-all-wert zusammen gezogen. den kann man aber nicht mehr sauber zurück rechnen und spätestens beim gpx export merkt man das auch (vermutlich aber auch nur da).

deswegen ist die liste der cachegrößen nun ein oder zwei einträge länger als vorher. das zusammenfassen auf fallbacks war auch der grund weshalb ich so für explizite mappings mit exceptions gekämpft habe. sonst merkt man einfach nicht, dass da etwas fehlt (und catch (Exeption ex) {} haben wir auch noch mehr als genug wie ich feststellte als ich mich fragte warum meine exeptions nicht auftauchen obwohl sie mit sicherheit ausgelöst wurden. das macht die umstellung halt mühsam.

bevor wir die versionsnummer nochmal erhöhen, würde ich gerne durch schauen ob wir so etwas noch irgendwo haben. und gleichzeitg die chance nutzen der einen oder anderen klasse etwas mehr struktur zu geben (als ich auf "String s = wildes konstrukt;" stieß schien mir potential vorhanden).

 

[greiol]

ach ja, ich würde den "rückwärtscode" übrigens gnadenlos nach einer generation rauswerfen (spätestens aber nach zwei). so lange würde ich ihn gerne als deprecated im jeweiligen objekt lassen.

 

[MiK]

die Zwischenversionen "fehlerbehaftet" nennen

Fehlerbehaftet war da nix. Euch hat nur der Stil nicht gefallen.

Das habe ich auch nicht behauptet. Deswegen ja auch die Anführungszeichen und "nennen". Ich meinte damit nur, dass wir bzgl. der Nummerierung so tun könnten, als wären es erste unvollständige Schritte des Wechsels zu einem neuen Format.

Aber wenn Du darauf bestehst, kann ich auch mit "Version 3" leben.

In Anbetracht meiner ersten Bemerkung in http://www.geoclub.de/viewtopic.php?p=535449#p535449: Ja.

Meiner Meinung nach spielt es keine Rolle, ob man seine Meinung zu einer Codeänderung vor oder nach einem SVN-Commit abgibt. Außerdem sagt niemand, dass eine Formatumstellung innerhalb eines SVN-Commits geschehen muss. Sowas kann auch mal länger dauern. Die Tatsache, dass wir NBs anbieten, ändert daran gar nichts.

und diesen Umwandlungscode (2->3) sparen.

Der Umwandlungscode 2->3 umfasst derzeit 5 Zeilen, ausgelagert in die dafür gedachte Legacy-Klasse.

Wie viele Zeilen es genau sind und wo der Code liegt, ist mir eigentlich nicht so wichtig. Ich halte es nur für unnötig, dass beim Einlesen dieser Fall noch unterschieden werden muss.

Aber wenn Dir so viel an dieser Zwischenversion liegt, können wir sie gerne weiter unterstützen.

 

[greiol]

ein paar wünsche/anregungen formatänderungen hätte ich noch für v3:
- profil: die bit felder im filter als zahl speichern, denn intern wird ohnehin direkt in einem bitmaske umrechnet
- profil: SPIDERGC erweitern um attribute für maxlogsspidern, tbspidern, beimspidernaktualisieren erweitern und die einstellung profilbasiert statt global zu speichern (diese einstellungen in einem reiter Einstellungen/Profil zusammen führen). tbspidern und beimspidernaktualisieren könnten da der anfang eines boolfiled sein, dann bleibt auch raum für weitere on/off ohne dass wir wieder ans profil müssen
- version als attribut des haupttags statt als eigene tag

 

[Engywuck]

Aber wenn Dir so viel an dieser Zwischenversion liegt, können wir sie gerne weiter unterstützen.

Gut, ich werde dann mal auf Version 3 umstellen. Ob man dann Version 2 unterstützt oder einfach so tut, als sei Version 2 das gleiche wie Version 3 (also keine gesonderte Unterstützung), sei erstmal dahingestellt. Aber man hat dann zumindest die Möglichkeit, die alte Version zu unterstützen - dieser Möglichkeit beraubt man sich, wenn man jetzt einfach anderen Inhalt mit der gleichen Versions-ID wegschreibt.
Die Versions-ID ist ja gerade dazu gedacht, unterschiedliche Inhalte kenntlich zu machen, und ob die Version jetzt 2, 3, 17 oder 512 heisst, ist inhaltlich ja völlig wurscht. Und - unabhängig davon, wieviel das offizielle Build von Version 2 unterstützt - bei mir wird es sowieso eine Version geben, die das kann. Insofern ists mir nicht ganz so wichtig, dass der offizielle Build das auch kann. Aber der Möglichkeit dazu will ich nicht beraubt werden.

Gruß,
E.

 

[Engywuck]

ach ja, ich würde den "rückwärtscode" übrigens gnadenlos nach einer generation rauswerfen (spätestens aber nach zwei). so lange würde ich ihn gerne als deprecated im jeweiligen objekt lassen.

Was ist denn für Dich eine Generation?

Und ich finde es deutlich hässlicher,

• Rückwärtscode an mehreren Stellen im System zu verteilen (CacheType, CacheSize, CacheDiffTerr...)
• Methoden einzubauen, die ich im Kontextassist angeboten bekomme, obwohl ich sie nicht verwenden sollte
• mit deprecated extra Stellen einzubauen, die Warnings liefern

anstatt den Code in einer Klasse zu sammeln, die dann (wenn der Code - was normalfall sein sollte - nicht aufgerufen wird) noch nicht einmal geladen wird. In verwendeten Objekten dagegen wird der Code auf jeden Fall geladen.

Gruß,
E.

 

[greiol]

generation:
wenn ich mal uneterstelle, dass zwei ein zwischenformat ist (darüber kann man sicherlich streiten, aber das werde ich jetzt hier nicht tun), beuetet eine generation für mich, dass der support für das einlesen von version 1 mit dem erscheinen von version 4 verschwinden sollte.

deprecated oder auslagern:
nach meinem verständnis ist das markieren von klassen oder methoden als deprecated der für java vorgesehen weg veraltete dinge zu kennzeichnen und sollte java entwicklern bekannt sein. in solchen fällen gehöre ich zu den leuten die sich lieber an den bestehenden sparchstandard halten, als einen neuen zu erfinden der dann erst mal dokumentiert und auch der nächsten generation von bearbeitern vermittelt werden müsste.

 

[MiK]

- profil: SPIDERGC erweitern um attribute für maxlogsspidern, tbspidern, beimspidernaktualisieren erweitern und die einstellung profilbasiert statt global zu speichern (diese einstellungen in einem reiter Einstellungen/Profil zusammen führen).

Diese drei Einstellungen haben alle direkt Einfluss darauf, wie aufwendig das Spidern ist, Deswegen würde ich sie auf dem PDA anders setzen als am PC. Dies geht allerdings nur, wenn sie global in der pref.xml gespeichert werden. Profilbasiert würde ich es nur unterstützen, wenn ich es direkt beim Spidern noch Umstellen kann (in dem kleinen Dialog der dabei erscheint). Wenn ich dazu in die Einstellungen muss, übersehe ich es bestimmt, wenn ich mal mobil spidern muss.

Allerdings sehe ich auch keinen Grund, warum man diese Einstellungen in verschiedenen Profilen unterschiedlich handhaben möchte. Die einzige Ausnahme wäre ein Funde-Profil. Aber auch hier wäre ich eher für eine Lösung, die immer beim Spidern/Aktualisieren fragt, als dies ins Profil zu verlagern.

 

[greiol]

- profil: SPIDERGC erweitern um attribute für maxlogsspidern, tbspidern, beimspidernaktualisieren erweitern und die einstellung profilbasiert statt global zu speichern (diese einstellungen in einem reiter Einstellungen/Profil zusammen führen).

Diese drei Einstellungen haben alle direkt Einfluss darauf, wie aufwendig das Spidern ist, Deswegen würde ich sie auf dem PDA anders setzen als am PC. Dies geht allerdings nur, wenn sie global in der pref.xml gespeichert werden. Profilbasiert würde ich es nur unterstützen, wenn ich es direkt beim Spidern noch Umstellen kann (in dem kleinen Dialog der dabei erscheint). Wenn ich dazu in die Einstellungen muss, übersehe ich es bestimmt, wenn ich mal mobil spidern muss.

ich checks heute abend ein

Gut. Und machen wir das als generellen Schalter in die Prefs oder profilabhängig wie z.B. Radius. Ich würde eher zweiteres wählen. Dann kann man es in normalen Profilen aktiv lassen und im Found-Profil deaktivieren.

würdest du dich bitte entscheiden ? das zweite zitat stammt aus http://www.geoclub.de/viewtopic.php?f=40&t=33965 da wollte ich den schalter für tbs global einbauen.

Allerdings sehe ich auch keinen Grund, warum man diese Einstellungen in verschiedenen Profilen unterschiedlich handhaben möchte. Die einzige Ausnahme wäre ein Funde-Profil. Aber auch hier wäre ich eher für eine Lösung, die immer beim Spidern/Aktualisieren fragt, als dies ins Profil zu verlagern.

die nächste Ausnahme wäre ein Hidden Profil.

auf dem pda zu spidern ist mir ehrlich gesagt noch nicht in den sinn gekommen, aber natürlich könnte jemand auch da spidern. andereseits haben wir auch immer mal wieder berichte von usern die für ein profil mal maxlogs auf 9999 stehen hatten weil sie alles wollten und sich dann wundern warum das spidern generell so langsam ist, cw stehen bleibt etc. wobei sie die umstellung "mal für das eine profil" schon längst vergessen haben.

könntest du evtl. so einen "erinnerungsdialog" mit änderungsmöglichkeit beisteuern?

 

[MiK]

Man könnte auch zwei getrennte globale Einstellungen andenken. Einmal für das Umkreis-Spider und einmal für das Funde-Spidern. Allerdings will man ja im Funde-Profil auch aktualisieren. Soetwas würde dann nur gehen, wenn man dem Profil "ansehen" könnte, dass es ein Funde-Profil ist.

Ich weiß, ich habe vor ein paar Tagen noch anders argumentiert, aber mittlerweile bin ich der Ansicht, dass wir Einstellungen, die man nur für den Sonderfall Funde-Profil anders haben möchte nicht profilabhängig machen sollte. Wie man das am besten handhabt, weiß ich selbst noch nicht genau. Die beste Idee, die ich bisher habe ist die kurze Nachfrage direkt vor dem Aktualisieren/Spidern.

 

[MiK]

würdest du dich bitte entscheiden ? das zweite zitat stammt aus http://www.geoclub.de/viewtopic.php?f=40&t=33965 da wollte ich den schalter für tbs global einbauen.

Ja, das habe ich selbst schon gemerkt. Siehe letztes Posting.

Allerdings sehe ich auch keinen Grund, warum man diese Einstellungen in verschiedenen Profilen unterschiedlich handhaben möchte. Die einzige Ausnahme wäre ein Funde-Profil. Aber auch hier wäre ich eher für eine Lösung, die immer beim Spidern/Aktualisieren fragt, als dies ins Profil zu verlagern.

die nächste Ausnahme wäre ein Hidden Profil.

Um ehrlich zu sein, würde ich sowieso sowohl bei Found als auch bei Hidden immer alle Informationen genauso spidern, wie im normalen Profil. Aber ich kann verstehen, dass das jemand evtl. nicht möchte.

auf dem pda zu spidern ist mir ehrlich gesagt noch nicht in den sinn gekommen, aber natürlich könnte jemand auch da spidern. andereseits haben wir auch immer mal wieder berichte von usern die für ein profil mal maxlogs auf 9999 stehen hatten weil sie alles wollten und sich dann wundern warum das spidern generell so langsam ist, cw stehen bleibt etc. wobei sie die umstellung "mal für das eine profil" schon längst vergessen haben.

könntest du evtl. so einen "erinnerungsdialog" mit änderungsmöglichkeit beisteuern?

Was meinst Du damit genau? Den Dialog, der jetzt schon beim Spidern kommt, erweitert um weitere Punkte? Außerdem sollte er auch beim Aktualisieren kommen? Der Dialog ist ja jetzt schon modular. Ich würde ihn dann um weitere Module erweitern, so dass man situationsabhängig das aktivieren kann, was man möchte. Sollten die Änderungen, die man dabei an globalen Einstellungen macht, dann für den nächsten Aufruf gespeichert werden? Ich denke ja.

Wenn wir uns über diese Punkte einig sind, mache ich diesen Dialog gerne. Ich hoffe ich finde am WE die Zeit dazu.

 

[Engywuck]

Ich hätte nichts dagegen, wenn vor dem Spidern ein kleines Fensterchen mit diversen Checkboxen aufgeht - deren Inhalt dann fürs nächste Mal übernommen wird. Ist mit dem Umkreis ja auch so, und das finde ich recht praktisch.

Gruß,
E.

 

[MiK]

Ich hätte nichts dagegen, wenn vor dem Spidern ein kleines Fensterchen mit diversen Checkboxen aufgeht - deren Inhalt dann fürs nächste Mal übernommen wird. Ist mit dem Umkreis ja auch so, und das finde ich recht praktisch.

Genau so war es gemeint. Wobei ich einige Einstellungen davon profilabhängig und andere global speichern würde. Im Moment gibt es darin auch zwei Punkte (Bilder und bereits gefundene Caches), die immer hart vorbelegt werden. Wollen wir das (teilweise) beibehalten oder auch merken?

Welche Punkte sollten alle rein?
bisher:
- Radius (profilabhängig gespeichert)
- Maximale Anzahl (profilabhängig gespeichert)
- Bilder laden (fest vorbelegt): würde ich zu einer globalen Pref machen
- Funde nicht laden (fest vorbelegt): könnte man fest vorbelegt lassen

neu:
- TBs laden (würde ich global speichern)
- max. Logzahl (wird bisher global gespeichert): Ich bin mir nicht sicher, ob das wirklich hier rein muss. Aber wenn wir nicht an Platzgrenzen stoßen: OK
- Aktualisieren beim Spidern: Ich finde es hier sinnvoller die Option "Nachfragen" zu setzen, als es an dieser Stelle abzufragen. Dann kommt die Frage nur, wenn sie nötig ist und man hat die Anzahl der zu aktualisierenden Caches als Entscheidungshilfe.

 

[Romanese]

Eine Frage zu Thema Founds spidern. Ist es moeglich, dass dabei nur der eigene Log gespidert wird und nicht die letzten xyz, die man mit max. Log definiert hat?

Wie sieht es mit selbst angelegten Wegpunkten beim sipdern von Founds auf? Wenn ich z.B. einen Multi gefunden habe verschiebe ich den gefunden Cache inklusive Wegpunkte in mein Found-Profil. Bleiben die selbst angelegten Wegpunkte beim spidern unberuehrt?

Viele Gruesse von der Insel.

 

[MiK]

Eine Frage zu Thema Founds spidern. Ist es moeglich, dass dabei nur der eigene Log gespidert wird und nicht die letzten xyz, die man mit max. Log definiert hat?

Um beim Spidern an das eigene Log zu kommen, muss es in der Cache-Seite, die geladen wird vorhanden sein. Wenn Du weniger als 6 Logs eingestellt hast, wird auch nur die Seite mit den letzten 5 Logs geladen. Ansonsten die mit allen Logs. Wenn Du also 6 Logs einstellst, wird Dein Log erfasst, ohne dass übermäßig andere Logs gespeichert werden. Allerdings erscheint Dein Log bisher dann nicht unbedingt im LogPanel sondern bisher nur beim GPX-Export.

Wie sieht es mit selbst angelegten Wegpunkten beim sipdern von Founds auf? Wenn ich z.B. einen Multi gefunden habe verschiebe ich den gefunden Cache inklusive Wegpunkte in mein Found-Profil. Bleiben die selbst angelegten Wegpunkte beim spidern unberuehrt?

Selbst angelegte Wegpunkte und eingefügte Koordinaten bleiben unangetastet. Ausnahme: Es gibt jetzt einen "offiziellen" Wegpunkt mit diesem Namen und mit gesetzten Koordinaten. Dann werden die eigenen Werte überschrieben.

PS: Eigentlich gibt es für Fragen zu dieser Funktion einen eigenen Thread.

 

[huzzel]

Frage:

ist es Absicht, dass bei der neuen Version bei

 <CACHE  name =

zwischen

CACHE

und

name

jetzt 2 Leerzeichen sind?
Wenn ja, bleibt das so?

 

[MiK]

Willst Du Deinen Code wirklich davon abhängig machen, ob in einer XML-Datei irgendwo mehr oder weniger Leerzeichen sind?

 

[huzzel]

Ich habs jetzt mit einer IF-Abfrage mehr gelöst, aber ja, ich gehe doch davon aus, das ein XML-Gerüst statisch ist

 

[greiol]

Ich habs jetzt mit einer IF-Abfrage mehr gelöst, aber ja, ich gehe doch davon aus, das ein XML-Gerüst statisch ist

in einem xmlgerüst dient whitespace zwischen elementen oder attributen bestenfalls der lesbarkeit. im moment haben wir unter ästhetischen gesichtspunkten noch ein paar leerzeichen zu wenig dafür an anderer stelle halt mehr

a="b", a = "b", a= "b" und a ="b" sind alle gültig und sollten erkennt werden können.

egal mit welcher sprache du auf die cw rohdaten zugreifst, sollte die sprache direkt mit xml umgehen können, wäre das eine möglichkeit die du ernsthaft in betracht ziehen solltest.

 

[Engywuck]

Im moment haben wir unter ästhetischen gesichtspunkten noch ein paar leerzeichen zu wenig.

Vorsicht... Bei EWE muss man immer auch an die Ressourcen denken. Unnötige Leerzeichen sollten wir eliminieren, weil es die Ladezeit der Datei und das Suchen in der Daten nach den Anführungszeichen verkürzt.

Gruß,
E.