Re: [Evolution-hackers] Introduction and Questions

[Ross Boylan <ross biostat ucsf edu>]

On Fri, 2007-06-08 at 20:22 -0400, Jeffrey Stedfast wrote:
> > [Ross wrote]
> > Second question: even if it creates a folder, does it need to stick
> > around for the folder creation to finish?  I think I remember seeing
> > that camel was single-threaded
> 
> not true...
> 
> > , relying on the client app to do
> > threading.  Would there be a way to multi-thread this somewhere
> (either
> > in camel or in the app)?  Obviously doing so would complicate
> things,
> > because at some point one might need to block (e.g., if I move a
> message
> > from folder A to B and then switch the UI to look at B).
> 
> okay, I think you need to familiarize yourself with Camel's API before
> we discuss anything further :)
> 
http://www.go-evolution.org/Mail_Threading begins
"The Camel API is blocking and synchronous"
although it then goes on to qualify this:
"Custom Threads
Two tasks inside Camel use threads internally in order to implement a
cancellable api ontop of a non-cancellable one."

Further
"Mail-OPS
mail-ops.h contains asynchronous versions of varous Camel api's"
It sounds as if mail-ops is outside of Camel, however.

So it sounds as if Camel could (in principle) respond to a move request
by issuing the appropriate IMAP command and then, starting a thread to
do the other activities (indexing the target folder and deleting the the
message from the  source folder) and return.  It would then block on
operations that attempted to access the target folder until the other
operations completed.

I think this could be called a syncronous API, though perhaps that's a
stretch.

On the other hand, http://www.go-evolution.org/Camel.Operation does not
sound like a bocking syncronous API at all, so maybe the statement
quoted at the top is just obsolete?

So, first of all I'm confused about the nature of Camel's API and
operation as far as threading and syncronicity.  

Second, I don't have a sense of whether its features are historical
accidents (camel was implemented in a simple way and evo then used it as
it was) or the result of some deliberate design decisions.  Blocking
syncronous operations are simpler to implement, to use, to debug, and to
understand, so they clearly have some advantages.   But it seems that
the entire application (evolution) does not have that character, so the
benefits of that simplicity end up lost anyway.