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: gr...@kolabsys.com t: +41 78 904 43 33 w: http://kolabsys.com pgp: 86574ACA Georg C. F. Greve
signature.asc
Description: This is a digitally signed message part.
