Änderung im Dateiformat

[huzzel]

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.

C

Ich habe noch nicht gesucht, ob da was direkt mit XML geht.
Bis jetzt zerpflücke ich es ganz herkömmlich:
Teilstring finden -> Position merken
Teilstring finden -> Position merken
...
Daten aus den Positionen ermitteln.
Und da tut ein Leerzeichen mehr (oder weniger) weh, weil dann keine Übereinstimmung mehr gefunden wird.

Aber guter Einwand, ich gucke mal, was es da gibt

 

[greiol]

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.

mir würde es schon reichen, wenn wir nicht für jedes leerzeichen mehr oder weniger die versionsnummer hochzählen, denn das verschwendet meine ressourcen

 

[Engywuck]

Das ließe sich machen. Die Versionsnummer sollten wir nur dann hochzählen, wenn sich dadurch für CacheWolf was ändert.

 

[greiol]

 

[MiK]

Das ließe sich machen. Die Versionsnummer sollten wir nur dann hochzählen, wenn sich dadurch für CacheWolf was ändert.

während wir am format arbeiten noch nicht einmal das. diese daily stable ist ein wahnsinn an dem ich mich nach dem aktuellen stand der dinge nicht weiter beteiligen werde.

Ganz ruhig bleiben. Niemand sagt, dass so eine Versionsumstellung an einem Tag oder in einem Commit erfolgen muss. Die Version 2 ist jetzt mal eine Ausnahme um die Wogen zu glätten und weil ich das vorher nicht in aller Deutlichkeit gesagt habe.

Ab jetzt gilt: Wir arbeiten an Version 3 und das bleibt so lange so, bis wir beschließen, dass sie final ist. Und danach gibt es dann ein Release. Wer mit Versionen dazwischen arbeitet wird möglichst daruf hingewiesen, auf was er sich da einlässt.

 

[Engywuck]

virtuals wurden z.b. immer als extra large dargestellt

Ich muss gestehen, dass mich die Containergröße von Virtuals bisher nie so richtig interessiert hat ;-)

Gruß,
E.

 

[greiol]

einlesen "unvollständiger" profile:

aus der arbeit mit den statistiktool habe ich erfahren müssen, dass einige user leider profile haben in denen eigentlich wichtige fahlen. beliebt dafür sind gelände, schwierigkeit und cachegröße. während der konvertierung müssen wir irgendwie darauf reagieren, denn unser ziel ist ja auch wieder konsitente daten zu haben.

wir könnten darauf reagieren indem wir die werte "heimlich" auf einen zulässigen wert mappen mit der gefahr dass die werte dann zwar gültig oder falsch sind oder indem wir den cache erst einmal aus der liste löschen/ignorieren. dann müssten wir den benutzer aber darüber informieren welche caches das sind damit er die neu einlesen kann.

persönlich würde ich es besser finden den cache mit rückmeldung an den benutzer zu entfernen. was meint ihr?

 

[Engywuck]

Wie wäre es, wenn man es ähnlich ahndet wie beim Spidern: Beim Laden wird festgestellt, welche Caches kritisch sind, und es kommt eine Meldung, dass bei x Caches inkonsistente Daten festgestellt wurden und ob man diese jetzt aktualisieren möchte.

Gruß,
E.

 

[greiol]

Wie wäre es, wenn man es ähnlich ahndet wie beim Spidern: Beim Laden wird festgestellt, welche Caches kritisch sind, und es kommt eine Meldung, dass bei x Caches inkonsistente Daten festgestellt wurden und ob man diese jetzt aktualisieren möchte.

ich sehe schon ich spider zu selten. können wir den spider an der stelle in einem "safe mode" starten und unabhängig davon ob der user sonst maxlogs 9999 hat mit 5 arbeiten? damit uns nicht evtl. der spider wegen resourcenverbrauch oder zu großen listings um die ohren fliegt?

 

[MiK]

Also löschen würde ich nichts. Das können ja auch irgendwelche selbst angelegten Caches sein. Ich würde es auf Werte setzen, die Zeigen, dass Daten fehlen. Also bei D/T z.B. auf 0. Bei der Cachegröße würde ich, um keinen speziellen Typ einführen zu müssen, auf "Not chosen" stellen.

