Hey Matt, On Sun, 2008-11-09 at 12:52 -0500, Matthew Barnes wrote: > Over the weekend I hit a milestone with a science experiment I started > earlier in the year to turn Camel into a GObject-based library with > minimal API breakage. The short-term goal of this effort is to make it > easier to generate language and D-Bus bindings for Camel. > This is awesome news :-).
> I now have running code which I've posted to a new evolution-data-server > branch called "camel-gobject" . The branch contains a couple very > small patches (evolution.patch and evolution-exchange.patch) that must > be applied before building Evolution against the GObject-based Camel > library. > > Evolution seems to be working just fine with my standard setup, but I > haven't tested all the built-in Camel providers and various third-party > extensions. If others want to chip in with the testing I'd be grateful. > > > Techie Details > -------------- > > My approach was basically to pull off the same stunt that was done to > GtkObject when GObject was introduced: turn the base CamelObject class > into a GObject subclass, and convert the CamelObject API into a set of > thin wrappers for equivalent operations in GObject. For example: > > camel_object_ref() now calls g_object_ref() > > camel_object_unref() now calls g_object_unref() > > camel_type_register() now calls g_type_register_static() > > ...etc... > > Obviously this breaks Camel's ABI. There's no way around that. I think, you are correct. This needs to happen at some time. > > The (intentional) API breakage is very minimal: > > CamelType is now an alias for GType. It is no longer a pointer > to the class structure. That was supposed to be an implementation > detail anyway, but Camel (and Evo, and Evo-Exchange) exploits that > in a number of places. The class structure can be properly accessed > using camel_type_get_global_classfuncs(), which is now an alias for > g_type_class_peek(). > > The corollary to that is when to fetch the parent class structure. > Most classes define a static "parent_class" pointer for chaining up > in class methods. The "parent_class" pointer should be set in the > class initialization function, NOT before the type registration in > get_type(). Just like you would in normal GObject code. There > were LOTS of places in Camel were that needed fixing. > > Camel interfaces are dead, but they were never really used anyway. > > The other half of the problem was CamelObjectBag. It formerly shared a > mutex with CamelObject's reference counting, I think because CamelObject > ref's and unref's were non-atomic. GObject's reference counting is > atomic, so with that issue out of the way I gave each CamelObjectBag its > own mutex, cleaned up the code a bit, and split it off into a separate > source file (camel-object-bag.c). After an evening's worth of debugging > it seems to be working fine now. > > > Now What? > --------- > > So with the "interesting" part now done, next comes the long and tedious > part: rewriting all the internal CamelObject boilerplate into GObject > boilerplate and making sure we're not using any newly deprecated API. > But that can be done gradually and with help from others. > > In time I'd also like to explore taking greater advantage of GObject > signals and properties in Camel, and also deprecating CamelArgV and > CamelArgGetV. Also the Camel Events to GObject signals right, or you meant the same? > > I haven't discussed this with the other Evolution/Camel developers yet, > so there are currently no plans to include it in 2.26. That may change, > but for now it remains purely experimental. 2.26 might be a very tough one, with Kill-Bonobo also in, we may have too many things to shape up. > > Matthew Barnes > > >  > http://svn.gnome.org/viewvc/evolution-data-server/branches/camel-gobject/ > > > _______________________________________________ > Evolution-hackers mailing list > Evolutionfirstname.lastname@example.org > http://mail.gnome.org/mailman/listinfo/evolution-hackers _______________________________________________ Evolution-hackers mailing list Evolutionemail@example.com http://mail.gnome.org/mailman/listinfo/evolution-hackers