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