Re: [Evolution-hackers] Camel Manifesto

[Matthew Barnes <mbarnes redhat com>]

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. [1]

- 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


[1] Alex's new GConverter interface also caught my eye as a potential
    replacement for CamelMimeFilter sometime in the distant future.