Exchange-Integration ist in unserem Geschäft die letzte Bastion. Dann könnte ich theoretisch einen Windows-Desktop komplett mit einer Linux-Maschine ersetzen.
Das sich endlich mal jemand dem Exchange Problem unter KDE widmet ist eine Klasse Sache, spenden werde ich also auf jeden Fall.
Warum aber muss wieder so dermaßen rumgefrickelt werden? Ist KMail der Weisheit letzter Schluss? Sicher Nicht!
Aber einen neuen E-Mail Client zu bauen, der dann für den Enduser auch wieder nutzlos ist weil er dringend benötigte Features nicht unterstützt, ist absolut sinnlos. Toll das wir dann eine Library haben, die theoretisch in jeden beliebigen Client eingebaut werden kann. Dem Enduser bringt das nur rein gar nichts, so lange sich nicht jemand findet, der das dann auch in KMail einbaut oder eben den neuen E-Mail Client zu einer vernünftigen E-Mail-Lösung ausbaut.
Resultat dieses Projekts ist also eine Library und zwei Mail Clients die beide nicht richtig mit Exchange sprechen können. Der eine kann ein bisschen, der andere gar nicht.
Einen vernünftigen E-Mail Client zu schreiben ist einfach kein 1-Mann Projekt. Da wird nie was vernünftiges rauskommen! Im Moment haben wir KMail, der bereits Jahre gebraucht hat um wieder benutzbar zu werden. Aber nein, da kommt der nächste Entwickler und meint er muss alles von vorne beginnen. In 10 Jahren können die Enduser also ca. mit vollständigen Exchange-Support rechnen - falls dann noch jemand Exchange nutzt und nicht alles bereits in der Cloud liegt.
Toll das wir dann eine Library haben, die theoretisch in jeden beliebigen Client eingebaut werden kann. Dem Enduser bringt das nur rein gar nichts, so lange sich nicht jemand findet, der das dann auch in KMail einbaut oder eben den neuen E-Mail Client zu einer vernünftigen E-Mail-Lösung ausbaut.
Ist eine solche Library überhaupt erforderlich? Es gibt mit openchange eine solche doch schon. Darauf eine Akonadi-Resource aufzusetzen, kann so schwer eigentlich auch nicht sein.
Einen vernünftigen E-Mail Client zu schreiben ist einfach kein 1-Mann Projekt. Da wird nie was vernünftiges rauskommen! Im Moment haben wir KMail, der bereits Jahre gebraucht hat um wieder benutzbar zu werden. Aber nein, da kommt der nächste Entwickler und meint er muss alles von vorne beginnen. In 10 Jahren können die Enduser also ca. mit vollständigen Exchange-Support rechnen - falls dann noch jemand Exchange nutzt und nicht alles bereits in der Cloud liegt.
Das typische OpenSource Problem halt. Jeder ist der Meinung er kann es besser als seine Vorgänger und fängt daher wieder von vorne an. Von Zusammenarbeit mal wieder keine Spur.
Wir haben 2013 und KDE hat immer noch keinen vernünftigen Mail Client!
Soweit ich den Blogeintrag verstanden habe ist das hier nicht der Fall.
Zwar ist im Ziel die Entwicklung eines Frontends beinhaltet, aber es geht in erster Linie um die Entwicklung einer Qt Bibliothek für den Zugriff auf EWS. Mir wäre jetzt nicht bekannt, dass eine derartige Bibliothek bereits existiert, der Autor also die Möglichkeit hätte, dort mit zu arbeiten.
Wir haben 2013 und KDE hat immer noch keinen vernünftigen Mail Client!
KDE ist zwar einer der Softwarehersteller der einen Mail Client in seinem Produktportfolio hat, aber wenn dir der nicht zusagt gibt es andere Hersteller die ebenfalls ein Produkt in dieser Kategorie haben.
Inwiefern das etwas mit 2013 zu tun hat entzieht sich allerdings meinem Verständnis. Soweit mir bekannt gibt es keine Anforderung dass alle Hersteller überhaupt einen Mail Client anbieten müssen.
Zwar ist im Ziel die Entwicklung eines Frontends beinhaltet, aber es geht in erster Linie um die Entwicklung einer Qt Bibliothek für den Zugriff auf EWS. Mir wäre jetzt nicht bekannt, dass eine derartige Bibliothek bereits existiert, der Autor also die Möglichkeit hätte, dort mit zu arbeiten.
Genau um das Frontend geht es ja bei der Kritik des OPs. Darauf habe auch ich mich bezogen. Die Library ist ja schön und gut, aber ich bezweifle, dass er es in 2 Monaten schafft eine Library UND das Frontend voranzubringen. Beides wird nur halb fertig werden.
Anstatt sich also voll auf die Library zu konzentrieren, entwickelt er lieber noch nebenher seinen eigenen Mail Cient anstatt auf bestehende Lösungen zu setzen. Was da innerhalb von 2 Monaten rauskommen kann, weiß jeder der schon mal ein paar Zeilen programmiert hat. Nichts vernünftiges auf jeden Fall.
KDE ist zwar einer der Softwarehersteller der einen Mail Client in seinem Produktportfolio hat, aber wenn dir der nicht zusagt gibt es andere Hersteller die ebenfalls ein Produkt in dieser Kategorie haben.
Wenn man Groupware-Funktionalität möchte, dann gibt es eigentlich nur die Wahl zwischen Evolution und KMail. Das ist die Wahl zwischen Pest und Cholera.
Inwiefern das etwas mit 2013 zu tun hat entzieht sich allerdings meinem Verständnis. Soweit mir bekannt gibt es keine Anforderung dass alle Hersteller überhaupt einen Mail Client anbieten müssen.
Du musst KDE Entwickler sein. Für jeden normalen Menschen ist es einfach nicht nachvollziehbar, dass ein derartige Basisapplikation, die eigentlich von jedem Benutzer täglich benötigt wird, so dermaßen vernachlässigt wird und im Jahre 2013 immer noch nicht vernünftig läuft.
Genau um das Frontend geht es ja bei der Kritik des OPs. Darauf habe auch ich mich bezogen. Die Library ist ja schön und gut, aber ich bezweifle, dass er es in 2 Monaten schafft eine Library UND das Frontend voranzubringen. Beides wird nur halb fertig werden.
Hmm, das ist natürlich ein möglicher Ausgang. Kann aber auch sein, dass das Frontend mehr dazu dient, den Funktionsumfang der Bibliothek zu gewährleisten. Es kann dazu viel einfach gestaltet sein als ein "volles" Produkt, aber schnellere Entwicklungszyklen erlauben als das Einbauen und Testen in einer komplexeren und fremden Codebasis.
Bin zwar auch skeptisch aber mit Sicherheit kann man zu diesem Zeitpunkt einfach noch nichts sagen.
Wenn man Groupware-Funktionalität möchte, dann gibt es eigentlich nur die Wahl zwischen Evolution und KMail.
Ja, aber Mail Clients gibt es von mehreren Herstellern.
Für jeden normalen Menschen ist es einfach nicht nachvollziehbar, dass ein derartige Basisapplikation, die eigentlich von jedem Benutzer täglich benötigt wird, so dermaßen vernachlässigt wird und im Jahre 2013 immer noch nicht vernünftig läuft.
Für mich ist nicht ganz nachvollziehbar wie das Entfernen des Programms aus dem Produktportfolio den Benutzern helfen würde. Weil sich die Benutzer dann gezwungenermaßen an einem anderen Hersteller wenden müssen?
Sofern mir bekannt ist wird diese Möglichkeit auch ohne Zwang benutzt, aber in Anbetracht der von dir oben angeführten Einsicht, dass im Bereich Groupware Client dann nur ein Produkt zur Auswahl stehen würde, würde ich das eher als Verschlechterung der Situation sehen.
Man kann natürlich spekulieren, dass durch den Wegfall eines Herstellers ein Neuer aufkommt, aber das halte ich dann doch auch für sehr unwahrscheinlich.
Hmm, das ist natürlich ein möglicher Ausgang. Kann aber auch sein, dass das Frontend mehr dazu dient, den Funktionsumfang der Bibliothek zu gewährleisten. Es kann dazu viel einfach gestaltet sein als ein "volles" Produkt, aber schnellere Entwicklungszyklen erlauben als das Einbauen und Testen in einer komplexeren und fremden Codebasis.
Da glaube ich, ähnlich wie lokis, auch nicht dran. Wenn man eine derartige Library testen möchte, dann macht man das mit Unit-Tests. Die kann man automatisiert gegen verschiedene Server laufen lassen, Stichwort: Continuous Integration.
Das geht natürlich nicht mit jeder Library, aber in diesem speziellen Fall sind Unit Tests gar kein Problem. Ein GUI zu schreiben, nur um die Library testen zu können, ist einfach ein Wahnsinn. Ich glaube auch, dass Nicoletti hier versucht seinen Mail-Client voranzubringen. Zwei Monate sind allerdings viel zu wenig - das reicht noch nicht einmal um die Library vernünftig zu bauen und zu testen.
Wenn man eine derartige Library testen möchte, dann macht man das mit Unit-Tests.
Ja und nein. Unittest sind natürlich wichtig, aber speziell die Kommunikation mit einem echten Server ist auf einem höheren Level.
Das muss natürlich keine GUI sein, bzw sollte es am Ende auch nicht, eben wegen dem automatischen Testen, aber während der Entwicklung kann es sehr nützlich sein mal schnell was ausprobieren zu können ohne dieses Experiement in Code gießen zu müssen.
ch glaube auch, dass Nicoletti hier versucht seinen Mail-Client voranzubringen.
Ja, da gebe ich dir Recht.
Zwei Monate sind allerdings viel zu wenig - das reicht noch nicht einmal um die Library vernünftig zu bauen und zu testen.
Hmm, ja, hängt halt vom Funktionsumfang ab und in welchem Format die E-Mails über dieses Webserviceinterface übertragen werden. Wie gesagt bin ich auch eher skeptisch, aber man wird ja sehen
Das ist ja auch wie gesagt fast immer der Fall. Nur wenige Ausnahmen haben deratige Abhängigkeiten und die meisten davon sind Teil des jeweiligen Desktops.
Die Antwort bekommst du im Beitrag. Der Gnome kann mit Exchange wohl umgehen und Kde nicht.
Generell habe ich das gefühl das KDE seit Jahren auf der Stelle tritt. 3D ist zwar schön, aber alles funktioniert irgendwie auch Rudimentär. Beim Gnome hat man sich ein Ziel gesetzt und verfolgt es konsequent. Vieles ist mittlerweile gut implementiert, zb. mit Google Diensten und Diensten von Microsoft. Ich kann sehr einfach ohne bastelei, einrichten und benutzen. KDE besitzt irgendwie gar kein Konzept, vieles ist nicht fertig, vieles ist kaputt.
Aber ich kenne mich damit auch nicht aus, wie es bei ihnen so abläuft. So vom Eindruck eines Außenstehenden her, ist KDE mittlerweile nicht gerade berauschend geworden.
Exchange-Integration ist in unserem Geschäft die letzte Bastion. Dann könnte ich theoretisch einen Windows-Desktop komplett mit einer Linux-Maschine ersetzen.
Mit 10$ dabei..
Exange Integration ist mehr als nur Email und Kontakte. Leider sind Aufgaben und Termine bereits ausgeschlossen :-/
Das sich endlich mal jemand dem Exchange Problem unter KDE widmet ist eine Klasse Sache, spenden werde ich also auf jeden Fall.
Warum aber muss wieder so dermaßen rumgefrickelt werden? Ist KMail der Weisheit letzter Schluss? Sicher Nicht!
Aber einen neuen E-Mail Client zu bauen, der dann für den Enduser auch wieder nutzlos ist weil er dringend benötigte Features nicht unterstützt, ist absolut sinnlos. Toll das wir dann eine Library haben, die theoretisch in jeden beliebigen Client eingebaut werden kann. Dem Enduser bringt das nur rein gar nichts, so lange sich nicht jemand findet, der das dann auch in KMail einbaut oder eben den neuen E-Mail Client zu einer vernünftigen E-Mail-Lösung ausbaut.
Resultat dieses Projekts ist also eine Library und zwei Mail Clients die beide nicht richtig mit Exchange sprechen können. Der eine kann ein bisschen, der andere gar nicht.
Einen vernünftigen E-Mail Client zu schreiben ist einfach kein 1-Mann Projekt. Da wird nie was vernünftiges rauskommen! Im Moment haben wir KMail, der bereits Jahre gebraucht hat um wieder benutzbar zu werden. Aber nein, da kommt der nächste Entwickler und meint er muss alles von vorne beginnen. In 10 Jahren können die Enduser also ca. mit vollständigen Exchange-Support rechnen - falls dann noch jemand Exchange nutzt und nicht alles bereits in der Cloud liegt.
Ist eine solche Library überhaupt erforderlich? Es gibt mit openchange eine solche doch schon. Darauf eine Akonadi-Resource aufzusetzen, kann so schwer eigentlich auch nicht sein.
Angefangen wurde damit zumindest schon:
https://projects.kde.org/projects/playground/pim/akonadi-exchange
Openchange verfolgt einen anderen Ansatz nämlich direkte Kommuniktion mit Exchange in seinem nativen Protokoll.
Das typische OpenSource Problem halt. Jeder ist der Meinung er kann es besser als seine Vorgänger und fängt daher wieder von vorne an. Von Zusammenarbeit mal wieder keine Spur.
Wir haben 2013 und KDE hat immer noch keinen vernünftigen Mail Client!
Soweit ich den Blogeintrag verstanden habe ist das hier nicht der Fall.
Zwar ist im Ziel die Entwicklung eines Frontends beinhaltet, aber es geht in erster Linie um die Entwicklung einer Qt Bibliothek für den Zugriff auf EWS.
Mir wäre jetzt nicht bekannt, dass eine derartige Bibliothek bereits existiert, der Autor also die Möglichkeit hätte, dort mit zu arbeiten.
KDE ist zwar einer der Softwarehersteller der einen Mail Client in seinem Produktportfolio hat, aber wenn dir der nicht zusagt gibt es andere Hersteller die ebenfalls ein Produkt in dieser Kategorie haben.
Inwiefern das etwas mit 2013 zu tun hat entzieht sich allerdings meinem Verständnis. Soweit mir bekannt gibt es keine Anforderung dass alle Hersteller überhaupt einen Mail Client anbieten müssen.
Genau um das Frontend geht es ja bei der Kritik des OPs. Darauf habe auch ich mich bezogen. Die Library ist ja schön und gut, aber ich bezweifle, dass er es in 2 Monaten schafft eine Library UND das Frontend voranzubringen. Beides wird nur halb fertig werden.
Anstatt sich also voll auf die Library zu konzentrieren, entwickelt er lieber noch nebenher seinen eigenen Mail Cient anstatt auf bestehende Lösungen zu setzen. Was da innerhalb von 2 Monaten rauskommen kann, weiß jeder der schon mal ein paar Zeilen programmiert hat. Nichts vernünftiges auf jeden Fall.
Wenn man Groupware-Funktionalität möchte, dann gibt es eigentlich nur die Wahl zwischen Evolution und KMail. Das ist die Wahl zwischen Pest und Cholera.
Du musst KDE Entwickler sein. Für jeden normalen Menschen ist es einfach nicht nachvollziehbar, dass ein derartige Basisapplikation, die eigentlich von jedem Benutzer täglich benötigt wird, so dermaßen vernachlässigt wird und im Jahre 2013 immer noch nicht vernünftig läuft.
Hmm, das ist natürlich ein möglicher Ausgang. Kann aber auch sein, dass das Frontend mehr dazu dient, den Funktionsumfang der Bibliothek zu gewährleisten. Es kann dazu viel einfach gestaltet sein als ein "volles" Produkt, aber schnellere Entwicklungszyklen erlauben als das Einbauen und Testen in einer komplexeren und fremden Codebasis.
Bin zwar auch skeptisch aber mit Sicherheit kann man zu diesem Zeitpunkt einfach noch nichts sagen.
Ja, aber Mail Clients gibt es von mehreren Herstellern.
Für mich ist nicht ganz nachvollziehbar wie das Entfernen des Programms aus dem Produktportfolio den Benutzern helfen würde.
Weil sich die Benutzer dann gezwungenermaßen an einem anderen Hersteller wenden müssen?
Sofern mir bekannt ist wird diese Möglichkeit auch ohne Zwang benutzt, aber in Anbetracht der von dir oben angeführten Einsicht, dass im Bereich Groupware Client dann nur ein Produkt zur Auswahl stehen würde, würde ich das eher als Verschlechterung der Situation sehen.
Man kann natürlich spekulieren, dass durch den Wegfall eines Herstellers ein Neuer aufkommt, aber das halte ich dann doch auch für sehr unwahrscheinlich.
Da glaube ich, ähnlich wie lokis, auch nicht dran. Wenn man eine derartige Library testen möchte, dann macht man das mit Unit-Tests. Die kann man automatisiert gegen verschiedene Server laufen lassen, Stichwort: Continuous Integration.
Das geht natürlich nicht mit jeder Library, aber in diesem speziellen Fall sind Unit Tests gar kein Problem. Ein GUI zu schreiben, nur um die Library testen zu können, ist einfach ein Wahnsinn. Ich glaube auch, dass Nicoletti hier versucht seinen Mail-Client voranzubringen. Zwei Monate sind allerdings viel zu wenig - das reicht noch nicht einmal um die Library vernünftig zu bauen und zu testen.
Ja und nein. Unittest sind natürlich wichtig, aber speziell die Kommunikation mit einem echten Server ist auf einem höheren Level.
Das muss natürlich keine GUI sein, bzw sollte es am Ende auch nicht, eben wegen dem automatischen Testen, aber während der Entwicklung kann es sehr nützlich sein mal schnell was ausprobieren zu können ohne dieses Experiement in Code gießen zu müssen.
Ja, da gebe ich dir Recht.
Hmm, ja, hängt halt vom Funktionsumfang ab und in welchem Format die E-Mails über dieses Webserviceinterface übertragen werden.
Wie gesagt bin ich auch eher skeptisch, aber man wird ja sehen
Warum für KDE? Warum nicht Destopunabhängig?
Das ist mit sicherheit desktopunabhängig, selbst die meisten Programme von KDE sind unabhängig vom Workspaceprodukt des selben Herstellers.
Aber generell, warum ist sowas nicht desktopunabhängig, egal ob Gnome, KDE oder was auch immer?
Das ist ja auch wie gesagt fast immer der Fall. Nur wenige Ausnahmen haben deratige Abhängigkeiten und die meisten davon sind Teil des jeweiligen Desktops.
Die Antwort bekommst du im Beitrag. Der Gnome kann mit Exchange wohl umgehen und Kde nicht.
Generell habe ich das gefühl das KDE seit Jahren auf der Stelle tritt. 3D ist zwar schön, aber alles funktioniert irgendwie auch Rudimentär. Beim Gnome hat man sich ein Ziel gesetzt und verfolgt es konsequent. Vieles ist mittlerweile gut implementiert, zb. mit Google Diensten und Diensten von Microsoft. Ich kann sehr einfach ohne bastelei, einrichten und benutzen. KDE besitzt irgendwie gar kein Konzept, vieles ist nicht fertig, vieles ist kaputt.
Aber ich kenne mich damit auch nicht aus, wie es bei ihnen so abläuft. So vom Eindruck eines Außenstehenden her, ist KDE mittlerweile nicht gerade berauschend geworden.
Ich glaube kaum, dass ein Entwickler alles
von Grund auf selbst programmieren kann.
Ich schätze, dass er auf Technologien von OpenChange.org setzt.
Es wäre interessant zu erfahren, ob das so ist...
Soweit ich das verstanden habe wählt er einen anderen Ansatz, den Weg über die Webservice API von Exchange.
...nimmt DavMail. Und zwar mit jedem beliebigen E-Mail-Client und nicht nur für E-Mails.