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