Cyrus CalDAV design decision

[Dave McMurtrie]

From my phone, so please excuse any brevity and the top-post.

I understand your passion for the storage format, but the reason I wanted to keep it as a separate thread was because the amount of code that needs to be modified to alter the existing storage format is relatively trivial (entirely contained in the new calendar code) where the code changes required to alter the storage location of the data (in whichever format is used) will be extensive, touching many other parts of the existing Cyrus code.

I spoke with Ken about the storage format and we will have some questions for you regarding the same.  Please fire off a fresh mail to the cyrus-devel list and we can discuss.  I'd offer to do that now, but I'm on my phone at the moment.

Thanks!

Dave

On Aug 23, 2011, at 4:19 PM, "Georg C. F. Greve" <greve at kolabsys.com> wrote:

> 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