Re: [Evolution-hackers] Camel Manifesto

[Michael Meeks <michael meeks novell com>]

Hi Matthew,

On Wed, 2009-11-18 at 14:07 -0500, Matthew Barnes wrote:
> With work on Bonobo removal wrapping up, I've finally started taking a
> closer look at Camel (Evolution's mail storage and networking library)

	Ah - another life-time of cleaning up, and polishing code: the goal
sounds really nice.

> This is a distant future goal and will have to happen gradually, but I
> would like Camel to shift to a single-threaded design where all file and
> network operations directly use or are derived from GIO's asynchronous
> file and stream APIs.

	Hmm; you really propose to remove all threading from camel's
implementation ? or just from it's API ? a full removal might be
problematic.

	While clearly threading, if done in an un-constrained way, has it's own
peculiar problems - there are a couple of obvious advantages:

	First debugging - while both async and threaded programming loose
determinism due to event re-ordering - the debugger at least understands
threads - and can hopefully show you your state in a reasonably
follow-able way - you can step through slow/blocking calls with 'next',
'finish' etc.; I worry about a world packed with highly granular
asynchronous state-machines, all chained together - with no good way to
see what is happening, what state everything is in, and (of course) why
the app is serenely inactive in it's mainloop suddenly ;-)

	Secondly - of course, a fully async mode potentially would loose any
(possible) benefit of parallelism that in theory threads can provide -
in this world of dual-core laptop CPUs, and even hyper-threaded Atoms.

	OTOH - I'm sure you know what you're doing ;-)

	ATB,

		Michael.

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