About CalDAV

[Martin Konold]

Am Freitag, 7. Januar 2005 22:40 schrieb Helge Hess:

Hi Helge,

> While what you say is not wrong, the implication is incorrect. Nobody
> forces you to use pessimistic locking with CalDAV - you can do that in
> online clients, but you don't need to in offline ones. Just use
> optimistic locking using etags, very "old" techology used by various
> site replication systems.

Please explain. To my understanding the CalDAV heavily relies on coherency. 
How do you intend to keep coherency with etags?

> Please point out what issues you see with etags in offline
> synchronisation scenarios.

The intended CalDAV clients cannot deal with etags to my knowledge.

> HTTP/1.1 draft as well as point to the broad support for caching proxy
> servers used in practice.

The caching for HTTP is to my knowledge intended for static data.

> As an application consider a public calendar webservice like the Yahoo
> TV schedule - a single calendar is accessed by millions of people.
> Something like this will give you big headache with IMAP4

Why? Only modifications to individual events need to be regularly fetched. 
This works perfectly with IMAP4. The nice thing about IMAP4 is that the 
effort is O(1)!

> obviously this isn't in the focus of Kolab either).

Kolab suits well to very big public calendars.

> > WebDAV neither knows about unsolicited server messages nor pipelining.
>
> Unless there is a terminology mismatch HTTP/1.1 supports message
> pipelining on a single socket since the initial revision (several years
> old).

Pipelining in the context of IMAP4 means that messages can be fetched like

1 C FETCH 1
2 C FETCH 2
3 C FETCH 3

and then the server may send the results in any order.

This helps to reduce latency a lot. Think about slow / high latency links.

> But HTTP itself does intentionally not provide a "back-channel" for
> (web-scale) scalability reasons. 

This means that the client must poll often in order to stay current while with 
Kolab the server tells the client that the calendar changed.

> you'll notice that this is supposed to get covered using XMPP (Jabber),

Jabber is very inefficient and expensive across slow links e.g. GPRS.

> retrieval and upload is more network efficient in HTTP since it
> supports gzip/deflate transport encoding per default (and this feature
> is widely supported).

Doing gzip/deflate in the clients is trivial for Kolab clients and scales much 
better than server side gzip/gunzip.

> > parser/validation suites are available. Technically our XML storage
> > format is
> > semantically similar to a subset of the iCalendar standard.
>
> Yes.
>
> Notably with HTTP you can easily support both (XML and iCal encoded
> iCal entities) using content negotiation without the requirement to
> change any other part of the infrastructure.

We can do the very same with plain IMAP folder annotation or message headers.

>
> > Q: Why not iCalendar?
> > A: Well iCalendar is fine for doing invitations e.g. via email
> > transport. This
> > is done in Kolab 1 and Kolab 2. iCalendar is unfortunately not well
> > defined
> > for doing storage of calendars which are supposed to be accessed by
> > multiple
> > client implementations.
>
> Please elaborate. Whats the issue here?

The iCalendar standard is not precise enough. It leaves to many valid manners 
to express the same.

> You need to compare "Kolab/XML" with "iCalendar" and if you do, there
> is no advantage here for Kolab/XML.

As said multiple times before I don't believe XML is the holy grail. If some 
group comes up with an improved iCal like standard I see no reason not to 
switch to it in the future. 

As of today this fixed iCal like standard does not exisist.

> I have another Q:
> Q: Why not the xCal draft?

It is unfortunately incomplete for our purposes. (Mainly OL stuff missing)

Regards,
-- martin

-- 
"I am committed to helping Ohio deliver its electoral votes to the
President next year."  -- 2004, Wally O'Dell - CEO of Diebold, Inc. 
e r f r a k o n - Stuttgart, Germany
Erlewein, Frank, Konold & Partner - Beratende Ingenieure und Physiker