Re: [Evolution-hackers] Overview of camel-lite

[Matthew Barnes <mbarnes redhat com>]

On Mon, 2007-06-11 at 15:45 +0530, Srinivasa Ragavan wrote:
> On Mon, 2007-06-11 at 12:47 +0300, Philip Van Hoof wrote:
> > I think (opinion) that the most easy way to get things in a clean way
> > into an upstream version, is to split Camel away from EDS. I noticed
> > that Jeffrey wouldn't object and that Matthew more or less agrees with
> > this point of view (although, don't let me speak for them).
> > 
> 
> Every time we discuss the first road-block is the split. Why don't we do
> some progressive work together before we discuss on this? It would have
> made real sense if there are many projects that depends on camel. For
> now, it is just Evolution and tinymail. I dont see a great point in
> splitting it. I remember that we had discussed it too many times at
> various forums. (Guadec/Mail/bugs/...). I'm not in favor of it atm.

Just to clarify my position on this...

I think it makes sense for Evolution and E-D-S to treat Camel as an
external dependency, similar to GtkHTML and libsoup.  Whether Camel
should be *distributed* separately from E-D-S is a political matter, and
I don't see a pressing need to persue it at the moment.  But I would
like to try to make it at least technically feasible.

The biggest technical obstacle to splitting Camel from E-D-S is Camel's
dependency on libedataserver.  I imagine this dependency formed somewhat
accidentally as a result of Camel and Evolution being developed in
parallel.  Closer inspection of the dependency, however, shows that some
of the API provided by libedataserver is used exclusively by Camel.
Other parts of the API seem to make more sense for Camel to provide than
libedataserver (e.g. e-iconv).

Some other data structures provided by libedataserver and used by Camel
could possibly be deprecated altogether in favor of some of the newer
features now offered by GLib that weren't available or mature enough at
the time Camel was written.  Some examples include:

   - EThread -> GThreadPool (already done)
   - EMutex -> GStaticMutex / GStaticRecMutex (already done)
   - EDList -> GQueue
   - EMemChunk -> GSlice and/or GStringChunk

I've opened bug #424744 [1] to try to untangle some of these
dependencies.

Matthew Barnes

[1] http://bugzilla.gnome.org/show_bug.cgi?id=424744