Von Idiotenpfleger am Mi, 8. Februar 2012 um 14:14 #
na dann bin ich ja mal gespannt, welche großen Ziele mit dieser Herangehensweise erreicht werden sollten. Hast du diese Ziele verstanden? Kannst du sie erklären?
Was, außer Mails empfangen, Termine und Adressen verwalten soll eine PIM Software können? Welche Aufgaben, von diesen genannten, kann Thunderbird nicht? Wo versagt auch z.B. Evolution? Was ist also das "Shortcoming" all dieser Mailprogramme? Was kann Kmail2 stattdessen, außer sinnlos Festplatte und CPU fressen?
Also... dann stellt sich mir das ganze so dar: wir wollen eine Revolution unter den Mailprogrammen loslassen und bauen uns die super-duper-Maschinerie zusammen... und dann, als sie fertig war, die Super-Mailkiste... dann konnte sie nichtmal Mails empfangen oder senden... wahnsinn... ja, das ist revolutionär.
Da wäre mal das Ziel, den gleichzeitigen Zugriff auf Daten zu verbessern. Der vorher benutze Ansatz, aus allen interessierten Applikation parallel auf die selbe(n) Datei(en) zuzugreifen hat immer wieder zu Problemen geführt. Unter anderem weil das dafür nötige Sperren von Dateinzugriffen nicht auf allen Dateisystem (gleich) funktioniert. D.h. es kam schon mal vor, dass zwei Programme ihre Änderungen gegenseitig überschrieben haben.
Der neue Ansatz verbessert dies, in dem nur immer ein Programm auf die Datei direkt zugreift und alle anderen eben mit diesem Dienst kommunizieren.
Dann wäre da weiters das Ziel "Offline" Fähigkeiten für alle Datentypen zur Verfügung zu haben, nicht nur für IMAP E-Mails. Das ist natürlich interessanter für Benutzer, die serverbasierende Adressbücher und Kalendar benutzen und deren Server nicht im selben Netzwerk stehen oder die mobil arbeiten.
Auf der Anwendungsebene ist ein Ziel den Datenzugriff von der Datendarstellung zu trennen. Der Hauptgrund dafür ist, dass vorher bestimmte Funktionalität von Programmen an das Vorhandensein und Ausgeführtwerdens eines anderen Programms abhingen. Z.B.: die Möglichkeit auf Adressbücher oder Kalendar zuzugreifen, die in speziellen Ordnern auf einem IMAP Server liegen, erforderte bisher das Vorhandensein und Ausgeführtwerden von KMail, weil darin sowohl IMAP Zugriff als auch Anzeige implementiert war.
Das Ausgliedern in einen Dienst erlaubt nun Programmen solche Adressbücher oder Kalendar zu benutzen, ohne dass der Benutzer dafür KMail installiert und laufen haben muss.
Was, außer Mails empfangen, Termine und Adressen verwalten soll eine PIM Software können? Welche Aufgaben, von diesen genannten, kann Thunderbird nicht? Wo versagt auch z.B. Evolution?
Es geht da nicht darum was andere Programme können, sondern ob und wie diese entsprechende Funktionalität für anderen Programme zur Verfügung stellen. Thunderbird ist daran nicht interessiert und das kann für viele Benutzer auch ausreichend sein. Andere Benutzer brauchen die Möglichkeit auf ihre Daten, z.B. Kontakte, von anderen Programmen nicht nur auf Import-/Exportbasis zuzugreifen.
Aus diesem Grund benutzt Evolution ebenfalls einen dienstbasierten Ansatz (siehe Evolution Data Server), allerdings bis vor kurzem meines Wissens nur für Adressbücher und Kalendar (d.h. Unterstützung für E-Mail ist da auch noch relativ neu).
Von Idiotenpfleger am Mi, 8. Februar 2012 um 19:46 #
danke für die Erläuterungen. Klingt alles nach was ziemlich großem... Obwohl ich nicht ganz begreife, warum man nicht wenigstens eine Grundfunktionalität einfach so "normal" darstellen kann und wenn es wirklich DER spezielle Anwendungsfall ist, mit Dateien auf dem Server und was weiß ich - dass man dann und nur dann auf dieses große Gebilde zurückgreift... Ich meine, die Idee ist ja nicht schlecht (eigentlich verdammt faszinierend), aber man bewegt sich sehr eng an der Kante der Nicht-Akzeptanz. Vor allem bei Fehlern und wenn es kompliziert ist.
Denn es ist nunmal so: der einfache Benutzer begreift nicht, warum er stundenlang am Mailprogramm rumkonfigurieren muss... immer wieder die Meldung, dass irgendeine Migration nicht funktioniert hat und was weiß ich... der will einfach nur Mails lesen und schreiben und seine Kontakte und Termine verwalten... Also all das klingt zwar furchtbar spannend, aber es ist schwer zu vermitteln.
Und wenn man dann immer wieder in Probleme kommt und immer wieder irgendwas nicht funktioniert, dann denkt man als User: "Wisst ihr was, ihr könnt euch euren höheren Zweck sonstwo hinstecken"... das sind dann die Akzeptanzprobleme. Dann kommt das schlechte Imgage... "KDE? Kmail? der Zacker-Kram? nee, lass mal. Da bleib ich lieber beim Win, oder Unity... irgendwas". Also als User ist man schon fehlertolerant. Ich habe mir zwar kein KDE 4.0 gegeben, aber in der 4er Reihe bin ich seit 4.1 dabei und ich habe viel erlebt. Und ich bin auch verdammt stolz auf KDE, weil es in meinem Fall seit 4.2 einigermaßen gut läuft und auch generell mit jeder Version immer besser geworden ist. Wenn man dann immer wieder mal in irgendwelche Löcher fällt = irgendwas nicht funktioniert, dann ist es bis zu einem bestimmten Maß auch ok. Nur wenn man dann Daten verliert... dann hörts bei mir auf. Und Kmail2 hat mir so manchen Schaden eingebrockt. Da habe ich kein Verständnis. Auch nicht, wenn eine "große Sache" dahinter steckt. Und auch nicht, wenn es nix kostet.
Meiner Meinung nach gehört ein funktionierendes Mailprogramm zu einem anständigen DE. Heißt: es muss funktionieren. Auch wenn es kompliziert ist: dann ist es eben im Hintergrund kompliziert, aber für den User hat es einfach zu sein. Auch wenn´s geschenkt = gratis ist.
Ich stelle mir auch immer wieder die Frage: warum bastelt KDE denn an einem eigenen PIM? Warum kann man denn nicht meinetwegen Thunderbird nehmen, den ins KDE integrieren und mit Add-ons bedarfsgerecht aufmotzen?
Warum kann man denn z.B. Evolution nicht einfach nehmen und an den entsprechenden Stellen ans KDE anpassen?
Ist doch freie Software... da geht das doch! Liegts am Ego? Am NIH Syndrom? Warum macht man sich diese Arbeit, lässt die Beschimpfungen über sich wegrollen... um dann bei der nächsten Version wieder nix zum Besseren geändert zu haben... traurig.
IMO liegt es an den Distros. Die stimmen z.B. KDE- und Gnomesoftware einfach nicht aufeinander ab. Dabei sind selbst z.B. Epiphany-Browser und Evolution hervorragend unter KDE4 nutzbar, gerade wegen des mitinstallierten, funktionsfähigen Gnome-Networkmanagers.
Um den überflüssigen Bloat in Grenzen zu halten, bräuchte man halt durchgehend schlanke kde-, gtk-, qt-, gnome-Basisbibliotheken.
Was nicht passieren darf, ist, dass z.B. Tracker und Nepomuk gleichzeitig herumwerkeln, nur weil mit den entsprechenden Programmen gearbeitet wird. Eine Art Mindestabstimmung zwischen den DEs wäre also in jedem Fall vonnöten. Und das wäre die Aufgabe der Distros.
Obwohl ich nicht ganz begreife, warum man nicht wenigstens eine Grundfunktionalität einfach so "normal" darstellen kann und wenn es wirklich DER spezielle Anwendungsfall ist, mit Dateien auf dem Server und was weiß ich - dass man dann und nur dann auf dieses große Gebilde zurückgreift...
Ich denke das Hauptproblem ist den Rahmen von Grundfunktionalität wirklich gut zu stecken. Würde es nur um ein Programm gehen könnte man zum Beispiel den Rahmen so definieren, dass der Zugriff auf lokale Dateien direkt passiert. Nachdem das aber schon alleine in KDEPIM nicht der Fall ist (z.B. Zugriff auf Kontakte aus Adressbuch, Kalendar und E-Mail Programm) ist der Rahmen von Grundfunktionalität schon mal der gleichzeitige Zugriff auf lokale Dateien.
Bzw. im Falle von E-Mails ist der Zugriff auf Server schon im Rahmen der Grundfunktionalität.
Durch das sehr ähnliche Anforderungsprofil bei GNOME sieht man eigentlich ganz schön, dass man dort auf die selben Techniken setzt, um die nötige Funktionalität umzusetzen. Mozilla hat auf Grund eines einfacheren Profils weniger komplexe Problemstellungen und kann daher andere Wege gehen.
Denn es ist nunmal so: der einfache Benutzer begreift nicht, warum er stundenlang am Mailprogramm rumkonfigurieren muss... immer wieder die Meldung, dass irgendeine Migration nicht funktioniert hat und was weiß ich... der will einfach nur Mails lesen und schreiben und seine Kontakte und Termine verwalten... Also all das klingt zwar furchtbar spannend, aber es ist schwer zu vermitteln.
Da gebe ich dir natürlich recht. Hier hat der Wunsch, den Umstieg von alter zu neuer Technologie möglichst "unsichtbar" zu gestalten, genau zum Gegenteil geführt. Im Nachhinein betrachtet wäre ein expliziter "import" Prozess besser gewesen. Der hätte von den Benutzer zwar Interaktion erwartet, wäre aber daher auch besser kontrollierbar gewesen.
Meiner Meinung nach gehört ein funktionierendes Mailprogramm zu einem anständigen DE.
Ich würde jetzt nicht sagen zu einer DE, das wären eher so Sachen wie Fensterleiste, Desktop, Windowmanager. Aber durchaus zum Produktumfang eines Herstellers von Endbenutzer-Software für "alle" Basisanwendungsbereiche.
Ich stelle mir auch immer wieder die Frage: warum bastelt KDE denn an einem eigenen PIM?
Die einzelnen Programme gibt es einfach schon seit ewig, KMail gab es z.B. schon für KDE1. Im Falle der darunterliegenden Infrastruktur, z.B. dem Adressdateizugriff, weil das einfach von einer Plattform für Endanwendersoftware erwartet wird (und daher z.B. auch Bestandteil jeder Plattform für Mobilgeräte oder proprietärer Desktopplattformen ist).
Warum kann man denn nicht meinetwegen Thunderbird nehmen, den ins KDE integrieren und mit Add-ons bedarfsgerecht aufmotzen?
Ich denke das wäre nicht durchführbar. Thunderbird ist nicht als Komponenten in einem größerem System konzipiert, d.h. es ist vermutlich schwer das Programm ohne GUI zu starten bzw. zu verhindern dass es beendet wird während es von einer anderen Applikation für den Dateizugriff gebraucht wird.
Warum kann man denn z.B. Evolution nicht einfach nehmen und an den entsprechenden Stellen ans KDE anpassen?
Das ist schon eher machbar, allerdings auch nicht so einfach. Die Kommunikation zwischen Evolution Data Server (EDS) und seinen Clients funktioniert mehr oder weniger über bestimmte Bibliotheken, die zugrunde liegende Kommunikation ist nicht so fixiert und Server und Clientbibliotheken werden bei Bedarf zeitgleich verändert. Das würde das Bereitstellen von Qt-basierten Clientbibliotheken relativ schwer machen, oder auf Seiten der EDS Entwickler eine Umstellung ihrer Verfahrensweise bedeuten.
Durch die Umstellung bei KDE auf eine ähnliche (dienstbasierte) Architektur und die Erweiterung des Leistungsmfangs bei EDS (+ E-Mail) und die Umstellung auf D-Bus für die interne Kommunikation, ergibt sich schon eine gewisse Konvergenz. Es ist daher durchaus vorstellbar, dass sich in Folge daraus eine Art von Austauschbarkeit ergibt.
Von Idiotenpfleger am Do, 9. Februar 2012 um 12:36 #
Zitat: "Durch das sehr ähnliche Anforderungsprofil bei GNOME sieht man eigentlich ganz schön, dass man dort auf die selben Techniken setzt, um die nötige Funktionalität umzusetzen. Mozilla hat auf Grund eines einfacheren Profils weniger komplexe Problemstellungen und kann daher andere Wege gehen."
Zitat: "Durch die Umstellung bei KDE auf eine ähnliche (dienstbasierte) Architektur und die Erweiterung des Leistungsmfangs bei EDS (+ E-Mail) und die Umstellung auf D-Bus für die interne Kommunikation, ergibt sich schon eine gewisse Konvergenz. Es ist daher durchaus vorstellbar, dass sich in Folge daraus eine Art von Austauschbarkeit ergibt."
also, das liest sich ja so wie: "die bei Gnome haben das gleiche gemacht, nur eben auf einige Gnome-spezifische Dinge angepasst" ...
für mich als Nutzer sind hier die augenscheinlichsten Dinge:
- Einbindung in die Desktop-Uhr, zur Terminverwaltung und Benachrichtigung
- Einbindung in das User-Benachrichtigungssystem
- Anbindung an die Netzwerkschnittstelle
- Optik = GUI in GTK
- Diensteverwaltung: D-Bus und Udev
- Anbindung an den Dateimanager fürs speichern von Dokumenten und für "Rechtsklick --> senden per E-mail an..."
Der Unterschied zum Kmail2 ist, dass Evolution erste Sahne funktioniert. Und ich als User frage mich:
- Desktop-Uhr und Benachrichtigungsystem? Hat KDE
- Netzwerkschnittstelle? Hat KDE
- Optik? Qt
- Dateimanager? Hat KDE
- Diensteverwaltung: D-Bus und dieses Udev
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? Doch wegen NIH? Bestimmt. Da bin ich mir jetzt ziemlich sicher.
Ich meine, das mit Thunderbird sehe ich ein, dass das sinnlos wäre, aber bei Evolution... da kann man Argumente noch und nöcher vorbringen: die sind für mich allesamt fadenscheinige Ausreden. Noch dazu, wo Novell, der Sponsor vom Evolution, mal die Suse-Mutter war und Suse DIE KDE-Distro ist... eigentlich sieht das aus meiner "Nutzersicht" richtig übel nach gewaltigem Irrsinn, brutaler Hochnäsigkeit und extremst übersteigertem Ego auf der KDE-Seite aus. Die Zeche zahlt der User. Na schönen Dank auch...
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.
na dann bin ich ja mal gespannt, welche großen Ziele mit dieser Herangehensweise erreicht werden sollten. Hast du diese Ziele verstanden? Kannst du sie erklären?
Was, außer Mails empfangen, Termine und Adressen verwalten soll eine PIM Software können? Welche Aufgaben, von diesen genannten, kann Thunderbird nicht? Wo versagt auch z.B. Evolution? Was ist also das "Shortcoming" all dieser Mailprogramme? Was kann Kmail2 stattdessen, außer sinnlos Festplatte und CPU fressen?
Also... dann stellt sich mir das ganze so dar: wir wollen eine Revolution unter den Mailprogrammen loslassen und bauen uns die super-duper-Maschinerie zusammen... und dann, als sie fertig war, die Super-Mailkiste... dann konnte sie nichtmal Mails empfangen oder senden... wahnsinn... ja, das ist revolutionär.
Ich denke zum Großteil, ja.
Kann ich versuchen
Da wäre mal das Ziel, den gleichzeitigen Zugriff auf Daten zu verbessern. Der vorher benutze Ansatz, aus allen interessierten Applikation parallel auf die selbe(n) Datei(en) zuzugreifen hat immer wieder zu Problemen geführt. Unter anderem weil das dafür nötige Sperren von Dateinzugriffen nicht auf allen Dateisystem (gleich) funktioniert. D.h. es kam schon mal vor, dass zwei Programme ihre Änderungen gegenseitig überschrieben haben.
Der neue Ansatz verbessert dies, in dem nur immer ein Programm auf die Datei direkt zugreift und alle anderen eben mit diesem Dienst kommunizieren.
Dann wäre da weiters das Ziel "Offline" Fähigkeiten für alle Datentypen zur Verfügung zu haben, nicht nur für IMAP E-Mails. Das ist natürlich interessanter für Benutzer, die serverbasierende Adressbücher und Kalendar benutzen und deren Server nicht im selben Netzwerk stehen oder die mobil arbeiten.
Auf der Anwendungsebene ist ein Ziel den Datenzugriff von der Datendarstellung zu trennen. Der Hauptgrund dafür ist, dass vorher bestimmte Funktionalität von Programmen an das Vorhandensein und Ausgeführtwerdens eines anderen Programms abhingen.
Z.B.: die Möglichkeit auf Adressbücher oder Kalendar zuzugreifen, die in speziellen Ordnern auf einem IMAP Server liegen, erforderte bisher das Vorhandensein und Ausgeführtwerden von KMail, weil darin sowohl IMAP Zugriff als auch Anzeige implementiert war.
Das Ausgliedern in einen Dienst erlaubt nun Programmen solche Adressbücher oder Kalendar zu benutzen, ohne dass der Benutzer dafür KMail installiert und laufen haben muss.
Es geht da nicht darum was andere Programme können, sondern ob und wie diese entsprechende Funktionalität für anderen Programme zur Verfügung stellen.
Thunderbird ist daran nicht interessiert und das kann für viele Benutzer auch ausreichend sein. Andere Benutzer brauchen die Möglichkeit auf ihre Daten, z.B. Kontakte, von anderen Programmen nicht nur auf Import-/Exportbasis zuzugreifen.
Aus diesem Grund benutzt Evolution ebenfalls einen dienstbasierten Ansatz (siehe Evolution Data Server), allerdings bis vor kurzem meines Wissens nur für Adressbücher und Kalendar (d.h. Unterstützung für E-Mail ist da auch noch relativ neu).
danke für die Erläuterungen. Klingt alles nach was ziemlich großem... Obwohl ich nicht ganz begreife, warum man nicht wenigstens eine Grundfunktionalität einfach so "normal" darstellen kann und wenn es wirklich DER spezielle Anwendungsfall ist, mit Dateien auf dem Server und was weiß ich - dass man dann und nur dann auf dieses große Gebilde zurückgreift...
Ich meine, die Idee ist ja nicht schlecht (eigentlich verdammt faszinierend), aber man bewegt sich sehr eng an der Kante der Nicht-Akzeptanz. Vor allem bei Fehlern und wenn es kompliziert ist.
Denn es ist nunmal so: der einfache Benutzer begreift nicht, warum er stundenlang am Mailprogramm rumkonfigurieren muss... immer wieder die Meldung, dass irgendeine Migration nicht funktioniert hat und was weiß ich... der will einfach nur Mails lesen und schreiben und seine Kontakte und Termine verwalten... Also all das klingt zwar furchtbar spannend, aber es ist schwer zu vermitteln.
Und wenn man dann immer wieder in Probleme kommt und immer wieder irgendwas nicht funktioniert, dann denkt man als User: "Wisst ihr was, ihr könnt euch euren höheren Zweck sonstwo hinstecken"... das sind dann die Akzeptanzprobleme. Dann kommt das schlechte Imgage... "KDE? Kmail? der Zacker-Kram? nee, lass mal. Da bleib ich lieber beim Win, oder Unity... irgendwas".
Also als User ist man schon fehlertolerant. Ich habe mir zwar kein KDE 4.0 gegeben, aber in der 4er Reihe bin ich seit 4.1 dabei und ich habe viel erlebt. Und ich bin auch verdammt stolz auf KDE, weil es in meinem Fall seit 4.2 einigermaßen gut läuft und auch generell mit jeder Version immer besser geworden ist. Wenn man dann immer wieder mal in irgendwelche Löcher fällt = irgendwas nicht funktioniert, dann ist es bis zu einem bestimmten Maß auch ok. Nur wenn man dann Daten verliert... dann hörts bei mir auf. Und Kmail2 hat mir so manchen Schaden eingebrockt.
Da habe ich kein Verständnis. Auch nicht, wenn eine "große Sache" dahinter steckt. Und auch nicht, wenn es nix kostet.
Meiner Meinung nach gehört ein funktionierendes Mailprogramm zu einem anständigen DE. Heißt: es muss funktionieren. Auch wenn es kompliziert ist: dann ist es eben im Hintergrund kompliziert, aber für den User hat es einfach zu sein. Auch wenn´s geschenkt = gratis ist.
Ich stelle mir auch immer wieder die Frage: warum bastelt KDE denn an einem eigenen PIM? Warum kann man denn nicht meinetwegen Thunderbird nehmen, den ins KDE integrieren und mit Add-ons bedarfsgerecht aufmotzen?
Warum kann man denn z.B. Evolution nicht einfach nehmen und an den entsprechenden Stellen ans KDE anpassen?
Ist doch freie Software... da geht das doch! Liegts am Ego? Am NIH Syndrom? Warum macht man sich diese Arbeit, lässt die Beschimpfungen über sich wegrollen... um dann bei der nächsten Version wieder nix zum Besseren geändert zu haben... traurig.
IMO liegt es an den Distros.
Die stimmen z.B. KDE- und Gnomesoftware einfach nicht aufeinander ab.
Dabei sind selbst z.B. Epiphany-Browser und Evolution hervorragend unter KDE4 nutzbar, gerade wegen des mitinstallierten, funktionsfähigen Gnome-Networkmanagers.
Um den überflüssigen Bloat in Grenzen zu halten, bräuchte man halt durchgehend schlanke kde-, gtk-, qt-, gnome-Basisbibliotheken.
Was nicht passieren darf, ist, dass z.B. Tracker und Nepomuk gleichzeitig herumwerkeln, nur weil mit den entsprechenden Programmen gearbeitet wird. Eine Art Mindestabstimmung zwischen den DEs wäre also in jedem Fall vonnöten.
Und das wäre die Aufgabe der Distros.
Ich denke das Hauptproblem ist den Rahmen von Grundfunktionalität wirklich gut zu stecken. Würde es nur um ein Programm gehen könnte man zum Beispiel den Rahmen so definieren, dass der Zugriff auf lokale Dateien direkt passiert.
Nachdem das aber schon alleine in KDEPIM nicht der Fall ist (z.B. Zugriff auf Kontakte aus Adressbuch, Kalendar und E-Mail Programm) ist der Rahmen von Grundfunktionalität schon mal der gleichzeitige Zugriff auf lokale Dateien.
Bzw. im Falle von E-Mails ist der Zugriff auf Server schon im Rahmen der Grundfunktionalität.
Durch das sehr ähnliche Anforderungsprofil bei GNOME sieht man eigentlich ganz schön, dass man dort auf die selben Techniken setzt, um die nötige Funktionalität umzusetzen. Mozilla hat auf Grund eines einfacheren Profils weniger komplexe Problemstellungen und kann daher andere Wege gehen.
Da gebe ich dir natürlich recht.
Hier hat der Wunsch, den Umstieg von alter zu neuer Technologie möglichst "unsichtbar" zu gestalten, genau zum Gegenteil geführt.
Im Nachhinein betrachtet wäre ein expliziter "import" Prozess besser gewesen. Der hätte von den Benutzer zwar Interaktion erwartet, wäre aber daher auch besser kontrollierbar gewesen.
Ich würde jetzt nicht sagen zu einer DE, das wären eher so Sachen wie Fensterleiste, Desktop, Windowmanager.
Aber durchaus zum Produktumfang eines Herstellers von Endbenutzer-Software für "alle" Basisanwendungsbereiche.
Die einzelnen Programme gibt es einfach schon seit ewig, KMail gab es z.B. schon für KDE1. Im Falle der darunterliegenden Infrastruktur, z.B. dem Adressdateizugriff, weil das einfach von einer Plattform für Endanwendersoftware erwartet wird (und daher z.B. auch Bestandteil jeder Plattform für Mobilgeräte oder proprietärer Desktopplattformen ist).
Ich denke das wäre nicht durchführbar. Thunderbird ist nicht als Komponenten in einem größerem System konzipiert, d.h. es ist vermutlich schwer das Programm ohne GUI zu starten bzw. zu verhindern dass es beendet wird während es von einer anderen Applikation für den Dateizugriff gebraucht wird.
Das ist schon eher machbar, allerdings auch nicht so einfach. Die Kommunikation zwischen Evolution Data Server (EDS) und seinen Clients funktioniert mehr oder weniger über bestimmte Bibliotheken, die zugrunde liegende Kommunikation ist nicht so fixiert und Server und Clientbibliotheken werden bei Bedarf zeitgleich verändert.
Das würde das Bereitstellen von Qt-basierten Clientbibliotheken relativ schwer machen, oder auf Seiten der EDS Entwickler eine Umstellung ihrer Verfahrensweise bedeuten.
Durch die Umstellung bei KDE auf eine ähnliche (dienstbasierte) Architektur und die Erweiterung des Leistungsmfangs bei EDS (+ E-Mail) und die Umstellung auf D-Bus für die interne Kommunikation, ergibt sich schon eine gewisse Konvergenz.
Es ist daher durchaus vorstellbar, dass sich in Folge daraus eine Art von Austauschbarkeit ergibt.
Zitat: "Durch das sehr ähnliche Anforderungsprofil bei GNOME sieht man eigentlich ganz schön, dass man dort auf die selben Techniken setzt, um die nötige Funktionalität umzusetzen. Mozilla hat auf Grund eines einfacheren Profils weniger komplexe Problemstellungen und kann daher andere Wege gehen."
Zitat: "Durch die Umstellung bei KDE auf eine ähnliche (dienstbasierte) Architektur und die Erweiterung des Leistungsmfangs bei EDS (+ E-Mail) und die Umstellung auf D-Bus für die interne Kommunikation, ergibt sich schon eine gewisse Konvergenz.
Es ist daher durchaus vorstellbar, dass sich in Folge daraus eine Art von Austauschbarkeit ergibt."
also, das liest sich ja so wie: "die bei Gnome haben das gleiche gemacht, nur eben auf einige Gnome-spezifische Dinge angepasst" ...
für mich als Nutzer sind hier die augenscheinlichsten Dinge:
- Einbindung in die Desktop-Uhr, zur Terminverwaltung und Benachrichtigung
- Einbindung in das User-Benachrichtigungssystem
- Anbindung an die Netzwerkschnittstelle
- Optik = GUI in GTK
- Diensteverwaltung: D-Bus und Udev
- Anbindung an den Dateimanager fürs speichern von Dokumenten und für "Rechtsklick --> senden per E-mail an..."
Der Unterschied zum Kmail2 ist, dass Evolution erste Sahne funktioniert. Und ich als User frage mich:
- Desktop-Uhr und Benachrichtigungsystem? Hat KDE
- Netzwerkschnittstelle? Hat KDE
- Optik? Qt
- Dateimanager? Hat KDE
- Diensteverwaltung: D-Bus und dieses Udev
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? Doch wegen NIH? Bestimmt. Da bin ich mir jetzt ziemlich sicher.
Ich meine, das mit Thunderbird sehe ich ein, dass das sinnlos wäre, aber bei Evolution... da kann man Argumente noch und nöcher vorbringen: die sind für mich allesamt fadenscheinige Ausreden.
Noch dazu, wo Novell, der Sponsor vom Evolution, mal die Suse-Mutter war und Suse DIE KDE-Distro ist... eigentlich sieht das aus meiner "Nutzersicht" richtig übel nach gewaltigem Irrsinn, brutaler Hochnäsigkeit und extremst übersteigertem Ego auf der KDE-Seite aus. Die Zeche zahlt der User. Na schönen Dank auch...
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.