Bleibt die Frage, ob man eine Meldung ausgibt und dabei evtl. das Aktualisieren anbietet. Ich halte es eigentlich für unnötig. Es fehlen eben ein paar Daten, die man durch Aktualisieren ergänzen muss. Das war bei der Einführung der Attribute genauso.

Aber falls sich jemand für die einmalige Umwandlung die Arbeit machen möchte: Man könnte auch die Caches, bei denen soetwas festgestellt wurde, einfach nur mit dem Haken markieren und dies melden. Dann kann man entscheiden, ob man sie löscht oder aktualisiert. Hmm... ok... das könnte man auch gleich in dem Dialog anbieten...

 

[MiK]

ich sehe schon ich spider zu selten. können wir den spider an der stelle in einem "safe mode" starten und unabhängig davon ob der user sonst maxlogs 9999 hat mit 5 arbeiten? damit uns nicht evtl. der spider wegen resourcenverbrauch oder zu großen listings um die ohren fliegt?

Ich bin ja eigentlich dafür den Benutzer für einigermaßen mündig zu halten. Sowohl bei der Anzahl der Caches, die er spidert als auch bei der Anzahl der Logs. Besonders, wenn wir diese Zahlen dann noch in dem Vordialog anzeigen, sollten wir das dem User überlassen, was er möchte.

 

[greiol]

ich sehe schon ich spider zu selten. können wir den spider an der stelle in einem "safe mode" starten und unabhängig davon ob der user sonst maxlogs 9999 hat mit 5 arbeiten? damit uns nicht evtl. der spider wegen resourcenverbrauch oder zu großen listings um die ohren fliegt?

Ich bin ja eigentlich dafür den Benutzer für einigermaßen mündig zu halten. Sowohl bei der Anzahl der Caches, die er spidert als auch bei der Anzahl der Logs. Besonders, wenn wir diese Zahlen dann noch in dem Vordialog anzeigen, sollten wir das dem User überlassen, was er möchte.

das können wir machen wobei wir ohnehin darauf reagieren müssen ob der spider alles bekommen hat. was machen wir bei einem fehlschlag?

ich könnte mir folgende beiden varianten vorstellen:

variante a
- spidern mit user setting
- bei einem fehlschag -> aussortieren

variante b
- spidern mit user settings
- bei fehlschlag: spidern mit konservativen settings
- bei fehlschlag: aussortieren

 

[Engywuck]

Was stellst Du Dir unter aussortieren vor?

 

[MiK]

Ich finde, wir sollten es dem User überlassen, ob Caches "aussortiert" werden. Nur weil ein Cache z.B. jetzt Premium-Member-only ist und nicht mehr aktualisiert werden kann, ist das kein Grund ihn rauszuschmeißen.

Ein Cache, bei dem manche Werte nicht richtig erfasst sind, schadet im normalen Betrieb ja auch nicht. Nur für die Statistiken ist es halt blöd. Aber deswegen dürfen wir sie nicht einfach löschen.

Mein Vorschlag (einmalig bei der Konvertierung des Profils):
1. Frage: Es wurden x Caches mit unvollständigen Daten erkannt. Sollen sie a) aktualisiert b) gelöscht c) beibehalten werden?

Im Falle von a) aktualisieren wir und falls es dabei Probleme gibt fragen wir noch mal nach, ob die Problemcaches gelöscht werden sollen oder nicht.

 

[greiol]

Ich finde, wir sollten es dem User überlassen, ob Caches "aussortiert" werden. Nur weil ein Cache z.B. jetzt Premium-Member-only ist und nicht mehr aktualisiert werden kann, ist das kein Grund ihn rauszuschmeißen.

nicht dass wir uns hier falsch verstehen: ein cache dessen basis daten vollständig sind (<CACHE>), darf und wird nie rausfliegen.

Ein Cache, bei dem manche Werte nicht richtig erfasst sind, schadet im normalen Betrieb ja auch nicht. Nur für die Statistiken ist es halt blöd. Aber deswegen dürfen wir sie nicht einfach löschen.

ok, grundsätzlich haben wir dafür das flag isIncomplete. ich lass mir das nochmal zusammen mit meinen letzten checkins durch den kopf gehen.

Mein Vorschlag (einmalig bei der Konvertierung des Profils):
1. Frage: Es wurden x Caches mit unvollständigen Daten erkannt. Sollen sie a) aktualisiert b) gelöscht c) beibehalten werden?

