On Thu, 2009-11-26 at 14:24 +, 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?
 Alex's new GConverter interface also caught my eye as a potential
replacement for CamelMimeFilter sometime in the distant future.
Evolution-hackers mailing list