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.
