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 

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 care for stable and unstable 
Evo/E-D-S/IMAPX at the same time. Our resources are limited to the stable tree 
of IMAPX (porting our plugin to current unstable is in the plannings, but we 
cannot do it in parallel now). 
  I am thinking about using "git submodule" for that, so we can base our 
development on, say, EVOLUTION_DATA_SERVER_2_30_3, and we could follow to 
EVOLUTION_DATA_SERVER_2_30_4 (and later) easily. When our plugin will be 
ported to 2.31 in future, the submodule branch and our patchset (branch) could 
be adjusted accordingly.


What do you think about these ideas?

Kind regards,


PS.:    I will have to check with git-submodule whether we can track just
        some part of the E-D-S git with that (i.e. IMAPX) ... if we can
        track the full E-D-S git only, then I will have to think up something

kernel concepts GbR        Tel: +49-271-771091-14
Sieghuetter Hauptweg 48    Fax: +49-271-771091-19
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