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: gr...@kolabsys.com t: +41 78 904 43 33 w: http://kolabsys.com pgp: 86574ACA Georg C. F. Greve
signature.asc
Description: This is a digitally signed message part.
