Cyrus CalDAV design decision

[Georg C. F. Greve]

On Tuesday 23 August 2011 15.23:43 Dave McMurtrie wrote:
> At the moment, the storage format in use is iCalendar, being stored as 
> RFC5322 messages.

That sounds very much like what Kolab did in version 1.

After trying to make this interoperate for several years it was given up in 
favor of the Kolab XML format because iCalendar & vCard looked good on paper 
but suffered from severe interoperability issues between implementations.

So my question would be which kind of iCalendar you're storing?

Several implementations are known to have interoperability issues, e.g. Apple 
CalDav & Mozilla CalDav don't interoperate that well. That is the primary 
weakness of CalDav, and just storing what the client provides will ultimately 
give you a vendor-dependent iCal store with severe interoperability issues.

Googling for Zimbra & Apple iCal should give you some hints.

So if you want interoperability there must be a server side client-aware 
rewriting of data between client and storage layer.


> We can certainly discuss this further, but I'd like  to keep this thread
> centered on where to store the data instead of how to store the data.

These are not separate questions, though.

Because besides requiring a translation layer between storage and what is 
provided to the client, it must be able to deal with multi-user multi-group 
scenarios across different servers.


> There are several CalDAV clients out there (Apple's iCal, Mozilla 
> Lightning, the IOS Calendar app, Android CalDAV app to name a few). 

See above.

These incompatibilities between CalDav implementations are likely the reason 
virtually all groupware solutions I have seen connect Android through 
ActiveSync, and not CalDav, even where they formally provide it.


> I personally favor supporting open standards where possible, but again, 
> this is something we can open up in a separate thread to discuss further.

The Kolab XML format is open, interoperable, and driven by community process 
and suffers from much fewer of these interoperability issues between clients.


> We'll take you up on any offer to provide development assistance!

Well, that only makes sense if there is an understanding within the group to 
move in that direction. Otherwise providing this kind of functionality through 
Cyrus may end up more costly in development and ongoing support than other 
options, in particular as we also have users asking for Dovecot support. So if 
we're going to be alone in providing and maintaining this, there may be other 
options that work better.

Best regards,
Georg


-- 
Georg C. F. Greve
Chief Executive Officer

Kolab Systems AG
Zürich, Switzerland

e: greve at kolabsys.com
t: +41 78 904 43 33
w: http://kolabsys.com

pgp: 86574ACA Georg C. F. Greve
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 308 bytes
Desc: This is a digitally signed message part.
Url : http://lists.andrew.cmu.edu/pipermail/cyrus-devel/attachments/20110823/91fae148/attachment-0001.bin