Kontact and Citadel – experiences

kde-logo-official
While there are many FLOSS Groupware servers out there, hardly any one them is reliable working with any FLOSS client. Recently my company had to bring Citadel and Kontact together, and we used the opportunity to patch while we go.

Background

Recently my company, the credativ GmbH, was faced with the task to sync the usual groupware data (calender, tasks, addresses) between a mobile phone and a PIM client – using FLOSS and via Internet. The natural solution of course is Funambol to get the data of the phone. The next step is to connect that one to a groupware server and access the server via a well known KDE 3 groupware client.

However, having a closer look at the currently available FLOSS groupware solutions was quite disillusioning. While there are many nice servers, there are hardly any solutions where a server works correctly with a client. The best working example is maybe Kolab-Kontact, but Kolab doesn’t work easily together with Funambol. Actually, the current groupware-Funambol connector only supports three groupware servers: Citadel, OpenGroupware and eGroupware. For various reasons we settled on Citadel, and now the task was to check how well this works together with Kontact.

Citadel

Citadel is rather unique in the groupware world. It is one of the oldest projects, and started off as something different than it is today. For that reason there are many historically grown things – like the room concept. However, once you get used to that the server is quite usable, and the developer community was very helpful.

Regarding the described setup there were only smaller things to fix, and the Citadel guys did that for us, so thanks to them. Citadel still desperately needs a theme which is pleasing the eyes – the current one looks horrible. But that is a task for a web designer and can come after the code basically works.

Kontact – solved problems

Kontact has quite some problems on many levels. The main reason behind all these problems is the protocol: there is no single open standard for doing groupware stuff, there are many different. There is though Groupdav, an attempt to create such a common standard, but until now Groupdav is still a proposal, and besides some missing main functions (no notifications when the content was changed, for example) it wasn’t accepted by everyone. As a result, the current Groupdav support in Kontact is mixed, and we tried to check what worked, what didn’t, and what was fixable for us.

The first problem was that Kontact of KDE 3 has problems with special characters like German umlauts. That is described in Bug #159795, and the patches necessary to fix that behavior are added to the bug report. This is fixed in KDE 4 anyway, so the patch is only interesting for people who are working with Kontact of KDE 3.x for some more time.

The second problem was that tasks flagged as complete were not synced properly – at least, the complete flag part wasn’t synced. When in Kontact a task was flagged as completed it didn’t show up as such on Citadel and vice versa. The problem seems to be that Kontact looks at the percentage value of the completion while Citadel looks at the parameter ‘COMPLETED’. See Bug #171905 for more details – and a patch.

The base for the third problem lies more in the groupdav protocol than in Kontact: there is no mechanism defined to inform the client that the content on the server has been updated. That is sad – and requires the client to pull for changes. This is not properly implemented in Kontact. Therefore we settled on a hack: whenever a resource in Kontact (addressbook or organizer) is deactivated and again activated, the content is reloaded. We decided to trigger exact that action with a refresh button.
Immediately the question comes up if that should not be triggered by time, but the usual work flow in an office is: “Hey, Joe, it’s me, John, have you seen the new appointment I just added to your calendar?” – a time base pulling would confuse the user, a button to pull would not. The bug to this problem is Bug #175409 – including the patches.

Kontact – problems still valid

While we were able to fix some of the problems (hurray Open Source) there are still some things left: we were not able to properly implement a working Free/Busy system with Kontact and Citadel. This is definitely due to some rather strange bus in Kontact, and will require quite some rewrite of Kontact’s resource plugins. But since Akonadi will be out soon the question is if that should be fixed now or if we should wait until Akonadi is out and then have another look at it.

Final words

Kontact and Citadel do work together somehow. And the bits which are missing can be fixed. However, it is clear that Kontact developed into something which was not planned originally, and that a revolutionary change is needed.
Akonadi will hopefully bring this change, but currently it is not there yet.

But even if Akonadi arrives right in time – and with plugins for all the needs we have – the underlying problem of the broken groupdav protocol remains. It is sad somehow that there are so many fine FLOSS Groupware servers out there but that there is hardly any protocol which is supported by all of them and delivers all the features the users want. No wonder that Outlook/Exchange has such a strong position right now.

About these ads

