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.me...@novell.com <><, Pseudo Engineer, itinerant idiot _______________________________________________ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers