Hi everyone.

In evolution-kolab [1], we use an IMAPX derivative for accessing
the Kolab groupware server via IMAP.


(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,


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

Attachment: signature.asc
Description: This is a digitally signed message part.

evolution-hackers mailing list
To change your list options or unsubscribe, visit ...

Reply via email to