On Thu, 2009-11-26 at 14:24 +0000, Michael Meeks wrote: > So - I'm well up for hiding complexity behind an asynchronous API in > general; that's a great goal. I guess there is also the mail-to-e-d-s > red herring to consider in the mix - that (potentially) adds a layer > of asynchronicity to the equation in the form of remote dbus calls; > perhaps worth considering that in parallel - though it would be cut at a > different place (potentially).
In fact the mail-to-eds effort is part of what's motivating all this. Your point about the backends devolving into complex, hard-to-follow state machines is well taken. Evolution itself is what I'm really aiming to de-thread, and having thought about it further I think I can accomplish that without having to disrupt the Camel backends too much. 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. - Convert Camel to GObject and discard the redundant parts of its custom type system. (That's mostly done now on my branch.) - Replace CamelException with GError, and make sure all methods that take a GError return -something- so failures can be detected without having to test the GError directly. (I'm slogging through all that now -- over the holiday weekend, no less!) - Gradually add GObject introspection annotations to the public API. - Once GIO gets SSL support, replace all the CamelStreams with stock GIO (and GNIO) streams plus our own GIO stream subclasses for things like filtered streams, "NULL" streams, etc.  - Every method that can block will take a GCancellable argument. This will address one of my major problems with Camel's current API, which is that you can't easily tell which functions block and which ones do not. This will make it obvious and explicit. - All (or at least most) of the POSIX or GLib-wrapped POSIX calls for file I/O will be replaced with cancellable GIO equivalents. - And finally the async aspect: taking a cue from GIO, blocking methods will have asynchronous variants whose default behavior is to simply call the corresponding synchronous method from an isolated thread. Subclasses (including the backends) can override the default async methods if they want to. 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? Matthew Barnes  Alex's new GConverter interface also caught my eye as a potential replacement for CamelMimeFilter sometime in the distant future. _______________________________________________ Evolution-hackers mailing list Evolutionemail@example.com http://mail.gnome.org/mailman/listinfo/evolution-hackers