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

[Chenthill <pchenthill gmail com>]

On Wed, 2011-11-16 at 15:38 -0500, Matthew Barnes wrote:
> 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.
Thanks for a detailed explanation. Rather than calling resistance, i
would say everyone wanted a clarity :) My concern is that, the above
stated reasoning would hold good for libebook and libecal as well. But I
think it might be too early to discuss this, later.

Thanks, Chenthill.
> 
> 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.
> 
> 
> _______________________________________________
> evolution-hackers mailing list
> evolution-hackers gnome org
> To change your list options or unsubscribe, visit ...
> http://mail.gnome.org/mailman/listinfo/evolution-hackers