Hi everyone.
After some time working on different places within our Plugin, I'm back to our
IMAPX part.
We would like to use the IMAPX implementation for our backends as well as for
the Evolution Email part when Kolab access is configured.
Thing is, we cannot just use the plain IMAPX implementation since we need to
support the IMAP ANNOTATEMORE draft to access Kolab's (i.e. Cyrus') folder
annotations to tell the different folder types apart. Distinguishing between
the different folder types is vital because it lets us know which entries the
respective folders hold (Email, Contacts, TODOs, Calendar entries, ...).
Depending on the folder type, each of our IMAP-Providers (Email in Evolution,
Address and Calendar in the backends) will care for a given folder type or a
set of folder types. When in Email context - i.e. within Evolution - our IMAPX
derivative would not display Address folders or Calendar folders. The Address
provider will only care for contact folder types, and the Calendar provider
will take care of TODOs, notes, appointments etc. (in short: all Calendar
data).
Now, we have several issues here. Presently, this whole folder annotation
stuff which is implemented in the Cyrus imapd (which is what the Kolab people
use) is based on version 05(!) of the IMAP ANNOTATEMORE draft and it will stay
this way for some time. The IMAP ANNOTATEMORE draft is what eventually turned
into RFC5464 "The IMAP METADATA Extension", but RFC5464 is not what Cyrus
currently implements. There are efforts to incorporate RFC5464 into a future
release of Cyrus (its in the plannings for 2.4, current stable is 2.3). It
will be quite a while, maybe years, before this will happen, and in the
meantime we will be stuck with this early version of the ANNOTATEMORE draft.
Up to version 07 of the draft, the old ANNOTATEMORE syntax and semantics are
used and Cyrus advertises this in it's CAPABILITY response. This was changed
afterwards and turned into METADATA before the final draft version 10 (the
intermediate ANNOTATEMORE2 has never been implemented anywhere, AFAIK).
ANNOTATEMORE and METADATA differ in the syntax they use and they have some
minor semantic differences.
Why am I writing this: IMAPX supports neither ANNOTATEMORE nor METADATA. My
initial thought of patching IMAPX directly IMHO does not make too much sense
presently because there is no imapd as yet which supports RFC5464 (true??) and
ANNOTATEMORE is a draft and it's already been obsoleted by RFC5464 (so
littering the IMAPX code with ANNOTATEMORE would not be too nice).
This made me think whether we could extend IMAPX within our plugin and the
ANNOTATEMORE (and METADATA) extensions could prove their ground there first,
before finally being pulled upstream, if the Evolution maintainers would wish
for that.
Apart from the ANNOTATEMORE/METADATA extensions, which are upstream
candidates, there are some Kolab-specific extensions, which most probably do
not make sense upstream. These could be kept within the plugin code, even if
the ANNOTATEMORE/METADATA should get pulled upstream and subsequently removed
from our plugin code some day. The Kolab extensions include an API extension
to IMAPX which enables us to configure a "context" into IMAPX. The "context"
would be defined by the set of folder type a certain IMAPX instance should
care for. By default, it would be "every folder but the known Kolab PIM
folders". This default would be used within Evolution, so Evolution does not
need to know about an extended API and use the provider as-is (it would then
not present Kolab PIM folders to the Email frontend). From within our backend
code, we could re-configure the respective provider instances via the extended
API as to care for contact folders (EBookBackend) and for calendar data
(ECalBackend) only. This way, we would still have multiple access to the IMAP
server, but each mailbox would only be accessed by one IMAPX provider instance
at a time (left alone the "delete mailbox" part, for which we will have to
think up a good solution, still). The folder annotations can be retrieved
without actually SELECTing a mailbox. Each provider instance would keep it's
own cache, but would cache it's own folder types only. This way, there should
not occure any duplicate caching.
Does this sound "sound" to you? :-)
IF it does, then the next question would be how to do that technically. From
within our plugin code, we cannot directly access IMAPX headers, since (for
good reason) they are not installed (and we would like to be able to link
against installed Evo and E-D-S libs for user convenience). Still, I would
like to avoid duplicating all of IMAPX within our plugin, but instead use the
existing code wherever possible and just redefine the single functions which
we need to extend or change. This would keep a patchset as small as possible
while not really diverting from upstream.
Due to time constraints we cannot currently car
