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
