Und weil das doch sicher alles standardkonform ist, auf Gnome und KDE-Seite, usw., frage ich mich dann wirklich: warum kann man das Evolution-Programm, das hinter der GUI steckt, nicht einfach übernehmen, an die Gegebenheiten (Netzwerk, Dateimanager, Uhr, Benachrichtigungssystem) anpassen und dann eine Qt-GUI dafür bauen?
Man braucht dazu erst einmal den zeitlichen Kontext. Die Kommunikation zwischen EDS und seinen Clients erfolgte lange Zeit über CORBA, D-Bus stand nicht zur Verfügung und auch nicht auf der Roadmap als an den Arbeiten zu Akonadi begonnen wurde. Dazu kommt dann noch, dass bis noch vor kurzem E-Mail keiner der in EDS unterstützten Datentypen war.
D.h. auch wenn jetzt gerade diese Dinge besser sind, könnte man jetzt eine Umstellung neu evaluieren. Nur ist eben jetzt nicht 2007.
Dazu kommt dann eben noch die technische Schwierigkeit, dass die Kommunikation zwischen EDS und seinen Clients als internes Detail gehandhabt wird. D.h. eine Änderung in der Kommunikation wird einfach zeitgleich in Server und Client gemacht.
Das ist natürlich lösbar, d.h. man mit entsprechender Versionierung und Vermeidung von inkompatiblen Änderungen. Aber das erfordert eine entsprechende Änderung im Entwicklungsmodell und damit verbundenen Mehraufwand für das EDS Team.
Wie gesagt ergibt sich auf Grund von Umstellungen auf beiden Seiten (Evolution, KDEPIM) eine Angleichung der Gegebenheiten, die durchaus in Zukunft zu einer gewissen Austauschbarkeit von Komponenten führen kann, bzw. eventuell auch zu einer eigenständigen und von beiden Projekten benutzen Referenzimplementierung.
Selbst in einem viel einfacheren Feld wie dem gemeinsamen Secret Service bedeutet eine Zusammenführung einen Prozess von mehreren Jahren, denn benötigt nicht nur den neuen Dienst bzw neue Schnittstellen für einen bestehenden Dienst, sondern auch entweder entsprechende Anpassungen in allen benutzenden Programmen oder eine neue Implementierung der vorhanden APIs basierend auf den neuen Schnittstellen.
Das Anstreben solcher Universallösungen dürfte durchaus die Unterstützung vieler Entwickler geniessen, nur sind sich diese eben auch der damit verbundenen "Kosten" bewusst. D.h. man arbeitet in kleinen Schritten daran die Unterschiede zu minimieren um den Aufwand zu verringern, den eine Umstellung auf eine gemeinsame Lösung mit sich bringen wird.
Es ist denke ich verständlich, dass aus Benutzersicht diese Kosten nicht sichtbar sind oder gering erscheinen, aber leider ist die Realität aus der Entwicklersicht oft eine ganz andere.
Man braucht dazu erst einmal den zeitlichen Kontext.
Die Kommunikation zwischen EDS und seinen Clients erfolgte lange Zeit über CORBA, D-Bus stand nicht zur Verfügung und auch nicht auf der Roadmap als an den Arbeiten zu Akonadi begonnen wurde. Dazu kommt dann noch, dass bis noch vor kurzem E-Mail keiner der in EDS unterstützten Datentypen war.
D.h. auch wenn jetzt gerade diese Dinge besser sind, könnte man jetzt eine Umstellung neu evaluieren. Nur ist eben jetzt nicht 2007.
Dazu kommt dann eben noch die technische Schwierigkeit, dass die Kommunikation zwischen EDS und seinen Clients als internes Detail gehandhabt wird. D.h. eine Änderung in der Kommunikation wird einfach zeitgleich in Server und Client gemacht.
Das ist natürlich lösbar, d.h. man mit entsprechender Versionierung und Vermeidung von inkompatiblen Änderungen. Aber das erfordert eine entsprechende Änderung im Entwicklungsmodell und damit verbundenen Mehraufwand für das EDS Team.
Wie gesagt ergibt sich auf Grund von Umstellungen auf beiden Seiten (Evolution, KDEPIM) eine Angleichung der Gegebenheiten, die durchaus in Zukunft zu einer gewissen Austauschbarkeit von Komponenten führen kann, bzw. eventuell auch zu einer eigenständigen und von beiden Projekten benutzen Referenzimplementierung.
Selbst in einem viel einfacheren Feld wie dem gemeinsamen Secret Service bedeutet eine Zusammenführung einen Prozess von mehreren Jahren, denn benötigt nicht nur den neuen Dienst bzw neue Schnittstellen für einen bestehenden Dienst, sondern auch entweder entsprechende Anpassungen in allen benutzenden Programmen oder eine neue Implementierung der vorhanden APIs basierend auf den neuen Schnittstellen.
Das Anstreben solcher Universallösungen dürfte durchaus die Unterstützung vieler Entwickler geniessen, nur sind sich diese eben auch der damit verbundenen "Kosten" bewusst. D.h. man arbeitet in kleinen Schritten daran die Unterschiede zu minimieren um den Aufwand zu verringern, den eine Umstellung auf eine gemeinsame Lösung mit sich bringen wird.
Es ist denke ich verständlich, dass aus Benutzersicht diese Kosten nicht sichtbar sind oder gering erscheinen, aber leider ist die Realität aus der Entwicklersicht oft eine ganz andere.