Cyrus CalDAV design decision

[Bron Gondwana]

On Tue, Aug 23, 2011 at 02:44:46PM -0400, Dave McMurtrie wrote:
> 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.

I actually like this best - put it in a separate namespace at the
top level, like:

addressbook.brong
addressbook.brong.Work
calendar.brong
calendar.brong.Work

This could also be hooked in with "altnamespace" more sensibly,
and even advertised as separate namespaces or suppressed to IMAP
clients completely.

> Things that should weigh into our decision:
> 
> - Must work with replication.

tick, replication really don't care, except for extending it to
add the additional namespace to a 'user' command.  That's not
hard.

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

can't see any reason why it wouldn't... same thing, add the extra
folders to the list XFERed when you move a user.  Besides, XFER
is going the way of the dodo real soon now - if the destination
imapd advertises replication protocol support, then it will use
replication protocol to sync the data across rather than binary
copies anyway (in my long term ideals...)

> - 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.

Existing cyrus locking API is orthagonal to WebDAV LOCK.  I would
implement WebDAV LOCK as annotations.  It's really quite unlike any
other locking system, particularly the way "userid" works in locks,
along with lock UUIDs and all sorts of magic.  Basically you can
list the locks on there, and even "fake" them (absent checks that
compare the authenticated userid to the one claimed in the lock
request) - it's very client side exclusion based rather than
server side enforcement.

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

Well, that's my opinions :)  The other solutions could work too, but
I really think this is what different parts of the top-level heirarchy
are for!  And it would hook in better with real namespace support
rather than the hard coded three namespaces we have now.

Bron.