Im Falle von a) aktualisieren wir und falls es dabei Probleme gibt fragen wir noch mal nach, ob die Problemcaches gelöscht werden sollen oder nicht.

löschen hat noch einen weiteren haken. lösche ich den hauptpunkt, müsste ich die addis dazu auch löschen.

frage: macht es sinn die incomplete caches "zu komplettieren"? wir müssen uns ohnehin überlegen wie wir die fehlenden daten beim export und in der gui handhaben. wenn wir es ohnehin dauernd handhaben müssen, könnten wir es auch direkt "erfinden". anderesits mag ich erfudene daten nicht wirklich.

there is no easy way ...

 

[MiK]

Um ehrlich zu sein, verstehe ich das Grundproblem schon nicht. Was genau ist "unvollständig"? Was genau fehlt? Wie kommt es dazu? Und wie häufig kommt so etwas vor?

Wir brauchen uns hier nicht den Kopf zerbrechen, nur weil es irgendjemand mal irgendwie geschafft hat krude sein Profil zu zerstören. Wenn dies aber häufiger vorkommen kann, müssen wir einen vernünfitigen Weg dafür finden.

 

[MiK]

ok, grundsätzlich haben wir dafür das flag isIncomplete. ich lass mir das nochmal zusammen mit meinen letzten checkins durch den kopf gehen.

Man könnte natürlich auch nur mit diesem Flag arbeiten. Also es setzen, wenn etwas nicht richtig konvertiert werden konnte. Dann sieht der Anwender sofort (Totenkopf), dass etwas mit dem Cache nicht stimmt, und kann selbst entscheiden, was er tut. Man müsste sich dann nur überlegen, wie man mit solchen Caches beim Export umgeht.

frage: macht es sinn die incomplete caches "zu komplettieren"? wir müssen uns ohnehin überlegen wie wir die fehlenden daten beim export und in der gui handhaben. wenn wir es ohnehin dauernd handhaben müssen, könnten wir es auch direkt "erfinden". anderesits mag ich erfudene daten nicht wirklich.

"Erfinden" würde ich auch ungern etwas. Deswegen würde ich beim "komplettieren" gerne Werte setzen, die deutlich machen, dass der Wert "nicht gesetzt' ist. Z.B. bei D/T dann 0 setzen. Andere Felder kann man teilweise einfach leer lassen. An welchen Stellen sind wir denn "gezwungen" etwas zu erfinden? Vielleicht können wir da jeweils eine vernünftige Lösung finden.

 

[greiol]

An welchen Stellen sind wir denn "gezwungen" etwas zu erfinden? Vielleicht können wir da jeweils eine vernünftige Lösung finden.

an jeder stelle an der wir etwas speichern oder lesen müssen

ernsthaft:
was ist der wert den wir nach <CACHE> schreiben für ich habe keine daten. für zahlen verwenden wir an einigen stellen -1. falls das durchgängig ist, wäre das ein marker für zahlen. welchen nehmen wir für fehlende zeichenketten?

 

[MiK]

Woran erkennst Du denn, ob eine Zeichenkette fehlt, oder einfach gewollt leer ist? Ich würde sagen leer bleibt leer. Und wenn es eine Stelle ist, die normalerweise nie leer sein kann, ist "leer" auch ein gutes Erkennungsmerkmal für "fehlt"

 

[greiol]

über is_incomplete könnte man sowohl den weg von 2 nach 3 finden als auch die unvollständen profile aus 1 erkennen.

idee:
im moment liest der cacheholder eine zeile und schreibt sofort die werte in die felder des objektes. isincomplete kommt aber erst relativ spät in der zeile und würde mit hartem setzen des wertes aus der index.xml ein flag überschreiben das vielleicht ein anderer teil des importes wegen fehlern setzen wollte.

aus diesem grund würde ich den vorgang gerne trennen in
- einlesen der einzelnen felder in temporäre variablen
- zuweisen der temporären variablen zu den feldern des objektes während der zuweisung kann dann geprüft werden ob fehler auftreten und isincomplete könnte entsprechend gesetzt werden

damit würde uns die späte posistion von isincomplete im string nicht die werte zerhauen und es würde auch die größe 2 -> 3 abfangen, denn alle caches deren größe 2 nicht ermitteln konnte wurde auf -1 gesetzt und mit incomplete könnten wir dem user signalisieren dass hier etwas akztualisiert werden muss um wieder vollständig zu sein.