About CalDAV

Bernhard Reiter bernhard at intevation.de
Wed Jan 5 11:30:18 CET 2005


On Tuesday 04 January 2005 23:12, Michael Harlaut wrote:
> I know a XML storage format has been specified for Kolab2/Proko2.

Yes, we implemented it and it works fine so far.

> But I read today that a new format has been submitted to IETF in order to
> work with Webdav and more : CalDAV.
>
> Here is the last draft :
> http://ietfreport.isoc.org/idref/draft-dusseault-caldav/
>
> A sum up :
> http://greenbytes.de/tech/webdav/draft-dusseault-caldav-01.html
>
> the consortium :
> http://www.calconnect.org/tc-caldav.html
>
> CalDAV is supported by the OSAfoundation (http://www.osafoundation.org/)
>
> And Sunbird (the mozilla calendar) has panned to implement it in its
> roadmap
>
> :http://wiki.mozilla.org/index.php/Calendar:CalDAV_Roadmap

First thanks for the links
and sparking the discussion. 
There never are simple answer to questions like this.

> I haven't read anything regarding CalDAV before, and I know it's quite late
> to do this choice in Kolab2/Proko2. But what are thinking about it ?

We saw CalDAV coming during the last two years
and I believe that our design choices are fine.
Personally I did not really dig deep into the specifications, 
because the design philosophy of Kolab and request languages like
CalDAV is quite different.

First I would say it is an access protocol, not a storage format.
The storage format of a CalDAV server might be a database scheme.

> Interoperability is something as (more ?) important as efficiency :)

The question is: Where do you need interoperability?
All Kolab client must support invitations via iCalendar emails,
this is far more widespread that CalDAV from what I know.
The storage is less significant for interoperability, but you need
something which allows you to reach the other design goals.

Some places from
http://greenbytes.de/tech/webdav/draft-dusseault-caldav-01.html
where design differences can be seen:

| The HTTP/WebDAV feature model encourages a wide range of clients, 
| from extremely simple to very rich. 
| This is because servers must support a wide range of features, 
| but clients can pick and choose which features to support.

Kolab shall scale well and be secure which conflicts
with complex server operations.

We have fat clients always in Kolab and 
a stable storage technology 
which is proven to work for installations with more than 100 000 users.

| Locks are indispensible when multiple authors 
| may modify or create the same resources.

Kolab does not believe in locks as they require a consistant database state.
We developed a workflow which is suitable for the task at hand
and uses a more appropriate self healing conflict resolution. 

| Many WebDAV working group members are discussing more work 
| to improve the performance of synchronization betweeen WebDAV clients 
| and WebDAV repositories. 

This sounds like they are working on inventing a network filesystem again
with special properties. The Kolab server was build on disconnected imap
which already has server implementations providing a very good speed, 
thus is a step further down the line 
where WebDAV needs to go for offline usage.

The good part about the two contracts sparking Kolab was that 
there should be a usable solution that is ready for production usage.
It keeps us on the ground so we create a solution that works first.
Standardisation works better if you have a few good solutions to look at
and not having a comittee thinking about how they should work.
There are not that many Free Software groupware solutions  and none
of them has taken a huge international market share for larger installations.
Kolab has the potential to grab a larger share,
not in spite of but because of our XML storage format!

Bernhard
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2145 bytes
Desc: signature
URL: <http://lists.kolab.org/pipermail/users/attachments/20050105/cb53f869/attachment.p7s>


More information about the users mailing list