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