12 thoughts on “Kontact and Citadel – experiences

  1. What is _broken_ in the GroupDAV protocol? Its a minimalistic protocol and widely implemented (we test it successfully against ~15 server systems, from Apache mod_dav to Google Calendar).
    Before we can approach more complicated functionality (like push), we need to ensure that those basics are working (stuff like honoring COMPLETED).

    Having said that, it looks like the next iCal server version will support XMPP push notifications on changed contents. Note that this does not have anything to do with GroupDAV, its a completely separate thing sitting alongside.

    Right now the major problem with GroupDAV is not that it is to simple or that the servers do not support it, but that the _clients_ (including Kontact) even failed to implement the basics properly.
    Its great to see that someone does some work on it! :-)

    Greets,
    Helge

    PS: Would be good to join the GroupDAV mailing list to exchange and discuss issues :-)

    PS2: GroupDAV most likely will never become a real IETF RFC. The more complex requirements for an official standard are implemented in CalDAV (RFC4791) and the upcoming CardDAV.

  2. Helge, from my point of view Groupdav is so difficult (“broken”) because it is, strictly spoken, not a protocol, but just a proposal – according to the homepage (which *you* know quite well, I guess ;) ) it is not even a proposal, but an attempt to create a unified standard. There has never been a release, and the proposal is sitting around for years now.

    But you are right that there is no need for a first version to implement all features thinkable. Still, currently there is no visible development what so ever that indicates any future development in the spec/proposal. I did think about joining the mail list, but there is hardly any traffic at all – it somehow looks dead :(

    About the working part, the problem is that we first have to check what the curretn state with Akonadi is, and if it makes sense to put effort there (that part is about hired people, so money, so corporate thinking, so making sense == getting results quickly).

    About the IETF stuff – maybe it would be worth the effort to put it somehwere else? IETF is not the only place to host/publish standards.

  3. liquidat: the mailing list has some traffic. In fact there are people actively working on GroupDAV clients, for Thunderbird, for Funambol and I work on the Outlook one. Its low traffic, but really, there is not *that* much to discuss! :-)

    Please do not make it more complicated than it actually is. Technically there isn’t even a need for a ‘GroupDAV’ spec, since its really just a subset of WebDAV plus vCard/iCalendar for payloads.
    (eg in contrast to CalDAV which actually _adds_ something)

    I agree though that we should wait for Akonadi before approaching it in greater detail. I’m hoping to get a chance to have a dev meeting / sprint with the Akonadi/Kontact guys next year to do a reasonable Akonadi GroupDAV resource. Not sure whether that will happen though :-/

    Fact is, that the majority of calendaring services are moving to CalDAV now (mostly driven by the need to support Apple iCal). It really starts to gain traction, which IMHO is a very good thing, its the first time we are nearing a _real_, widely implemented standard (especially since Google and Yahoo implemented CalDAV).

    http://caldav.calconnect.org/implementations.html

    Anyways, I’m working on GroupDAVv2, which will improve CalDAV/CardDAV compatibility. The beauty in v2 BTW is that you can use the plain Apache mod_dav as a backend. No need for a “groupware server” at all :-)

    Greets,
    Helge

  4. Thore, I know, I never said anything else :)

    Helge, nevertheless Groupdav must be specified somehwere, otherweise you just get several different, only half compatible products.
    Anyway, if you need to get in contact with anyone of the Akonadi team, maybe I can help you there, just give me a hint! Also, when the next Akonadi meeting is it might be helpful for everyone if you would join the meeting. In worst case the KDE e.V. could be asked to sponsor you (in case travel costs are a matter), sometimes they have some spare money for such things.

  5. liquidat: well, no, “GroupDAV” in the most generic form is already standardized. Its RFC 2518 plus RFC 2445 or RFC 2425/2426. If people would just properly support those, I would be perfectly happy :-)
    [notably Kontact has one of the best iCalendar implementations]

    I can hardly believe that there are incompatible GroupDAV implementations (the GroupDAV aspect). Its so simple, its quite impossible to do it wrong :-)
    Most real world issues live in iCalendar/vCard (eg your COMPLETED example), but thats a completely separate topic and iCal/vCard perfectly standardized for almost 10 years now.

    I have contact with the Akonadi members (remember, GroupDAV was invented during a Kontact+OGo meeting :-), the difficult thing is finding the time for a meeting as everyone is superbusy. Generic KDE/Kontact meetings are not a good environment to get this forward as its too broad, we need a focused 2..4 days hack-o-ton to get it into place (IMHO).

    PS: no, travel cost do not matter ;-)

  6. Helge, btw., since you are already mentioning the example: where can I check the iCalender/vCard specification properly? Especially regarding the completed thing? Is there a handy link somewhere?
    And, I would love to help, but my Qt/KDE knowledge is really quite limitted – but at least I might put someone at work at it :D

    Roy, yes, I regret a bit that I hardly blog right now – but there is really little time. Hopefully, after some more weeks in “a real job” I get used to it a bit…

  7. It’s a shame that there are still holes in some GroupDAV implementations, because it really is a nice straightforward way to connect everything to everything else. We at the Citadel project remain committed to working with any client developers who are interested in improving this.

    liquidat: do you have anyone in mind for working on a new theme for the Citadel web interface that is more to your liking? We would also welcome the opportunity to work with them.

  8. Sounds good, looking forward to it.

    By the way, we’ve also heard from some people who are saying that they had better experiences with Kontact and Citadel by connecting them together using IMAP (Kolab1 style) rather than GroupDAV. Your mileage may vary.

  9. hello…. very interesting post

    My company is running Kontakt + Kolab/Horde +Funambol and it works…. thought IT guys had to dig alot to accomplish the task…
    There was an option for us to settle up on inverse sogo server however it is tightly integrated witch thunderbird which is far simpler in terms of functionality than kontact…

    Looking in to not a far away future KDE PIM 4.3 + Akonadi + OpenSync should give a stable ground and make open source sync development simpler than ever…

Comments are closed.