@skg:
Was du beschreibst ist ein CW-eigener Synchronisationsmechanismus, der noch implementiert werden müßte.
Meine Anmerkungen beziehen sich auf schon vorhandene Tools wie z.B. MissingSync für den Mac.
Der hier beschriebene Ansatz der manuellen Synchronisation bzw. Selektion ("Ich nehme nur die Cachebeschreibungen mit, die ich für heute geplant habe.") bedeutet deutlich mehr Vorbereitungsaufwand als bisher und ist deswegen ein Rückschritt. Mit der Definition einer Cachetour sollte die Planung abgeschlossen sein. Selbst diese kann unterbleiben, wenn man sich grob ein Cachegebiet ausguckt und sich vor Ort nach Zeit, Wetter und Laune von einem Cache zum nächsten hangelt.
Zur Idee nur index.xml als Datenbank zu verwalten:
Intern arbeitet jede halbwegs schnelle Datenbank mit einer oder mehreren Indexdateien, die aus Performance-Gründen im Hauptspeicher gehalten werden. Wenn jetzt also ein Profil geladen wird, wird zuerst der interne Index geladen und dann werden mit Hilfe dieses Index die weiteren Inhalte, die z.B. in der Liste dargestellt werden, dazugeladen. Deswegen erwarte ich hier keinen großen Zeitgewinn. Auf diese Weise liessen evtl. sich die Such- und die Filterfunktion beschleunigen.
Umfaßt diese Index-Datenbank zur Vermeidung von Redundanzen jedoch alle Caches, die bisher in einzelnen Profilen verwaltet wurden, dann wird sich die Ladezeit zum Start sehr deutlich erhöhen. Außerdem wird, wie schon angesprochen, der Speicherbedarf deutlich steigen. Die Bemerkung, daß Bilddateien noch speicherintensiver sind, stimmt, denn schon jetzt passiert es mir bei sehr bildintensiven Caches ("Suche diese zwanzig Fassaden") daß der CW aufgibt und 10 Fehlermeldungen ("Kann nicht laden") ausgibt. Wenn dieser knappe Speicherplatz jetzt verstärkt vom "fetten" Index besetzt wird, dann kann man sich den Aufruf einer Landkarte sparen.
Außerdem zeigt die Erfahrung ("Never change a running program!"), daß man mit so einer tiefgreifenden Änderung sehr vorsichtig sein sollte. Das "Aufbohren" des Statusfeldes bzw. der damit verbundenen Abfrage- und evtl. Änderungsmöglichkeiten erhält die Struktur und wird von mir auch aus diesem Grund präferiert.
Was du beschreibst ist ein CW-eigener Synchronisationsmechanismus, der noch implementiert werden müßte.
Meine Anmerkungen beziehen sich auf schon vorhandene Tools wie z.B. MissingSync für den Mac.
Der hier beschriebene Ansatz der manuellen Synchronisation bzw. Selektion ("Ich nehme nur die Cachebeschreibungen mit, die ich für heute geplant habe.") bedeutet deutlich mehr Vorbereitungsaufwand als bisher und ist deswegen ein Rückschritt. Mit der Definition einer Cachetour sollte die Planung abgeschlossen sein. Selbst diese kann unterbleiben, wenn man sich grob ein Cachegebiet ausguckt und sich vor Ort nach Zeit, Wetter und Laune von einem Cache zum nächsten hangelt.
Zur Idee nur index.xml als Datenbank zu verwalten:
Intern arbeitet jede halbwegs schnelle Datenbank mit einer oder mehreren Indexdateien, die aus Performance-Gründen im Hauptspeicher gehalten werden. Wenn jetzt also ein Profil geladen wird, wird zuerst der interne Index geladen und dann werden mit Hilfe dieses Index die weiteren Inhalte, die z.B. in der Liste dargestellt werden, dazugeladen. Deswegen erwarte ich hier keinen großen Zeitgewinn. Auf diese Weise liessen evtl. sich die Such- und die Filterfunktion beschleunigen.
Umfaßt diese Index-Datenbank zur Vermeidung von Redundanzen jedoch alle Caches, die bisher in einzelnen Profilen verwaltet wurden, dann wird sich die Ladezeit zum Start sehr deutlich erhöhen. Außerdem wird, wie schon angesprochen, der Speicherbedarf deutlich steigen. Die Bemerkung, daß Bilddateien noch speicherintensiver sind, stimmt, denn schon jetzt passiert es mir bei sehr bildintensiven Caches ("Suche diese zwanzig Fassaden") daß der CW aufgibt und 10 Fehlermeldungen ("Kann nicht laden") ausgibt. Wenn dieser knappe Speicherplatz jetzt verstärkt vom "fetten" Index besetzt wird, dann kann man sich den Aufruf einer Landkarte sparen.
Außerdem zeigt die Erfahrung ("Never change a running program!"), daß man mit so einer tiefgreifenden Änderung sehr vorsichtig sein sollte. Das "Aufbohren" des Statusfeldes bzw. der damit verbundenen Abfrage- und evtl. Änderungsmöglichkeiten erhält die Struktur und wird von mir auch aus diesem Grund präferiert.
