About CalDAV

[Martin Konold]

Am Mittwoch, 5. Januar 2005 11:30 schrieb Bernhard Reiter:

Hi,

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

This is a very basic assumption of the Kolab architecuture.

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

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.

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

Yes, this is possible as we use the properties of real world calendaring and 
intentionally _not_ reliational database like coherency.

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

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

WebDAV neither knows about unsolicited server messages nor pipelining. 

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

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

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.

> not in spite of but because of our XML storage format!

I don't think that our XML storage format is a holy grail. E.g. if someone 
else is coming up with a better storage format which suits all our current 
and future purposes I can imagine to support this in the future.

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.

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

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