CacheWolf Desktop Spinnoff?

[TweetyHH]

Nachdem ich vor einiger Zeit auch schon am Cachewolf rumgefummel mitgearbeitet hatte, hab ich mich mal wieder dran gemacht. Dabei hab ich den GPX-Exporter für Vantage Point (Software für Magellan Tritons) der im Magellan Board kursierte (also nicht von mir geschrieben) mal in den den aktuellen Cachewolf eingebaut (ich glaube der Grund, dass er damals nicht in das offizielle Release hingekommen ist, dass es damals einen Feature Freeze gab, der ja recht lange bestand. Dabei war mir schon aufgefallen, dass er offensichtlich den CacheWolf gegen die Orginal java.lang.* Klassen gebaut hatte und nicht die aus dem Ewe release.

Naja, alles in allem dachte ich dann an das nächste Feature, was mir beim Cachewolf fehlt: Die Möglichkeit Mails direkt zu lesen und zu importieren. Naja, kurze Rede: Da ich wenig Lust hatte, das per Hand zu programmieren (in Ewe seh ich keinen eingebauten Support für Pop3 oder Imap) hab ich mich entschieden das ganze mit Hilfe von JavaMail zu programmieren (und bin da auch noch bei). Das ganze wird vermutlich niemals auf einem PDA laufen können.

Und genau hier seh ich momentan auch etwas die Grenzen an die der Cachewolf stößt. Der Cachwolf möchte alles sein: Sowohl GSAK (also ein Tool auf dem Desktop PC) als auch (als ein von vielen Beispielen genannt) CacheBeagle - ein Tool um mit einem mobilen Gerät zu Cachen.

Ich sehe natürlich die Vorteile, die gemeinsamer Code auf mehreren Plattformen bietet. Aber die Ewe Gui (die man wohl nicht so schnell über Bord wirft) bietet auf dem Desktop nicht die schönste Benutzbarkeit. Außerdem macht gerade Ewe viele Dinge, die mit der vollen Java-API leicht umzusetzen wären (gerade Verarbeitung von großen Mengen Daten in z.B. XML), unnötig kompliziert. Und wieder andere Dinge, die existieren (z.B. Mail-API) müsste man für Ewe komplett neu schreiben. Aber auch für die mobilen Geräte seh ich Nachteile aus einer großen Codewolke: Auf einem PDA wird man eigentlich keine Daten exportieren wollen. Auch der Speicher- und Oberflächenbedarf steigt mit weiteren Funktionen immer weiter an.

Daher überlege ich sehr ernsthaft, ob es sinnvoll ist einen Desktop-Spinnoff des Cachewolfs zu starten, der vermehrt auf der vollen Java-API bassiert (ein Fernziel könnte sein, EWE komplett los zu werden). Das Ziel soll keine Konkurenz zu Cachewolf sein, sondern eher als Opensource-Konkurzen zu GSAK gesehen werden - d.h. wie dieser leicht zu erweitern sein: Sei es durch Plugins oder aber auch Skripte.

Ich sehe natürlich auch die Gefahr, dass sich in so einem Fall evtl. Entwicklerarbeit auf zwei unterschiedliche Projekte aufteilen würde und dann beide ungepflegt enden.

Ich würde mich über Feedback freuen. Ebenso würde mich interessieren, ob es andere Cacher gibt, die sich an einer Weiterentwicklung in diese Richtung beteiligen würden.

Grüße Florian

 

[greiol]

meinung:
wenn du dir die mühe machen möchtest das einmal komplett zu reimplementieren, lass die finger von java egal welcher ausprägung. bau eine kernbibliothek (dll resp.so) in c(++) ohne gui die sich auf hinreichend vielen plattformen kompilieren lässt. die kann dann wiederum in plattformabhängige anwendungen die auch eine gui haben reingelinkt werden oder über jni, perl, python, c# angesprochen werden. das dürfte zum einen einen deutlichen geschwindigkeitsgewinn bringen und zum anderen gar zu brutales auseinanderdriften verhindern. einen mailwolf brauche ich ehrlich gesagt nicht.

 

[klausundelke]

Ich bin auch noch níe auf die Idee gekommen, CW zum mailen zu verwenden :schockiert:

Aber den Magellan Export finde ich extrem interessant. Bisher hat das Einlesen in Vantage Point
bei mir immer Abstürze verursacht.
Werd das nächste Woche mal austesten, falls das klappen würde wäre das saustark!

 

[TweetyHH]

Auch wenn dein Posting ziemlich am eigentlichen Thema vorbei ist (C steht wirklich nicht zur Debatte) :

Wenn man das ganze in richtigem Java macht, dann muss man sich zumindest auf einem Desktop keinerlei Gedanken über Performance machen ... aber die ewig Gestrigen werden das noch in 10 Jahren behaupten. Und gerade für OpenSource ist meines Erachtens Java aufgrund der saubereren und einfach zu lernenderen Sprache einfach deutlich besser geeignet (ich erinner mich an den Quark den ich hatte, als ich 3 Librarys nutzen musste, die alle möglichen String Arten beinhalten: ein mal char*, einmal den C++ String und Microsoft muss ja auch noch was erfinden ...).

Außerdem will ich ja gar nicht das Rad auf einen Schlag neu erfinden.

P.S. Wieso verstehen mich alle falsch? Ich will nicht Mails versenden: Ich will Mails empfangen! Vorallem bei den Pocketquerys ist es doch nervig die immer erst speichern zu müssen ... und wenn ich schon eine Mail bekomme, die aussagt, dass ein Cache archiviert ist, dann kann mein Cachewolf das doch auch gerne wissen, ohne dass ich ihm das alles erzählen muss ;-)

 

