Cyrus CalDAV design decision

[Dan White]

On 23/08/11 14:44 -0400, 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.
>
>At a high level, here are the different ideas we've discussed:
>
>1) Keep the design as such and add code to not return folders 
>matching our special names to non-dav clients.
>
>2) Add a new mbtype for DAV resources.  This would remove the need to 
>have a separate level of hierarchy (#calendars and #addressbooks 
>could go away) and it would simplify the code to not show these 
>mailboxes to non-dav clients.
>
>3) Store DAV resources in a separate hierarchy like the DELETED 
>hierarchy.  I think Ken and I initially liked this idea, but the more 
>we talk about it, the more it seems like this is the hardest to 
>implement and we can't remember why we thought it was a good idea.  
>Also, I think Bron suggested that he'd like to move away from having 
>the DELETED hierarchy at some point.  I'm pretty sure we were at a 
>bar when we discussed this, which may explain why my memory is so 
>foggy on the details.

It's nice to have the ability to manage the folders via cyradm (IMAP) if
the client does not facilitate their creation via CalDAV (Sunbird?).

#1 provides an easier method for users to create and maintain their own
CalDAV hierarchy (with IMAP) in that case, and provides some flexibility
for the user and hopefully less headaches for the email administrator.
Hiding the mailboxes could be a configurable option.

Giving users IMAP permissions to modify the contents of the folders is kind
of a problem though.

-- 
Dan White