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