[greiol]

Wenn man das ganze in richtigem Java macht, dann muss man sich zumindest auf einem Desktop keinerlei Gedanken über Performance machen ... aber die ewig Gestrigen werden das noch in 10 Jahren behaupten.

es geht darum eine software zu haben die auf möglichst vielen plattfromen läuft. und welche probleme java da macht hast du selber ja im eingangsposting geschrieben. ein rewrite in nativem java staht für mich nicht zur debatte

Und gerade für OpenSource ist meines Erachtens Java aufgrund der saubereren und einfach zu lernenderen Sprache einfach deutlich besser geeignet

für open source die einen breites einsatzspektrum haben soll, trifft das imho eben genau nicht zu.

Außerdem will ich ja gar nicht das Rad auf einen Schlag neu erfinden.

mir ist klar, dass das auf den ersten blick nicht einladend wirkt, aber eine halbgare halbimplementierung bringt in meinen augen keinen vorteil.

P.S. Wieso verstehen mich alle falsch? Ich will nicht Mails versenden: Ich will Mails empfangen! Vorallem bei den Pocketquerys ist es doch nervig die immer erst speichern zu müssen ...

warum baust du dann statt dem nächsten gui client nicht etwas was batchverarbeitung machen kann? dann muss ich cw noch nicht mal starten um mail abzurufen weil das alles schon lange im hintergrund geschehen ist

der von dir aufgezeigte weg wird wohl nicht meiner sein.

 

[MiK]

Um mal auf die Ursprungsfrage einzugehen: CW ist OpenSource. Du kannst gerne ein SpinOff-Projekt (möglichst unter klar unterscheidbarem Namen) starten. Ich werde aber weiterhin beim Cachewolf-Projekt bleiben, da ich die meisten Funktionen auf Desktop und mobil für sinnvoll halte.

 

[pfeffer]

a) Du hast recht: eine ordentliche Java-VM kann fast mit nativem Code mithalten (JIT), zumindest aufm Desktop.

b) Die PocktPCs haben standardmäßig keine (gute) JavaVM mitgeliefert.

c) Deswegen wäre es durchaus eine denkbare Alternative zumindest Code, der in Ewe sehr langsam ist, auszulagern.

d) Nen Mailclient in CW? - Auf den ersten Blick sehr befremdlich. Auf den zweiten: wieso eigentlich nicht? Vermutlich kann man die PocketQueries am Betreff erkennen, CW müsste nur die herunterladen. Und CW müsste sich merken, welche er schon geladen hat.

e) dazu könnte man überlegen, die Idee von Salzkammergut aufzugreifen und eine Schnittstelle für Add-Ons oder so anzubieten (Modularisierung). Er hatte dazu mal einige Überlegungen angestellt - ich war bisher eher Gegner davon, weil ich denke, dass dies recht aufwändig ist und die Integration neuer Features einfacher und im Endeffekt auf ressourcenschonender.

f) Da fällt mir ein: Ich glaub: Irgendwer hatte schon einen CW gebaut, bei dem man Menü-Befehle hinzufügen kann, darüber könnte man ein externes Prog starten, das die PocketQueries holt - danach müsste man CW nur noch sagen, dass er sie einlesen soll.

g) Eine schöne Oberfläche ist auch mit Ewe möglich, wenn auch evtl. merh Arbeit.

h) Ewe-java läuft in der Java-VM sehr flott.

i) Mir scheint es damit keinen Grund für einen Fork zu geben.

j) Wegen des Mailclients würde ich jedenfalls nicht zum Fork wechseln.

Gruß,
Pfeffer.

 

[TweetyHH]

b) Die PocktPCs haben standardmäßig keine (gute) JavaVM mitgeliefert.

Damit meinst du auch unmittelbar die Ewe VM, oder? Oder gibt es inzwischen was vernüftigeres als J2ME? *Fingernägel Roll, nachdem ich mal PocketPocketQuery erweitert hatte*

