Re: [Evolution-hackers] Camel no longer depends on libedataserver

[Matthew Barnes <mbarnes redhat com>]

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.

But as long as it stays arbitrarily bundled in E-D-S it's not really
reusable.  Any project looking to use such a library would be scared
away by having to drag in E-D-S for no reason.  And I want Camel to
be a viable choice. [2]

Picking up just one additional user besides Evolution, like perhaps
something from the XFCE or LXDE projects, would be really healthy for
Camel.  It would demonstrate that Camel _is_ reusable.  It would force
us to consider other users of Camel before making changes.  That's a
good thing.  It's a sign of library maturity.

Camel is a base library for E-D-S.  Always has been, for as long as I've
been around anyway.  We already treat it as a base library.  Splitting
Camel out of the E-D-S git repo would have minimal impact.  In concrete
terms, it would involve moving the "camel" source directory, its API
docs, and some autoconf goo to a separate git repo.  Then we would start
releasing Camel tarballs.  That's it.  Aside from maybe some pkg-config
tweaks there would be ZERO impact to Evolution or the extension modules.

[It occurred to me that we would first need to give Camel the ability to
load provider modules from both built-in and custom directories, so the
evo-specific providers stay evo-specific.  IMAPX, POP, SMTP, etc. would
move perhaps to /usr/lib/camel/providers; but MAPI, EWS, GroupWise, etc.
would stay where they are.  Perhaps that's where the resistance is
coming from?  That's an easy fix.]

Let me emphasize again that Camel is not yet ready to be split off from
E-D-S.  This is a long term goal, and in fact I've been nudging Camel in
this direction for years.  Porting Camel to GObject, sealing up object
structures, moving to a single-include paradigm like GTK+ did, adding an
asynchronous API, keeping its API docs up-to-date, and now severing its
libedataserver dependency... all done in the service of molding Camel
into a standalone GLib-based mail library.

I think an actual split is probably a year or two out yet, at least.
Splitting off Camel now would create API stability expectations that I'm
not ready to meet.  Parts of Camel's API still need a lot of love, and
sheltering the library in the E-D-S repo for the time being gives us
cover to break the API to fix it, until everything is hammered into
shape and nicely polished.  Camel is still "in the shop", so to speak.

I view the split as just a logical step in Camel's path to maturity, so
I was a bit taken aback by the resistance expressed.  Hopefully I've now
clarified myself.

Matthew Barnes


[1] http://projects.gnome.org/evolution/meeting-logs/2011-11-16.shtml

[2] Some distros like Debian already package Camel as a standalone
    library.  "apt-get install libcamel-1.2-23"  Perhaps the point
    to all my rambling is it should be packaged this way UPSTREAM
    too.