Ja, wir haben Z-Push unter der AGPL integriert indem wir ein Kolab-Backend unter der AGPL mit Übertragung der Rechte an die FSFE implementiert haben. Insofern ist es für die Datenhaltung der Nutzer unbedenklich und es werden keine proprietären Abhängigkeiten geschaffen.
Da der hinter Z-Push stehende Prozess aber in der Tat nicht offen und Z-Push selber bei Zarafa dual-lizenziert wird, sind wir mit der Situation auch nicht vollkommen zufrieden. Hoffe ich kann dazu in den nächsten Wochen mehr sagen.
Schade, dass man nicht weiter auf OpenPKG gesetzt hat. Das vereinfachte vieles: Für ein Backup braucht man einfach nur /kolab sichern und fertig. Und man kann die gesamte Installation sogar von einer Distribution auf die nächste mitnehmen, ohne sich um viel zu kümmern (nur die Einträge in passwd und groups und ein Startskript). Das habe ich selbst mehrmals gemacht und fand es äußerst praktisch und bequem.
Hintergrund zu der Entscheidung gibt es übrigens unter http://blogs.fsfe.org/greve/?p=519
Letztlich ist OpenPKG sehr arbeitsintensiv und statisch, und war bei den meisten Nutzern sehr unbeliebt weil sie noch ein neues Paketsystem lernen mussten das ausser Kolab niemand eingesetzt hat. Als es dann noch proprietär wurde, war der Zug für uns endgültig abgefahren.
Daher wurde im November/Dezember 2009 klar, dass wir uns davon verabschieden würden.
Natürlich hatte es auch seine praktischen Seiten, aber die Nachteile haben halt doch überwogen.
Ja, ich weiß, ich kenne die Gründe und es ging halt nicht anders. Eigentlich war schon früh klar, dass Kolab da allein auf weiter Flur steht. Trotzdem hat es die Arbeit vereinfacht, eben weil man sicht nicht um die Distribution kümmern musste. Ich habe zwei Installationen von Suse zu Fedora und schließlich Debian umgezogen und das mit nicht mehr als tar über ssh. Das geht jetzt leider nicht mehr so leicht. Die Aktualität gerade bei Sicherheitsproblemen macht das dann aber wieder wett.
Die Aktualität gerade bei Sicherheitsproblemen macht das dann aber wieder wett.
Und man kann jetzt Pakete der Distribution installieren, die Kolab-Komponenten in ihren Abhängigkeiten haben. Das war mit OpenPKG auch nicht einfach möglich. Ich trauere OpenPKG nicht nach ;o)
Verwendet Kolab ein eigenes Protokoll für Kalender (statt CalDAV) & Kontakte (statt CardDav) ? Hat man etwas neues geschaffen um dem offenen Standarts zu konkurieren?
Oder hat man einfach die Protokolle neu implementiert statt DaviCal zu verwenden?
IMAP ist ein extrem weit verbreiteter Standard, würde ich mal behaupten. Dasselbe gilt für die anderen in Kolab verwendeten Protokolle.
Kolab gibt es schon länger als CalDAV & CardDAV. Es hat in Version 1 auch genau dasselbe getan: iCal & vCard in XML abgespeichert und übertragen. Allerdings hat man dann in der Praxis gesehen, dass die Implementationen unterschiedlicher Anbieter so weit voneinander abwichen, dass es häufig Probleme gab. Daher hatte Version 2 ein eigenes XML Format offen spezifiziert, welches ein kanonisches Speicherformat, und eben kein Übertragungsformat wie iCal & vCard ist.
Dann kamen CalDav & CardDAV mit derselben Idee, und laufen jetzt in ähnliche Probleme wie Kolab Version 1: So lange nur ein Klient oder Klienten eines Anbieters zugreifen ist es kein Problem. Sobald die Welt aber heterogen und mit gemeinsam genutzen Resourcen wird, gibt es Probleme.
Mit der Veröffentlichung von xCard & xCal im August 2011 wird das Kolab Format Version 3 übrigens darauf aufbauen -- allerdings mit ein paar Einschränkungen in der Art und Weise, wie die Standards benutzt werden sollen, um sie in ein kanonisches Format zu bringen, denn leider sind auch diese RFCs eher auf den Transport ausgerichtet und erlauben unterschiedliche Abbildungen desselben Problems. Somit ist alles, was Kolab schreibt zu 100% RFC konform. Um das dann noch einfacher zu machen, wird mit der libkolab eine Bibliothek für Klienten zur Verfügung stehen.
DaviCal ist natürlich um Ecken jünger als Kolab, und einer unserer Partner hatte es auch mal an Kolab angebunden. Leider ist es relativ stark Spaghetti-Code und nicht auf verschiedene Backends in der Datenhaltung ausgerichtet, daher ist das auf Dauer kein gangbarer Weg.
Wir rechnen damit, irgendwann in der 3.X Serie CalDAV & CardDAV hinzuzufügen, aber dafür muss eine entsprechende serverseitige Übersetzung für die verschiedenen Klienten gemacht werden, um nicht in die Probleme zu rennen die man sonst in grossen heterogenen Umgebungen bekommt.
Das und einiges mehr hätte man übrigens auch schnell finden können:
Ich wage es kaum zu erwähnen. Gibt es ein System am Markt (OS) mit dem ich mailen, Aufgaben verwalten kann und einen Kalender habe. Ein System auf das mehrere Leute zugreifen können? Ein System das ich mit meinem Android vielleicht syncen kann und zwar mind. alle drei genannten? 1997 funktionierte das mit meinen Casio (Handheld ;). Seitdem warte ich auf was neues. Sozusagen eine Killerapp die mal funktioniert. Das hat noch keiner geschafft. Oder irre ich mich, vielleicht zarafa???
Wobei Android als Plattform keine Aufgaben unterstützt, soweit ich weiss. Das könnte aber einer der ActiveSync Klienten von Drittanbietern mit drin haben.
Ja, es war leider sehr viel Arbeit, den OpenPKG entsprechend auseinander zu nehmen und dabei die technische Arbeit zu machen. Hat länger gedauert als es auch uns recht war.
Du wärest uns aber herzlich wieder willkommen, wenn Du noch Motivation aufbringen kannst.
Gerade nach Debian Entwicklern suchen wir im Moment auf allen Ebenen und Seiten.
... ist das nicht von Zarafa ?
Aber ja, ist ja AGPL und so von jedermann nutzbar. Trotzdem cool
für Zarafa - so hat jeder Kolab Nutzer Zarafa Technologie on Board.
Ja, wir haben Z-Push unter der AGPL integriert indem wir ein Kolab-Backend unter der AGPL mit Übertragung der Rechte an die FSFE implementiert haben. Insofern ist es für die Datenhaltung der Nutzer unbedenklich und es werden keine proprietären Abhängigkeiten geschaffen.
Da der hinter Z-Push stehende Prozess aber in der Tat nicht offen und Z-Push selber bei Zarafa dual-lizenziert wird, sind wir mit der Situation auch nicht vollkommen zufrieden. Hoffe ich kann dazu in den nächsten Wochen mehr sagen.
Schade, dass man nicht weiter auf OpenPKG gesetzt hat. Das vereinfachte vieles: Für ein Backup braucht man einfach nur /kolab sichern und fertig. Und man kann die gesamte Installation sogar von einer Distribution auf die nächste mitnehmen, ohne sich um viel zu kümmern (nur die Einträge in passwd und groups und ein Startskript). Das habe ich selbst mehrmals gemacht und fand es äußerst praktisch und bequem.
Hintergrund zu der Entscheidung gibt es übrigens unter http://blogs.fsfe.org/greve/?p=519
Letztlich ist OpenPKG sehr arbeitsintensiv und statisch, und war bei den meisten Nutzern sehr unbeliebt weil sie noch ein neues Paketsystem lernen mussten das ausser Kolab niemand eingesetzt hat. Als es dann noch proprietär wurde, war der Zug für uns endgültig abgefahren.
Daher wurde im November/Dezember 2009 klar, dass wir uns davon verabschieden würden.
Natürlich hatte es auch seine praktischen Seiten, aber die Nachteile haben halt doch überwogen.
Ja, ich weiß, ich kenne die Gründe und es ging halt nicht anders. Eigentlich war schon früh klar, dass Kolab da allein auf weiter Flur steht.
Trotzdem hat es die Arbeit vereinfacht, eben weil man sicht nicht um die Distribution kümmern musste. Ich habe zwei Installationen von Suse zu Fedora und schließlich Debian umgezogen und das mit nicht mehr als tar über ssh. Das geht jetzt leider nicht mehr so leicht.
Die Aktualität gerade bei Sicherheitsproblemen macht das dann aber wieder wett.
Und man kann jetzt Pakete der Distribution installieren, die Kolab-Komponenten in ihren Abhängigkeiten haben. Das war mit OpenPKG auch nicht einfach möglich. Ich trauere OpenPKG nicht nach ;o)
Verwendet Kolab ein eigenes Protokoll für Kalender (statt CalDAV) & Kontakte (statt CardDav) ?
Hat man etwas neues geschaffen um dem offenen Standarts zu konkurieren?
Oder hat man einfach die Protokolle neu implementiert statt DaviCal zu verwenden?
IMAP ist ein extrem weit verbreiteter Standard, würde ich mal behaupten. Dasselbe gilt für die anderen in Kolab verwendeten Protokolle.
Kolab gibt es schon länger als CalDAV & CardDAV. Es hat in Version 1 auch genau dasselbe getan: iCal & vCard in XML abgespeichert und übertragen. Allerdings hat man dann in der Praxis gesehen, dass die Implementationen unterschiedlicher Anbieter so weit voneinander abwichen, dass es häufig Probleme gab. Daher hatte Version 2 ein eigenes XML Format offen spezifiziert, welches ein kanonisches Speicherformat, und eben kein Übertragungsformat wie iCal & vCard ist.
Dann kamen CalDav & CardDAV mit derselben Idee, und laufen jetzt in ähnliche Probleme wie Kolab Version 1: So lange nur ein Klient oder Klienten eines Anbieters zugreifen ist es kein Problem. Sobald die Welt aber heterogen und mit gemeinsam genutzen Resourcen wird, gibt es Probleme.
Mit der Veröffentlichung von xCard & xCal im August 2011 wird das Kolab Format Version 3 übrigens darauf aufbauen -- allerdings mit ein paar Einschränkungen in der Art und Weise, wie die Standards benutzt werden sollen, um sie in ein kanonisches Format zu bringen, denn leider sind auch diese RFCs eher auf den Transport ausgerichtet und erlauben unterschiedliche Abbildungen desselben Problems. Somit ist alles, was Kolab schreibt zu 100% RFC konform. Um das dann noch einfacher zu machen, wird mit der libkolab eine Bibliothek für Klienten zur Verfügung stehen.
DaviCal ist natürlich um Ecken jünger als Kolab, und einer unserer Partner hatte es auch mal an Kolab angebunden. Leider ist es relativ stark Spaghetti-Code und nicht auf verschiedene Backends in der Datenhaltung ausgerichtet, daher ist das auf Dauer kein gangbarer Weg.
Wir rechnen damit, irgendwann in der 3.X Serie CalDAV & CardDAV hinzuzufügen, aber dafür muss eine entsprechende serverseitige Übersetzung für die verschiedenen Klienten gemacht werden, um nicht in die Probleme zu rennen die man sonst in grossen heterogenen Umgebungen bekommt.
Das und einiges mehr hätte man übrigens auch schnell finden können:
Mh so ist das. Sehr interessant, danke für die Infos.
Man merkt das hier eine Firma dahinter steht und das ganze professionell wirkt.
Ich wage es kaum zu erwähnen. Gibt es ein System am Markt (OS) mit dem ich mailen, Aufgaben verwalten kann und einen Kalender habe. Ein System auf das mehrere Leute zugreifen können? Ein System das ich mit meinem Android vielleicht syncen kann und zwar mind. alle drei genannten?
1997 funktionierte das mit meinen Casio (Handheld ;). Seitdem warte ich auf was neues. Sozusagen eine Killerapp die mal funktioniert. Das hat noch keiner geschafft. Oder irre ich mich, vielleicht zarafa???
Das sollte mit Kolab schon klappen.
Android unterstütz meines Wissens sowohl Active Sync für Kontakte und Kalendar als auch IMAP für E-Mail.
Kolab macht sowas seit 2003.
Naja, das mit Android nicht. Den Rest aber schon. Und seid ActiveSync auch mit Android.
Alternativ auch mit kolab-android.
Wobei Android als Plattform keine Aufgaben unterstützt, soweit ich weiss. Das könnte aber einer der ActiveSync Klienten von Drittanbietern mit drin haben.
Citadel mit Funambol-Anbindung ?
Citadel: http://www.citadel.org
Funambol: http://www.forge.funambol.org/
Funambol-Konnektor: http://bionicmessage.net/node/3
Funambol?
Wirklich?
Na das nenne ich mal mutig. Bravo!
Tine20
Wird auch Zeit!
(ehemaliger Debian-Paketierer von Kolab)
Ja, es war leider sehr viel Arbeit, den OpenPKG entsprechend auseinander zu nehmen und dabei die technische Arbeit zu machen. Hat länger gedauert als es auch uns recht war.
Du wärest uns aber herzlich wieder willkommen, wenn Du noch Motivation aufbringen kannst.
Gerade nach Debian Entwicklern suchen wir im Moment auf allen Ebenen und Seiten.