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
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