Cyrus CalDAV design decision

Jeroen van Meeuwen (Kolab Systems) vanmeeuwen at kolabsys.com
Tue Sep 6 07:04:29 EDT 2011


Dave McMurtrie wrote:
> Good day,
> 
> Ken, Bron and I have had various disjointed conversations about where
> CalDAV data should be stored.  We're getting to a point where we really
> need to finalize that design decision, so I'm soliciting feedback here.
> 
> The current Cyrus CalDAV code stores DAV resources as subfolders of a
> user's INBOX.  For example, user.dave64.#calendars and
> user.dave64.#addressbooks.  Under each resource, of course, may be
> additional sub-resources like user.dave64.#calendars.Work.  This was
> fairly easy for Ken to implement, so he did so as a proof of concept
> without much thought beyond that.  One issue, however, is that IMAP
> clients have access to these mailboxes and it would likely be a system
> administrator's nightmare to roll something like this into production.
> 

First: Does the Cyrus CalDAV daemon / interface require to use the same 
configuration / runtime data (imapd.conf, config and partition directories)?

Second: The IMAP clients to a Kolab Groupware solution, heavily dependent on 
Cyrus IMAP, uses annotations to indicate the folder type, for example;

    INBOX.Calendar -> /vendor/kolab/folder-type value.shared event

In these folders we store email messages that have .xml attachments.

The .xml attachments are the actual 'object'; an event, a contact, etc.

A 'dumb' IMAP client will see a message with a .xml attachment. The message 
body in our case contains a small note on the object being a Kolab object, and 
a link to a page listing 'Kolab Smart clients'. We find that we have to make 
many potential Kolab clients 'smart', however.

I suppose, with CalDAV integrating into Cyrus IMAP in the foreseeable future, 
Kolab Groupware will want to make use if these additional capabilities as 
well. We have previously found iCalendar to have a number of serious 
restrictions and/or flaws, however, so I'm not certain what/who/where/how on 
our side.

Anyway, perhaps the way we have successfully used for the past ~7 years 
inspires someone to come up with a way that works for all of us.

Kind regards,

Jeroen van Meeuwen

-- 
Senior Engineer, Kolab Systems AG

e: vanmeeuwen at kolabsys.com
t: +44 144 340 9500
m: +44 74 2516 3817
w: http://www.kolabsys.com

pgp: 9342 BF08
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.andrew.cmu.edu/pipermail/cyrus-devel/attachments/20110906/0e2fbe90/attachment.html 


More information about the Cyrus-devel mailing list