Cyrus CalDAV design decision

[Dave McMurtrie]

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.

Things that should weigh into our decision:

- Must work with replication.

- Must work with murder (including seamless XFER support of all caldav data)

- Will likely end up needing to support WebDAV LOCK method, so we should 
consider whether the existing cyrus locking api would make that "just 
work" if resources are stored under INBOX.

We'd really appreciate any thoughts and feedback you have on this.  Feel 
free to add ideas that I neglected above.

Thanks!

Dave