About CalDAV, a new calendar storage specification ...

[Helge Hess]

On Jan 5, 2005, at 11:03, Martin Konold wrote:
>> I know a XML storage format has been specified for Kolab2/Proko2.
> The cited URLs don't define a storage format but refer to iCalendar 
> and define
> a transport / query mechanism.

iCalendar _is_ the storage format for CalDAV.

> My first impression is that they do not solve the problems which exist 
> with
> iCalendar

There is the Calsify working group do work on that, its open, feel free 
to join! CalDAV choose to clean up the existing approach instead of 
throwing away all existing work and start something completely new.

> while not really addressing the scalability issues.

You just claim that there _are_ scalability issues. I claim that you 
can write a client which is superior in scalability to Kolab - *if* you 
know what you are doing and if you know what the protocol provides you. 
HTTP solves scalability issues extremely well, this should be out of 
question and is proven in practice.

> Basically CalDAV looks to me like an alternative database like 
> approach without using
> SQL but using webdav instead.

Wow, three things mixed up in one sentence.
a) CalDAV is not a database, its a protocol
b) SQL is query language, not a protocol (the protocol is usually some
    proprietary binary format)
c) WebDAV is not a query language, its a protocol (maybe you mix it up 
with DASL)

>> And Sunbird (the mozilla calendar) has panned to implement it in its
>> roadmap
> Yes I am aware of this since many years.

You can't be aware of that, since CalDAV isn't even a year old.

> In general I still lack to understand the inherent advantage of webdav
> compared to imap for a secure, scalable and offline capable 
> email/calendaring
> solution.

Since you ask, I answer ;-)

The only think which really matters to me is interoperability - Kolab 
obviously has a very different focus - _which is just fine_. IMAP4 
clients / servers - especially as used by Kolab - are VERY hard to get 
interoperable. Its a huge mess to write an IMAP4 client which can 
access Cyrus, Exchange, Domino, UW-IMAP, Courier at the same time. I 
hope you won't question that. KMail, Evolution Mail and even OGo 
webmail are *years of effort* to get the IMAP4/mail combination running 
sufficiently well.

On the other side most of the 280 groupware solutions on Freshmeat are 
based upon HTTP technology. This is why HTTP is a very good choice to 
get people to implement a protocol to their storage. HTTP as the 
transport has little to no interoperability issues - for none of those 
solutions.

As another example take Kontact. It provides six connectors, one of 
them - Kolab - is based on IMAP4. The remaining five are all based on 
HTTP. Three of them (50%) are based on WebDAV.
CalDAV is intended to bring the 5 implementations together. Currently 
there is no standard on how to use HTTP/WebDAV in the groupware context 
which is why the above five are not interoperable. But they already 
share a LOT of common base technology and adoption of CalDAV will be 
way easier than adoption of IMAP4/Kolab-XML.

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