Hi everyone. After some time working on different places within our Plugin, I'm back to our IMAPX part. <braindump> 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 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. </braindump> What do you think about these ideas? Kind regards, Christian 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 else. -- kernel concepts GbR Tel: +49-271-771091-14 Sieghuetter Hauptweg 48 Fax: +49-271-771091-19 D-57072 Siegen http://www.kernelconcepts.de/
Attachment:
signature.asc
Description: This is a digitally signed message part.