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.

_______________________________________________
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-hackers

Reply via email to