Hi everyone. In evolution-kolab [1], we use an IMAPX derivative for accessing the Kolab groupware server via IMAP. Since (a) Camel does not expose IMAPX directly and (b) IMAPX is not yet cleanly subclassable in all aspects and I need to keep a copy of upstream IMAPX in the evolution-kolab source tree. I need to replicate some code paths of IMAPX (e.g. all paths that lead from the Store to imapx_untagged, so I can extend this one for ANNOTATEMORE and later IMAP ACL). Hence, there is some IMAPX code duplication I cannot avoid at present. This means that for every (major) change in upstream IMAPX, I need to pull the changes in and check whether I need to fix something in my code dupes. I would therefore be very grateful if anyone who does a major change or an important fix to IMAPX could give me an advance warning before pushing into E-D-S master, especially if for any reason the commit message is not / cannot be prefixed with e.g. IMAPX: to signify that the change touches IMAPX. This is especially important to me when (pre)release dates draw nearer since I would like to keep evolution-kolab IMAPX in sync with upstream IMAPX for (pre)releases, if at all possible. Thanks in advance, Christian PS.: The changes I do to IMAPX locally at present are not specific to Kolab (these parts are kepts in yet another level of subclassing). It is IMAP extensions that I'm doing, so I'm confident that these extensions will be pulled upstream one day. Once that happens, and once IMAPX is exported from Camel for subclassing, I will happily drop my local copy and the dupes, these will just no longer be necessary by then. [1] http://live.gnome.org/Evolution/Kolab -- kernel concepts GmbH Tel: +49-271-771091-14 Sieghuetter Hauptweg 48 D-57072 Siegen http://www.kernelconcepts.de/
Attachment:
signature.asc
Description: This is a digitally signed message part.