About CalDAV

[Helge Hess]

On Jan 5, 2005, at 11:50, Martin Konold wrote:
> Actually I believe that maintaining correct and usable locks semantic 
> with
> multi-location (think about unreliable network links) and proper 
> offline
> support is not possible with CalDAV.

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 point out what issues you see with etags in offline 
synchronisation scenarios.

> WebDAV was never intended for offline usage but for providing a 
> hierarchical
> database like client server access over http.

Can you prove that claim?

I would claim that WebDAV, or more exactly HTTP, was developed with a 
strong focus on exactly this. So I'm rather surprised about your claim.

As a prove I would point to the etag feature which was in the initial 
HTTP/1.1 draft as well as point to the broad support for caching proxy 
servers used in practice.
Especially using the latter HTTP scales magnitudes better than IMAP4 - 
using standard and established technology. *Though* IMAP4 might scale 
well enough for Kolab requirements (this is proven as well).

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 (but 
obviously this isn't in the focus of Kolab either).

Other well known offline HTTP applications include Novell iFolder or 
sitecopy.

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

But HTTP itself does intentionally not provide a "back-channel" for 
(web-scale) scalability reasons. If you actually read the CalDAV spec, 
you'll notice that this is supposed to get covered using XMPP (Jabber), 
another proven and highly interoperable technology also proven to have 
huge scalability.

> The later two facts are very important for efficiency and usability.

IMAP4 is slightly more efficient than HTTP/WebDAV for a lot of 
operations due to smaller protocol packet sizes. Actually message 
retrieval and upload is more network efficient in HTTP since it 
supports gzip/deflate transport encoding per default (and this feature 
is widely supported).

HTTP itself has a certain usability issue due to the missing back 
channel. CalDAV doesn't, since it will specify a way to provide server 
notifications.

> Actually the Mozilla/CalDAV effort is older than Kolab but Kolab is a 
> working
> solution today with a lot of future potential for further development.

I might be wrong, but Mozilla/CalDAV isn't even started yet, it 
certainly isn't older than Kolab. The CalDAV effort was just recently 
announced (~6 months ago?)

Maybe you mix that up with transporting a full iCalendar document over 
a single HTTP call which is hardly a useful calendaring protocol.

> Q: Why XML?
> A: Well if being forced to create a new format choosing XML is sane as 
> many
> 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.

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

> This is due to the fact that iCalendar is a
> mult-vendor standard which leaves too many options and I am not aware 
> of a
> single application which correctly implements all aspects of 
> iCalendar. In
> addition parsing/creating correct iCalendar objects is non trivial 
> compared
> to do the same with XML.

I can't follow that. XML is just the syntax. The iCalendar _syntax_ is 
implemented completely by all implementations I know, just like the XML 
syntax is implemented by all XML parsers (actually in practice only a 
few of the XML parsers support full XML/1.0!, most of them only do well 
formed XML which is often sufficient in practice).

So actually comparing XML with iCalendar is non-sense because one is 
syntax and the other caries syntax AND semantics. The semantics is what 
the clients/servers do not implement fully.
You need to compare "Kolab/XML" with "iCalendar" and if you do, there 
is no advantage here for Kolab/XML. The former doesn't interoperate at 
all because it only works between Kolab clients/server. The latter is 
partially better, because it provides some interoperability, but 
nevertheless has the issues you mention (there is the Calsify working 
group to fix that - maybe rather help with fixing issues than inventing 
new stuff?).

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

best regards,
   Helge
-- 
http://docs.opengroupware.org/Members/helge/
OpenGroupware.org