On Sat, Nov 21, 2009 at 12:51 AM, Jeffrey Stedfast f...@novell.com wrote:
Matthew Barnes wrote:
With work on Bonobo removal wrapping up, I've finally started taking a
closer look at Camel (Evolution's mail storage and networking library)
and laying out plans for where I'd like it to go over the short and long
term, with the ultimate goal of splitting it off as a useful standalone
GNOME library (but we're a long way from that).
As usual I'm taking a bottom-up approach, starting with basic cleanup
chores (both code and development policies) and building up from there.
Here's some of my thoughts:
Backward Compatibility Policy
A reverse dependency search in Debian and Fedora reveals the only
external projects currently linking to Camel are mail-notification,
evolution-jescs and Anjal (please correct me if I've missed any).
That tells me that until Camel moves out of its parents' basement and
matures into an real, honest-to-goodness library, fixing its interface
is more important than maintaining backward compatibility. Deprecation
periods for obsolete API are not necessary, in my opinion. The few
external projects linking to Camel will just have to keep up with the
changes every six months.
I think it's a worthy goal to separate Camel out of Evolution.
That's not a license to go hog wild though. Some caveats:
1) The soname -must- be kept accurate. If you break the API or ABI,
increment the soname when you commit the break. It doesn't matter if
the break doesn't affect external projects, nor even if it's already
been incremented since the last point release. Bump it anyway.
Always bump is an easy policy to remember. It makes our own daily
development run smoother, and helps ensure a release doesn't slip out
with an inaccurate soname.
If you're not sure if your patch requires a soname increment, please
ask in IRC or Bugzilla. Patch reviewers should try to remember too.
2) If you must break the API, try to do so in a way that things will
fail noisily at build time rather than mysteriously at run time. For
example, if you want to change the behavior of an existing function,
it's better to rename the function or change its parameter list so
that stale Evolution code will fail to build.
3) Camel started life as a general purpose mail library and I'd like to
try to get back to that. Camel has become too Evolution-centric in
my view, with too many quick-fix hacks for Evolution bugs that would
not be appropriate for a general purpose mail library. I will clean
these up as I find them, but try to keep that in mind when altering
the API yourself.
I'm not sure what Evolution-specific quick-fix hacks you mean?
Migrate to GObject
Camel's homegrown type system will be replaced with GObject so that
introspection and D-Bus + language bindings are possible. CamelObject
will remain (for now), but as a subclass of GObject. The redundant
parts of CamelObject will be removed.
Worthy goals... there are some things like CamelObjectBag and such that
don't have an equivalent in GObject.
I'm also following GLib and GTK+'s example of sealing up public instance
data in private sections and enforcing that only its top-level header
file be included outside of Camel (including the providers). Unlike
GLib and GTK+, there will be no transition period.
This will give us a lot more freedom to reorganize the library and
refactor code without disturbing the ABI. Debugging is also easier when
you can trap data accesses through get and set functions.
Sure, but I don't think any code actually goes behind any get/set
method's back at the moment (or at least didn't back when I worked on
Camel). Regardless, I'm cool with the proposed changes...
I've been chipping away at this as a side project for the past year (it
was a good mindless activity when I got burned out on Bonobo removal),
and I recently published my results to git.gnome.org as a branch named
camel-gobject. The CamelObject conversion is finished -- including
all the boilerplate changes in the subclasses -- but I haven't finished
sealing up the API.
The branch probably won't land until 2.31 at the earliest. The backward
compatibility policies I described above would be in effect thereafter.
This is a distant future goal and will have to happen gradually, but I
would like Camel to shift to a single-threaded design where all file and
network operations directly use or are derived from GIO's asynchronous
file and stream APIs. SSL support is currently under development for
GIO, and that's the only missing piece I see at the platform layer.
I realize this is a drastic course correction and will require rewriting
all the providers and much of the mailer code in Evolution, but I firmly
believe that the overuse of threads carries much