a) Warum zippst Du den cmanager? Die Ersparnis des jar-Files zum zip waren nur wenige Bytes.
[/quote]
- Ein technischer Grund: Damit der cmanager seine Speichergröße anpassen kann, muss die cm.jar einen festen Namen haben. So kann ich den Namen der äußeren zip beliebig ändern und z.B. die Versionsnummer hinein schreiben.
- Und dann ist es der Versuch, es für nicht so technisch bewanderte Leute nutzbar zu machen. Die jar ist ja auch nur ein Archiv, dass man entpacken kann (für den Endanwender sinnlos). Je nach System- / Browserkonfiguration ist das die Standardeinstellung und würde ich da gerne Verwirrung vorbeugen. So nach dem Motto: Mehr als einmal werden die schon nicht versuchen, es zu entpacken.
b) Wenn man aus der Liste der Kandidaten ein oc-Listing anklickt und das Log erstellen läßt,
dann merkt sich das der cmanager nicht. Man könnte also nach Return wieder (versehentlich)
auf dasselbe oc-Listing klicken, und es wird wieder eine Logübertragung angeboten.
[/quote]
Oh, doof. Wird geändert.
[quote="mic@"]
d) Wenn Dir die Buchstaben ausgehen, dann beginne doch einen 0.3.a statt 0.2.27
[/quote]
Hmja. Ich bin nicht so der Freund vom Versionsnummern Herumwerfen. Wo ist der Firefox jetzt gerade? 30+ ?
Von daher verstecke ich Fortschritt lieber in den unteren Nummern, so lange es nur evolutionären und keinen revolutionären technischen Fortschritt gibt 
[quote="mic@"]
Mir fällt auf, daß der cmanager durch seinen Check mit rot/grün-Auswertung
ja quasi indirekt auch einen Abgleich auf Synchronität bei Doppellistings durchführt.
Könnte man dann sein Ergebnis nicht auch OCC mitteiilen?
[/quote]
Vermutlich müsste ich erst mal die Schattenliste einbeziehen, um euch da nicht mit Doppelten voll zu müllen, die ihr schon kennt. Ansonsten: Wenn es eine "API" gibt, dann droppe ich da gerne Treffer
. Wird verlinkt.