Cyrus CalDAV design decision
Georg C. F. Greve
greve at kolabsys.com
Wed Aug 24 01:43:12 EDT 2011
On Tuesday 23 August 2011 18.26:42 Dave McMurtrie wrote:
> I understand your passion for the storage format, but the reason I wanted to
> keep it as a separate thread was because the amount of code that needs to
> be modified to alter the existing storage format is relatively trivial
> (entirely contained in the new calendar code) where the code changes
> required to alter the storage location of the data (in whichever format is
> used) will be extensive, touching many other parts of the existing Cyrus
For me the primary question is one of architecture, e.g. the Kolab format uses
METADATA to set the folder type to calendar, and thus data lives in the normal
IMAP namespace. If this, or the need to translate data in a client-specific way
are not foreseen in the architecture it could turn into a nightmare to add
that functionality later and maintain it.
So I figured it makes sense to speak up loudly now so all options can be
considered, rather than later being asked why I didn't raise those points when
there was still conceptual thinking going on. That said, if people decide they
want a different architecture then I'll clearly survive.
But naturally I'll be happy to answer any questions you may have.
Georg C. F. Greve
Chief Executive Officer
Kolab Systems AG
e: greve at kolabsys.com
t: +41 78 904 43 33
pgp: 86574ACA Georg C. F. Greve
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 308 bytes
Desc: This is a digitally signed message part.
Url : http://lists.andrew.cmu.edu/pipermail/cyrus-devel/attachments/20110824/e20633eb/attachment.bin
More information about the Cyrus-devel