Thursday, February 4, 2010

CalDAV/CardDAV/GroupDAV Support for Akonadi

Another month, another new resource for Akonadi ;) Well, actually the resource has been started by Grégory Oestreicher 3 month ago and just recently I came across the code in playground and gave it a try. After some code cleanup (to simplify the later move to kdepim/runtime/resources) I started to refactor some parts of the resource to better match the design of Akonadi. Some of the features have been removed during that work (e.g. only reload data that have been changed on the server), but they will come back in the future.
Initially the resource was designed to support the CalDAV protocol and the calendaring part of the GroupDAV protocol, because these two protocols are basically the same, with some small differences, most of the code for listing, loading and saving events and todos can be shared.
However the GroupDAV protocol supports handling of contacts as well and there is a new standard, called CardDAV, which is the contact handling equivalent to CalDAV. The logical consequence was to add support for CardDAV and adapt the GroupDAV implementation to handle contacts as well. While we are still working on iron out some bugs and test the resource against all free available groupware servers, we plan for the future...

At the moment you'll see a configuration dialog like this:




Here you can configure which protocol to use, what the URLs for the protocol handlers are and what login credentials shall be used. Unfortunately that's much to technically. In the ideal world one would have a configuration dialog that provides a list of supported groupware servers and input fields for the login credentials, everything else should be setup automatically by the resource. And that's indeed the next big task on our TODO list, so be excited :)

Now follows another screenshot of akonadiconsole with two resources loaded (one for CardDav and one for CalDav) that a configured to access the SOGo demo system:



17 comments:

Andreas Kuhl said...

With which KDE SC version will this be available for the masses? :)

tokoe said...

@AndreasDemmer Depends on the time we can invest, but it looks like it could be shipped together with 4.5

Unknown said...

Is it somewhere in playground to test it, maybe with egroupware?

tokoe said...

@Chris Yes, it is located in trunk/playground/pim/dav. However you need an up-to-date kdepimlibs/akonadi and there might occur a crash when deleting items (that are the bugs I was talking about ;))

scroogie said...

Great! Can't wait to see all Akonadi goodness and finally fresh versions of KDE PIM on my work desktop.

Daniel Smedegaard Buus said...

I love you! :D

I have been so wondering why CalDAV wasn't there in Akonadi, since we have already a Google Calendar Resource, and Google actually use CalDAV.

But the only configuration options there are for that one are GMail login and password. D'oh!

Actually, double d'oh, since you can't even put in a Google Apps gmail address, since it assumes all GMail addresses end in "@gmail.com". Fail! :D

Unknown said...

"In the ideal world one would have a configuration dialog that provides a list of supported groupware servers and input fields for the login credentials"

Nah! The point of the standards is to avoid such server specific crap :-)

There are two approches, which IMHO every client should support:

a) WebDAV hierarchy browser. When the user entered a URL which is a WebDAV collection (responds to the respective PROPFIND), a hierarchy browser should be displayed. If its a GroupDAV typed folder, a CardDAV addressbook or a CalDAV calendar, the proper resource should be created.
[this is very neat with plain Apache mod_dav as the backend]

b) Principal Lookup. I the URL is a principal resource, or information which leads to a principal resource (eg via DNS or the well-known HTTP namespaces), it should do the homeset magic.
[this is done by most 'full' CalDAV/CardDAV clients]

Greets,
Helge

Unknown said...

Very cool, that's what I am really looking forward!

storm said...

@Helge, the point of standards it certainly not to prevent software being user-friendly or making commonly-used pathways closed to non-'experts'.

Having a choice of pre-defined services, plus 'Other...' is hardly disempowering to anyone. It's not as if they are going to think 'Oh, I best use BlahBlahGroupware now because it's listed, and my server isn't.' Those people who have less common configurations will generally be better able to figure out how to configure manually. Those users who are less or un-able to figure out how to enter a manual configuration are many, and are extremely likely to use one of a small set of common services.

Unknown said...

@storm I fail to see your point. What can be easier than entering username@hostname plus a password? The rest is all standards (or almost standards) stuff and completely independend of the (xyzDAV) server.

Note that I'm only talking about *standards* based servers.
I'm totally with you when we are talking about connecting using a proprietary protocol (Exchange, OpenXchange, Groupwise, etc). In this case a config dialog is required (obviously).

storm said...

This is brilliant work.
If you want to test against Zimbra server (widely-used opensource server with CalDav, GroupDav, CardDav capabilities), that would be great, I can provide access if needed.

Cheers

storm said...

@helge I see your point, I still submit that individuals who are not technically-orientated are far more likely to use technology and do it more confidently if they are signposted - e.g. even if lots of servers have the same standards-based configuration, it significantly helps to signpost the non-technical user i.e. select your server - Exchange, Zimbra, Yahoo! Mail, OpenXChange, Other... regardless of whether they use standards-based configuration or not. However, if a non-technical user is just faced with "enter your server username and password", they will probably not, or at least do so lacking confidence. They often don't even know what a server is.

Frank said...

Sorry for this stupid question, but is this still maintained? I basically can't wait to give it a try because this is a feature I'm waiting for since KDE4 was released. But somehow I can't find it in the SVN repository in the given location. I'm running kubuntu 10.04 with KDE SC 4.5 RC in a VM installed ...

tokoe said...

@frank Yes, the resource is still maintained and will be part of KDE PIM 4.5. Note however, that KDE PIM release will be postponed a bit, since porting of KMail and KOrganizer took a bit longer than expected. The code can be found in SVN trunk kdepim/runtime/resources/dav

JoKer said...

Hello. I just compiled kdepim and tried out caldav for google calendar. I could change already existing events but when I created a new event it doesn't get created on google calendar but instead get deleted.
Is this a known bug and why is this happaning. Nevertheless thanks a lot for this great work!!!

Andrew Wasielewski said...

Has this good stuff made it into KDE yet? I am on KDE 4.5.4 (Fedora 14) and my Akonadi GroupDAV resource screen looks significantly different from the screenshot above. (http://www.UploadScreenshot.com/image/197620/8044231)
I would expect "Update Folder List" to show something, but nothing happens. There is a thread on Zimbra forums where people are trying to get Kontact working with Zimbra using GroupDAV (http://www.zimbra.com/forums/users/9285-calendar-folder-through-imap-kde-kontact.html).
Regards,
Andrew

jennyu said...

togel online
bandar togel terpercaya
agen togel
judi togel