Cyrus CalDAV design decision
Jeroen van Meeuwen (Kolab Systems)
vanmeeuwen at kolabsys.com
Tue Sep 6 07:07:09 EDT 2011
Ken Murchison wrote:
> Bron Gondwana wrote:
> > 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.
> Where would shared mailboxes reside?> I don't know if there is a viable
> use case for shared mailboxes, (...snip...)
There's definitely a use-case for shared calendars (think resources such as
conference rooms, beamers and cars).
Jeroen van Meeuwen
Senior Engineer, Kolab Systems AG
e: vanmeeuwen at kolabsys.com
t: +44 144 340 9500
m: +44 74 2516 3817
pgp: 9342 BF08
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Cyrus-devel