Cyrus CalDAV design decision

[Georg C. F. Greve]

Hi Dave,

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
> code.

Understood.

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.

Best regards,
Georg


-- 
Georg C. F. Greve
Chief Executive Officer

Kolab Systems AG
Zürich, Switzerland

e: greve at kolabsys.com
t: +41 78 904 43 33
w: http://kolabsys.com

pgp: 86574ACA Georg C. F. Greve
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
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