Ich bin natürlich etwas anderer Meinung
Auf der einen Seite ist es sicherlich eine ganz gute Idee, schon auf vorhanden Ressourcen aufzubauen (z.B.: Calendar-Apis in Sunbird) und sich nicht mit dem Datenformat herumärgern zu müssen.
Doch funktioniert diese Lösung auch mit Lightning und der Calendar-Extension in Thunderbird, Firefox und z.B.: SeaMonkey oder ist jedesmal ein separates Plugin zu schreiben oder zu installieren?
Der MozillaConnector ist mittlerweile soweit, die Calendar-Extension und Lightning in Thunderbird und Firefox zu erkennen und er ermittelt auch die verfügbaren Kalender von Sunbird. Dazu werden natürlich alle verfügbaren Profile und alle dazugehörigen Kalender geladen.
Einzig und allein das Einlesen der Daten mittels SQLite ist noch nicht fertig.
Ich habe bei der Entwicklung darauf geachtet, dass die Schnittstellen einheitlich sind. Das ermöglicht das unkomplizierte Ansprechen der oben genannten Mozilla-Komponenten und der Code z.B.: zur Abfrage/Synchronisierung von Firefox kann auch für Thunderbird (mit minimalen Änderungen) verwendet werden.
Der Problematik mit den Runtimes von C++ bin ich mir mittlerweile bewusst, doch wüsste ich keine Lösung, den MozillaConnector und SQLite ohne sie zu verwenden. (Was wieder für die Plugins spricht
)
Aber vielleicht weiß auf diesem Gebiet irgendwer mehr als ich (Ich bin nämlich wahrlich kein C++ Experte...)
Könnte man nicht die Runtimes einfach ins Setup des MPE "einpacken" oder zumindest prüfen, ob sie installiert sind und wenn nicht, den Download-Link anbieten?
Weiters wäre aus meiner Sicht wäre - im Vergleich - nicht mehr sehr viel Aufwand nötig den MozillaConnector fertig zu stellen.
Und natürlich will ich das Projekt jetzt nicht, nachdem ich doch recht viel Zeit investiert habe, über Bord werfen.
Darüber hinaus denke ich auch über eine kleine Applikation nach, die mir (durch Profile gesteuert) Kalenderdaten zwischen Handy, iPod, Sunbird, Thunderbird, Firefox,... hin-und-her "schaufelt". Um dieses Vorhaben zu realisieren bin ich natürlich auch auf den MozillaConnector angewiesen, wobei es sich aber sicherlich nicht lohnen würde, ihn einzig und allein dafür weiterzuentwickeln. Doch das sind - nicht zuletzt auf Grund von Zeitmangel - derzeit noch Träumereien
