Hmm, vielleicht war der Satz ein bischen zu umständlich formuliert.
Ich wollte damit betätigen, dass die im Kommentar von "idiotenpfleger" vorgeschlagene Herangehensweise auch die tatsächlich umgesetzte war.
Im Detail ergab sich eben aus den Erfahrungen mit dem vorherigen Ansatz (gemeinsamer Zugriff auf Dateien mittels Plugins), dass der gemeinsame Datenzugriff über einen Dienst besser geeignet ist, die bestehenden Anforderungen zu erfüllen.
Im Rahmen der Detailüberlegungen wurde dann natürlich auch versucht abzuschätzen, ob damit mögliche zukünftigen Anforderungen ebenfalls abgedeckt werden können. Derartige Szenarien mit hoher Wahrscheinlichkeit wurden dann ählich berücksichtigt, wie bereits bestehende.
Von Idiotenpfleger am Mi, 8. Februar 2012 um 15:57 #
ich kenne mich mit Softwareentwicklung nicht aus. Aber:
- für ein Adressbuch gibts eine Textdatei. Da werden die Kontakte eingespeichert und auch bei Bedarf gelesen. Wozu brauche ich dann ein Plugin oder einen Dienst? Thunderbird hat soweit ich das bemerkt habe, keinen extra-Adressbuch-Dienst
- Kalender: da gibts eine Textdatei. Da werden die Termine eingespeichert und gelesen und wenn ein Datum mit der Systemzeit übereinstimmt, dann poppt ein Fenster auf... Wozu brauche ich da ein Plugin? Einen Dienst vielleicht, aber kein Plugin...
- für die Zugänge beim ISP/Mailprovider... da gibts Textdateien.... und da kann man drauf zugreifen... soll ich weitermachen? Da würde noch ein paar mal "da gibts ne Textdatei" kommen... hmm...
Komisch... bei den anderen funktioniert das jetzt und bestimmt auch in Zukunft. Die grundlegenden Anforderungen ändern sich auch nicht, bei einem Mailprogramm. Die sind nämlich ganz einfach: Mails empfangen und senden. Da kann man natürlich auch eine Raketenwissenschaft draus machen. Muss man aber nicht.
Und wenn man dazu noch irgendwelchen Fancy-Kram basteln will, kann man das gern tun. Aber nicht so, dass die grundlegenden Funktionen nicht mehr erfüllt werden. Oder besser noch, wo man doch so dolle auf Plugins steht: warum nicht den Fancy-Kram als einzelne Plugins machen, die der User dazu-installieren kann, wenn er sie denn braucht? Wohl, weil dann kein User den Fancy Kram installiert? Weil nur eine Minderheit sowas braucht? Und die, die es brauchen, wollen dass es funktioniert? Nee, echt... is ja n Ding!
Ach so ja, dann gibt es noch eine kleine Abhandlung darüber wie der Nutzer das Verhalten dieses ganzen Fremdschäm-Würgs... äh Frameworks sieht:
Akonadi braucht Nepomuk um zu funktionieren. Ergo: Nepomuk abschalten, aber Akonadi nicht = ganz großer Fehler. Also: Akonadi braucht die Suchmaschine. Wohl, um die ganzen Konfig-Dateien und die Dateien fürs Adressbuch auf der Festplatte zu finden. Heißt, für den User: er kann es irgendwo hinspeichern... Akonadi hat ja ne Suchmaschine. FALSCH! Sobald eine Datei nicht dort ist, wo die Durchlaucht Namens Akonadi entschieden hat, dass sie dort liege, gibt es Fehlermeldungen im Windows-Style. Und das hört selbst dann nicht auf, wenn die Datei dann endlich am geforderten Ort liegt. Der User fragt sich dann: wozu läuft da ne Suchmaschine im Hintergrund, die ZWINGEND für den Betrieb von Akonadi vorgeschrieben ist. Die Reaktion des Users, nachdem er sich das mal durch den Kopf gehen ließ, ist: Stilllegen und Deinstallieren, den Müll. Und nicht: "ah, ja ist ja verdammt nochmal ziemlich fancy, das ganze. Da geht was". Denn es geht ja nix.
- für ein Adressbuch gibts eine Textdatei. Da werden die Kontakte eingespeichert und auch bei Bedarf gelesen. Wozu brauche ich dann ein Plugin oder einen Dienst? Thunderbird hat soweit ich das bemerkt habe, keinen extra-Adressbuch-Dienst
Plugins braucht man, wenn man unterschiedliche Formen der Speicherung benutzen will. Das muss nicht für alle Benutzer relevant sein, aber manche Benutzer haben ihre Adressbuchdaten auf einem Server. Ich würde annehmen, dass Thunderbird hier ebenfalls Plugins benutzt, Evolution tut es.
Ein Dienst hilft dabei, den Zugriff mehrere Programme auf die selben Daten zu regeln. Das muss ebenfalls nicht für alle Benutzer relevant sein, aber manche Benutzer benutzen ihre Kontakte auch außerhab ihres E-Mail Programms. Thunderbird operiert unter der Annahme, dass es das einzige Programm ist, dass mit seiner Adressbuchdatei arbeitet. Evolution setzt ebenfalls auf einen Dienst.
- Kalender: da gibts eine Textdatei. Da werden die Termine eingespeichert und gelesen und wenn ein Datum mit der Systemzeit übereinstimmt, dann poppt ein Fenster auf... Wozu brauche ich da ein Plugin? Einen Dienst vielleicht, aber kein Plugin...
Da gilt im Wesentlich das selbe, d.h. Plugin wenn man bestimmte Arten der Speicherung und die dafür nötigen Abhängigkeiten nur optional haben möchte und Dienst wenn man die Daten in mehreren Anwendungen gleichzeitig haben möchte. Bei Thunderbird bzw Lightning muss ich raten, aber ich würde von Pluginunterstützung ausgehen. Bei Evolution ist Pluginunterstützung und Dienst im Einsatz.
- für die Zugänge beim ISP/Mailprovider... da gibts Textdateien.... und da kann man drauf zugreifen... soll ich weitermachen? Da würde noch ein paar mal "da gibts ne Textdatei" kommen... hmm... :huh:
Siehe oben. Die Bestrebungen bei Evolution den E-Mail-Zugriff aus der Applikation auch in den Dienst zu verlagern dürfte da ein gutes Indiz sein.
Akonadi braucht Nepomuk um zu funktionieren.
Wäre vielleicht besser gewesen, die Abhängigkeit in allen Applikationen einzubauen, statt im gemeinsamen Dienst. Die Idee war hier, dass die Suche nach PIM Dateien über die selbe API wie der Zugriff auf diese einfacher für Applikationsentwickler ist, als wenn diese dann mit zwei APIs arbeiten müssen.
Wohl, um die ganzen Konfig-Dateien und die Dateien fürs Adressbuch auf der Festplatte zu finden
Nein. Suche nach Dateien ist nur ein Teilaspekt von Nepomuk, in diesem Zusammenhang geht es um das Suche von und in PIM Daten. Zum Beispiel das Auflösen von Adressreferenzen in Kalendereinträgen, automatische Vervollständigung von E-Mail Adressen in Empfängereingabefeldern, das Suchen von E-Mails, etc.
Wie gesagt hätte man das auch an die Anwendungsentwickler schieben können, ein integrierter und einheitlicher Ansatz schien da einfach besser.
IMO fehlen aber die entsprechenden Kennzeichnungen wie Kmail2-Alpha3 oder Kmail2-Beta1, damit auch der Nutzer, der keine Mailinglisten mitliest, weiß, woran er ist. Kmail in KDE 4.7 ist wirklich nicht fertig, es ist keine finale, sondern eine verbuggte Vor-Version. Das muss man auch so kommunizieren.
Ich kann dir da nicht ganz folgen.
Hmm, vielleicht war der Satz ein bischen zu umständlich formuliert.
Ich wollte damit betätigen, dass die im Kommentar von "idiotenpfleger" vorgeschlagene Herangehensweise auch die tatsächlich umgesetzte war.
Im Detail ergab sich eben aus den Erfahrungen mit dem vorherigen Ansatz (gemeinsamer Zugriff auf Dateien mittels Plugins), dass der gemeinsame Datenzugriff über einen Dienst besser geeignet ist, die bestehenden Anforderungen zu erfüllen.
Im Rahmen der Detailüberlegungen wurde dann natürlich auch versucht abzuschätzen, ob damit mögliche zukünftigen Anforderungen ebenfalls abgedeckt werden können.
Derartige Szenarien mit hoher Wahrscheinlichkeit wurden dann ählich berücksichtigt, wie bereits bestehende.
ich kenne mich mit Softwareentwicklung nicht aus. Aber:
- für ein Adressbuch gibts eine Textdatei. Da werden die Kontakte eingespeichert und auch bei Bedarf gelesen. Wozu brauche ich dann ein Plugin oder einen Dienst? Thunderbird hat soweit ich das bemerkt habe, keinen extra-Adressbuch-Dienst
- Kalender: da gibts eine Textdatei. Da werden die Termine eingespeichert und gelesen und wenn ein Datum mit der Systemzeit übereinstimmt, dann poppt ein Fenster auf... Wozu brauche ich da ein Plugin? Einen Dienst vielleicht, aber kein Plugin...
- für die Zugänge beim ISP/Mailprovider... da gibts Textdateien.... und da kann man drauf zugreifen... soll ich weitermachen? Da würde noch ein paar mal "da gibts ne Textdatei" kommen... hmm...
Komisch... bei den anderen funktioniert das jetzt und bestimmt auch in Zukunft. Die grundlegenden Anforderungen ändern sich auch nicht, bei einem Mailprogramm. Die sind nämlich ganz einfach: Mails empfangen und senden.
Da kann man natürlich auch eine Raketenwissenschaft draus machen. Muss man aber nicht.
Und wenn man dazu noch irgendwelchen Fancy-Kram basteln will, kann man das gern tun. Aber nicht so, dass die grundlegenden Funktionen nicht mehr erfüllt werden. Oder besser noch, wo man doch so dolle auf Plugins steht: warum nicht den Fancy-Kram als einzelne Plugins machen, die der User dazu-installieren kann, wenn er sie denn braucht? Wohl, weil dann kein User den Fancy Kram installiert? Weil nur eine Minderheit sowas braucht? Und die, die es brauchen, wollen dass es funktioniert? Nee, echt... is ja n Ding!
Ach so ja, dann gibt es noch eine kleine Abhandlung darüber wie der Nutzer das Verhalten dieses ganzen Fremdschäm-Würgs... äh Frameworks sieht:
Akonadi braucht Nepomuk um zu funktionieren. Ergo: Nepomuk abschalten, aber Akonadi nicht = ganz großer Fehler.
Also: Akonadi braucht die Suchmaschine. Wohl, um die ganzen Konfig-Dateien und die Dateien fürs Adressbuch auf der Festplatte zu finden. Heißt, für den User: er kann es irgendwo hinspeichern... Akonadi hat ja ne Suchmaschine. FALSCH!
Sobald eine Datei nicht dort ist, wo die Durchlaucht Namens Akonadi entschieden hat, dass sie dort liege, gibt es Fehlermeldungen im Windows-Style. Und das hört selbst dann nicht auf, wenn die Datei dann endlich am geforderten Ort liegt.
Der User fragt sich dann: wozu läuft da ne Suchmaschine im Hintergrund, die ZWINGEND für den Betrieb von Akonadi vorgeschrieben ist. Die Reaktion des Users, nachdem er sich das mal durch den Kopf gehen ließ, ist: Stilllegen und Deinstallieren, den Müll. Und nicht: "ah, ja ist ja verdammt nochmal ziemlich fancy, das ganze. Da geht was". Denn es geht ja nix.
Plugins braucht man, wenn man unterschiedliche Formen der Speicherung benutzen will. Das muss nicht für alle Benutzer relevant sein, aber manche Benutzer haben ihre Adressbuchdaten auf einem Server. Ich würde annehmen, dass Thunderbird hier ebenfalls Plugins benutzt, Evolution tut es.
Ein Dienst hilft dabei, den Zugriff mehrere Programme auf die selben Daten zu regeln. Das muss ebenfalls nicht für alle Benutzer relevant sein, aber manche Benutzer benutzen ihre Kontakte auch außerhab ihres E-Mail Programms.
Thunderbird operiert unter der Annahme, dass es das einzige Programm ist, dass mit seiner Adressbuchdatei arbeitet. Evolution setzt ebenfalls auf einen Dienst.
Da gilt im Wesentlich das selbe, d.h. Plugin wenn man bestimmte Arten der Speicherung und die dafür nötigen Abhängigkeiten nur optional haben möchte und Dienst wenn man die Daten in mehreren Anwendungen gleichzeitig haben möchte.
Bei Thunderbird bzw Lightning muss ich raten, aber ich würde von Pluginunterstützung ausgehen. Bei Evolution ist Pluginunterstützung und Dienst im Einsatz.
Siehe oben. Die Bestrebungen bei Evolution den E-Mail-Zugriff aus der Applikation auch in den Dienst zu verlagern dürfte da ein gutes Indiz sein.
Wäre vielleicht besser gewesen, die Abhängigkeit in allen Applikationen einzubauen, statt im gemeinsamen Dienst. Die Idee war hier, dass die Suche nach PIM Dateien über die selbe API wie der Zugriff auf diese einfacher für Applikationsentwickler ist, als wenn diese dann mit zwei APIs arbeiten müssen.
Nein. Suche nach Dateien ist nur ein Teilaspekt von Nepomuk, in diesem Zusammenhang geht es um das Suche von und in PIM Daten. Zum Beispiel das Auflösen von Adressreferenzen in Kalendereinträgen, automatische Vervollständigung von E-Mail Adressen in Empfängereingabefeldern, das Suchen von E-Mails, etc.
Wie gesagt hätte man das auch an die Anwendungsentwickler schieben können, ein integrierter und einheitlicher Ansatz schien da einfach besser.
IMO fehlen aber die entsprechenden Kennzeichnungen wie Kmail2-Alpha3 oder Kmail2-Beta1, damit auch der Nutzer, der keine Mailinglisten mitliest, weiß, woran er ist.
Kmail in KDE 4.7 ist wirklich nicht fertig, es ist keine finale, sondern eine verbuggte Vor-Version.
Das muss man auch so kommunizieren.