c) Deswegen wäre es durchaus eine denkbare Alternative zumindest Code, der in Ewe sehr langsam ist, auszulagern.

Hört sich natürlich erstmal toll an: Ach, werfen wir ein bissle JNI an und fertig ... naja, ganz so schön wird es dann wohl nicht: Auch JNI hat einen gewissen Overhead, der sich erstmal bezahlt machen muss. Außerdem müssen die Daten über JNI übergeben werden (was nun nicht das Schönste ist ...). Außerdem verarbeitet der Cachewolf hauptsächlich strukturierte Daten und es ist wenig "Rechenalgorithmik" da, die sich in meinen Augen lohnen würde auszulagern. Ich glaube nicht, dass Auslagern auf eine native Sprache hier irgendetwas bringen würde.

d) Nen Mailclient in CW? - Auf den ersten Blick sehr befremdlich. Auf den zweiten: wieso eigentlich nicht? Vermutlich kann man die PocketQueries am Betreff erkennen, CW müsste nur die herunterladen. Und CW müsste sich merken, welche er schon geladen hat.

Naja, genau dafür hab ich mir bei googlemail einen Account angelegt (den ich momentan per CacheWolf-Fork-Kandidaten per IMAP abfrage). Da kann ich PQs solange sammeln wie ich möchte, da ist genug Platz. Nach dem Abholen mit dem Cachewolf kann man diese endweder löschen, als gelesen markieren, in einen anderen Ordener verschieben (ok, genau das Verschieben hab ich noch nicht probiert, müsste aber eigentlich auch gehen).
Aber damit sind die Möglichkeiten ja nicht beendet: Eine archived-Mail => Cache sofort auf archived setzen, sich nicht mit PQs in solchen Fällen rumschlagen. Eine publish Mail => sofort Spidern. Auf fast jede Logtyp kann man reagieren (Ok - Found logs und DNFs möchte ich eigentlich nicht alle so reinbekommen, da ist die PQ doch besser). Läuft hier jetzt Testweise sehr bequem. Dadurch kann man eine größere Datenbasis vermutlich ziemlich gut richtig aktuell halten.

e) dazu könnte man überlegen, die Idee von Salzkammergut aufzugreifen und eine Schnittstelle für Add-Ons oder so anzubieten (Modularisierung). Er hatte dazu mal einige Überlegungen angestellt - ich war bisher eher Gegner davon, weil ich denke, dass dies recht aufwändig ist und die Integration neuer Features einfacher und im Endeffekt auf ressourcenschonender.

Das wäre eigentlich auch mein Wunsch: Plugins. Nur soweit ich das sehe ermöglicht einem das Ewe (und ich muss auch sagen, die bisherige Architektur des Wolfes) nicht. Ich könnte mir vorstellen, dass es mit EWE in der Java-VM auf dem Desktop geht, allerdings läuft man ständig in die Falle: Java-Klassen vs. Ewe-Klassen.
Und das ganze über irgendwelche exec-Aufrufe zu machen ist erstens ziemlich dreckig (Funktionalität schreiben und dann irgendwie rausschreiben, so dass der Cachewolf das wieder parsen kann ...) und zum anderen mehr dürfte das auf Dauer noch mehr Performance fressen als die Ewe-VM.

f) Da fällt mir ein: Ich glaub: Irgendwer hatte schon einen CW gebaut, bei dem man Menü-Befehle hinzufügen kann, darüber könnte man ein externes Prog starten, das die PocketQueries holt - danach müsste man CW nur noch sagen, dass er sie einlesen soll.

Im Fall der Mails lässt sich das evtl. machen, man hat aber ein deutliches mehr an Arbeit, weil man sich einen Haufen Gedanken machen muss, wie die Schnittstelle dazwischen aussieht.

g) Eine schöne Oberfläche ist auch mit Ewe möglich, wenn auch evtl. merh Arbeit.

Soooo schlimm finde ich die vom Aussehen eigentlich auch gar nicht. Ich fände eine "klassische" Desktop Gui allerdings manchmal schöner. Was mich nervt ist, dass ich Datensätze in der Tabelle anharken statt mit Shift oder Str sie gezielt zu markieren ...

i) Mir scheint es damit keinen Grund für einen Fork zu geben.
j) Wegen des Mailclients würde ich jedenfalls nicht zum Fork wechseln.

Naja, genau dieser Mailmodus (also PQs ziehen) ist genau das, was mich manchmal neidisch auf die GSAKler gucken lässt. Nur da das bisher meines Wissens nicht unter Wine läuft, brauch ich auch gar nicht rüber zu starren. Außerdem stört mich dort etwas das Close-Source - denn ein Großteil der Funktionalität besteht aus Skripten, die die Nutzer zusteuern (dürfen).

 

