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 
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 
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 
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' 
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 

So far, so good.

Now, we're about to port evolution-kolab to the current 'git master' of Evo and 
The situation for IMAPX has not changed, so we will need to dupe IMAPX *again*, 
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 
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 
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 
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 
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 
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 
of Kolab folder types).

We *would* benifit from Camel being a separate lib, however, in that there be a 
defined and stable API for Camel users. Less API churn, once it has been 
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 
and Evo in the long term.

I'm not sure how this all would fit together with the planned-for email factory 
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 
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,


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