About CalDAV

[Helge Hess]

On Jan 5, 2005, at 11:30, Bernhard Reiter wrote:
> First I would say it is an access protocol, not a storage format.

Hu? You "could" say that, but this wouldn't make it more true. CalDAV 
is like IMAP4 a protocol to "access" a storage, yes. But CalDAV also 
defines the storage format to be iCalendar, just like Kolab1.

> The storage format of a CalDAV server might be a database scheme.

How is that important? The storage can also be an IMAP4 server. CalDAV 
is a protocol, not an implementation. Some will implement it using a 
RDBMS, some will using some BDB and some simplistic ones will use plain 
files. Same like with IMAP4 servers.

>> Interoperability is something as (more ?) important as efficiency :)
> The question is: Where do you need interoperability?

If you don't need interoperability nor want to reuse existing 
technology, you don't need standards, thats right.

Personally I need interoperability so that one must not write a special 
connector for each and every server for each and every client. Thats 
completely stupid waste of time, especially because _all_ OpenSource 
clients already are based upon iCalendar internally.

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

Where does it say that server operations are complex? It says that 
clients can be rich in functionality, the paragraph doesn't say 
anything about the complexity of server operations.
Notably Kolab clients also required a wide range of "extra" features in 
the IMAP4 server - so many that they are hardly interoperable with 
arbitary IMAP4 servers and only work against Cyrus imapd.

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

No one questions that. But this doesn't make CalDAV any worse. Notably 
there is no prove that it works for _calendaring_ in 100.000 user 
setups, do not even dear to ask for shared calendaring. This has a 
whole bunch of new issues which mail doesn't have, including the 
requirement to deal with conflicts and PDA synchronisation required to 
preserve identity.

Anyway, no one is talking about storage technology, CalDAV is storage 
agnostic, just like IMAP4. Its a protocol, not an implementation.

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

Pessimistic locks do not scale which is why HTTP provides etags to 
ensure atomicity for such setups.

> We developed a workflow which is suitable for the task at hand
> and uses a more appropriate self healing conflict resolution.

Agreed. Suitable for the task at hand.

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

I would like to learn about features offline IMAP4 provides which are 
not in HTTP/1.1.

The work being done in WebDAV "to improve performance" is work on 
transmitting only diffs of a single entity. AFAIK IMAP4 provides 
nothing like this.
(personally I don't think that this is relevant for CalDAV though, its 
more an issue for synchronization of repositories containing large 
files)

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

Yes, that is certainly a good approach and I agree that CalDAV somewhat 
lacks that and might be doomed to fail due to this just like CAP. Time 
will show, OSAF seems to be very focused here.

> Standardisation works better if you have a few good solutions to look 
> at
> and not having a comittee thinking about how they should work.

Thats where your argumentation fails. Because the current approach of 
Kolab2 provides _no interoperability at all_ and is just a _single_ 
solution which focuses on "the task at hand", not on interoperability. 
Actually the choice of technologies is so limited, that it doesn't even 
work with arbitary IMAP4 servers.

They correct way is somewhere in between, IMHO. Yes, you need a 
practical setup which is supposed to work, but you also need more than 
one server and client to accomplish interoperability. And think about 
that up front.

> There are not that many Free Software groupware solutions

Freshmeat only lists 280 projects in the groupware category. There are 
LOADS of free groupware solutions.
One of the issue which IMHO hurts most is that few of them provide free 
groupware client connectivity (like Kontact or Evolution). And this is 
IMHO due to a lack of a reasonable easy standard for doing calendaring.

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

Good look! At least you have a very good reference client ;-)

See you tomorrow,
   Helge
-- 
http://docs.opengroupware.org/Members/helge/
OpenGroupware.org