[greiol]

j) Wegen des Mailclients würde ich jedenfalls nicht zum Fork wechseln.

Naja, genau dieser Mailmodus (also PQs ziehen) ist genau das, was mich manchmal neidisch auf die GSAKler gucken lässt.

aber dafür den fork? das könntest du auch in cw mit dem knopf "arbeite das incoming verzeichnis ab" erledigen und ob das incoming verzeichnis mit procmail oder etwas anderem gefüllt wurde, kann sich dann jeder selber überlegen.

sowas wie

<cwbatch>
  <cmd profile="xxxx" action="import" what="/path/to/pq/or/gpx" />
  <cmd profile="yyyy" action="disable" what="GCxxxx" />
</cwbatch>

sollte sich mit überschaubarem aufwand programmieren lassen. manchmal wäre es vielleicht praktisch. wirklich vermisst habe ich es noch nicht.

 

[MiK]

Auch wenn wir uns ab und zu von Funktionalitäten von GSAK inspirieren lassen, sehe ich das Ziel von CW ganz klar nicht darin einen Open Source Clone von GSAK zu bauen.

 

[klausundelke]

Dabei hab ich den GPX-Exporter für Vantage Point (Software für Magellan Tritons) der im Magellan Board kursierte (also nicht von mir geschrieben) mal in den den aktuellen Cachewolf eingebaut

Ist das jetzt auch für den "normalen" Anwender in einem Nightly build verfügbar?
Ich nutze auch ein Magellan und hätte starkes Interesse an dem Exporter.

Gruß
Klaus

 

[TweetyHH]

Momentan ist der Exporter nicht in dem CacheWolf svn vorhanden, da ich glaube keinen schreibenden Account mehr für dieses zu haben.

Allerdings hab ich jetzt mit UncleOwen mit dem Fork begonnen. Dieses ist jetzt unter http://code.google.com/p/cachehound/ zu finden. Da findest du auch schon einen "Nightly Build" wenn du so möchtest (muss ich allerdings noch immer per Hand hochladen, du kannst dir aber auch den CacheHound schnell selber bauen, siehe Anleitung auf der Seite). Die Profile sollten zum CacheWolf kompatibel sein, auch wenn ich eine kleine Änderung vorgenommen haben.

P.S. Ich hoffe mit dem Namen das Projekt einerseits deutlich vom CacheWolf zu unterscheiden, aber auch die Herkunft noch deutlich zu machen.

P.P.S. Ich möchte mit dem Jagdhund allerdings keine Wölfe jagen ;-)

P.P.P.S. Ihr könnt natürlich auch gerne Code zurück in den CacheWolf überführen, passt aber auf: Ich hab soweit es ging das Encoding aller Dateien auf UTF 8 umgestellt.

 

[TweetyHH]

Noch eine Anmerkung zu der Version SVN 29:

Das Email-Feature ist noch ziemlich experimentel und noch lange nicht vollständig. Bevor der Importer => Email genutzt werden kann, müssen in den Einstellungen User, Passwort, Server und Protokoll eingestellt werden. Erfolgreich verarbeitete Mails werden als gelesen Markiert.

Folgenden Protokolle werden Unterstützt:
imap = normales Imap
imaps = Imap + SSL
Achtung, ich hab keine Ahnung ob die Pop3 Moduse nicht alle Mails vom Server hauen. Daher Pop 3 unbedingt auf einer eigenen Mailbox ausprobieren, auf der keine Mails empfangen werden die euch irgendwie wichtig sind!
pop3 = POP 3
pop3s = POP 3 + SSL

 

[pfeffer]

schade, dass Du wirklich einen Fork begonnen hast. Aber, wenn er kompatibel bleibt, werden ja mehr Möglichkeiten geschaffen, was wiederum begrüsstenswert ist.

Niemand hat Deinen Account bei BerliOS gelöscht, es sei denn, Du hast es selbst getan. Müsstest also Schreibzugriff für CacheWolf haben.

ja, die Umstellung aller Dateien auf UTF8 wäre bei CacheWolf auch mal fällig.

Gruß,
Pfeffer.

 

[flopp]

Habe CacheHound grade mal ausprobiert. Bisher funktioniert alles super, vor allem der E-Mail-Import!
Bisher habe ich eigentlich gar kein Cache-Verwaltungsprogramm genutzt, sondern nur die POIs von Patrick Röder, die es jetzt leider nicht mehr gibt.
Apropos: ein Export nach CSV (und dann ins Garmin POI-Format) im Stil von Patrick Röder (Aufteilen von Hints auf mehrere POIs, falls der Text zu lang ist) wäre für mich als Etrex-Nutzer ein Killerfeature...

Grüße
Flopp