Hi everyone. Am Mittwoch 16 November 2011, um 21:38:59 schrieb Matthew Barnes: > On Mon, 2011-11-14 at 23:33 -0500, Matthew Barnes wrote: > > There is no longer any _technical_ reason why Camel needs to be bundled > > in the evolution-data-server module. I DO intend to split Camel off at > > some point, but not yet. Parts of its API are still a complete mess and > > I'd like to give them some attention and also reach some semblance of > > API stability for the library as a whole. We're not there yet. > > Chen asked me in the IRC meeting today [1] to clarify my position on > splitting off Camel. > > My vision for Camel is simply for it to be a nicely crafted, reusable, > well-documented mail client library with tight GIO integration. I do > believe that's in line with what it was intended for all along. > [...] Thanks Matt for detailing your plans. Let me add some lines about what little experience I have with Camel and what we were facing when initially implementing evolution-kolab. Back then (2.30 era), we found we needed an IMAP implementation for use in our backend to talk to a Kolab server. Instead of arbitrarily using some random implementation, naturally, we looked at Camel, since it was provided in E-D-S. When consulting with the people on #evolution, we were instantly pointed to IMAPX, and my thought was "why not". We were, say, surprised when looking at the code. Camel (and IMAPX) sources were located in E-D-S, but used in Evolution, not E-D-S (we did not have a look at other groupware backends at that time). This was some sort of a funny finding to us. Next thing which bit us was the fact that we needed to extend on the existing IMAPX implementation for Kolab specifics. Alas, we found ourselves unable to subclass the Camel IMAP implementation. The reason was clear to us: Camel wanted to hide implementation details, just request your provider for a given protocol and then use it in a unified way. Unfortunately, this did not help us much. We were then forced to duplicate IMAPX in our backend so we have it handy for extension and subsequent subclassing. We did the following: First, extend the IMAPX implementation with the ANNOTATEMORE IMAP extension. It would have been difficult (and the wrong place) to do that in an IMAPX derivative, since this extension is at protocol level. After extending our IMAPX copy that way, we subclassed it to create our own 'kolab2' provider, which has some Kolab-specific extensions above IMAP level (so these extensions are kept outside the actual IMAPX extension). Most notably, the 'kolab2' provider now knows about Kolab folder type annotations, and hides the PIM folders when run in Evo for Kolab email access. When run in the backends, it hides the email folders and the folders the given backend type (cal/book) does not need to care about. So far, so good. Now, we're about to port evolution-kolab to the current 'git master' of Evo and E-D-S. The situation for IMAPX has not changed, so we will need to dupe IMAPX *again*, from current sources, re-implant our extensions into IMAPX (we have not had the time to push them upstream, but will this time, hopefully), and start over. Not during the initial porting, but later on, we will need to extend IMAPX even further, this time with the IMAP ACL support (as far as needed for Kolab, that is). That said, we would not have been able to benefit from Camel being a separate lib, unless it would have exported IMAPX as a subclassable GObject, and we would still have faced the problem that we had to get the IMAP extensions done in time, which we were able to do in our own dupe, but getting the stuff upstream (and doing it really, really Right), would have taken more time than we actually had. The same will hold true for the IMAP ACL extension we have planned. While our code dupe may be a good place to breed some ideas, and let the code mature somewhat, we would be happy of course to see these extensions being moved to IMAPX itself, once the implementation has evolved far enough. We could then get rid of our IMAPX code dupe, ripping it out from evolution-kolab, provided Camel would export the CamelIMAPX* classes as subclassable ones, so we still can derive our CamelKolabIMAPX* classes from them and keep in evolution-kolab only what is truly Kolab specific (like the handling of Kolab folder types). We *would* benifit from Camel being a separate lib, however, in that there be a well- defined and stable API for Camel users. Less API churn, once it has been stabilized, and less effort for Camel users to keep their stuff working. Creating a good and stable Camel API may be a p.i.t.a. initially, but I believe that it will clarify issues that need to be adressed in overall Camel use, which may in turn ease more things in E-D-S and Evo in the long term. I'm not sure how this all would fit together with the planned-for email factory later on, but it might be possible to further freeing evolution-kolab from code dupe. In our KolabMailImapClient class, we currently run our own CamelSession and all infrastructure to act Evo-like, just to be able to use (a part of) Camel. Maybe we can straighten this out further in future, and make use of a well thought-through IMAP infrastructure via the email factory, just adding our Kolab-specific stuff in our own code. That's it so far, more brain dump may follow as I find my bit bucket overflow. :) Kind regards, Christian -- 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.