Re: [Evolution-hackers] Camel Manifesto

[Michael Meeks <michael meeks novell com>]

Hi Matthew,

On Fri, 2009-11-27 at 11:58 -0500, Matthew Barnes wrote:
> In fact the mail-to-eds effort is part of what's motivating all this.

	Ah ! - ok :-) sounds good.

> To make the discussion more concrete, these are my current plans for
> Camel's extreme makeover.  The final API will hopefully feel like a
> natural extension of GIO.

	So - I'm well up for that :-) reducing the incidence of wheel
re-invention, reducing LOC, increasing familiarity and reducing the
skill-set required to hack on the code are all excellent work; I'm
really eager to see the good results.

> Evolution will then be free to call Camel's async methods from the main
> thread.  I'll still have to deal with queuing up operations in order on
> the Evolution side, but everything will be cancellable (and actually
> cancel when you tell it to, especially when the network is flaky) and
> we'll hopefully have far fewer issues with frozen UIs.
> 
> Does that sound like a more down-to-earth approach?

	Yes - very sensible; of course, I love step-wise re-factoring, so we
don't end up with these massive branches that take forever to merge; ie.
merging just the GObjectification, then merging the GIO-ification [ or
whatever ]: I guess that could conflict with keeping Camel API stable,
but is that even a useful goal ?

	The only thing that slightly concerns me, is that I am not certain
(knowing ~nothing about it) that the Camel API matches well what the
Evolution mailer uses, and/or what works in terms of IPC. When I last
did the analysis of a good place to cut here, the line went through some
of the Evo mailer code, as well as camel.

	If the idea is to use GObject introspection to provide a useful &
usable D-BUS interface, I rather suspect that the result will be an
over-granular, and round-trippy disaster :-) nevermind exposing
lifecycle counting over the wire (which is a total disaster) [ or if not
that, then the GObject API will be somewhat unpleasantly chunky to use
in-process (if that is a goal) ].

	As such, presumably it might be interesting to use the mail / d-bus
interfaces to provide the initial bulk of the asynchronicity, to clean
up the Evolution UI process. Then, in future - if people want to use the
backend API itself in an async fashion from other pieces of code, that
can be done as needed (?)

	It just seems to me that since this is D-BUS and we have to implement
these awful in-lined object adaptors, we can at least use the
DBusMessage encapsulation to throw all the parameters to a slow
operation into it's own thread, before unpacking all them all. That
would contrast with the method of implementing all slow D-BUS methods
using async calls that then spawn threads - which would require
unpacking all arguments, and then carefully re-packing them into various
async closures.

	But I speculate, as always :-)

	HTH,

		Michael.

-- 
 michael meeks novell com  <><, Pseudo Engineer, itinerant idiot