On Mon, 2007-06-11 at 14:39 -0400, Jeffrey Stedfast wrote:
> > > > 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 could, yes, but it'd need a way to report an error unless it
> waited
> > > for the operations to finish before returning. For moving mail,
> you
> > > typically want to know that it succeeded :)
> > >
> > > all of the current camel APIs are designed such that the caller
> expects
> > > that when the function returns, the operation has either succeeded
> or
> > > failed (where the failure would be set on the CamelException
> argument).
> > >
> > > > It would then block on
> > > > operations that attempted to access the target folder until the
> other
> > > > operations completed.
> > >
> > > yes, this is true... well, the way folders are implemented at this
> time
> > > anyway...
> > >
> > > >
> > > > I think this could be called a syncronous API, though perhaps
> that's a
> > > > stretch.
> > >
> > > it is indeed a synchronous API :)
> > Syncronous, but it fails the "you know if you've succeeded when the
> > function returns" test.
>
> most of the camel APIs don't fail that test
>
This was in the context of something I was thinking of ("So it sounds as
if Camel could ...."). The feature/change I was contemplating sounds as
if it would be a bad idea because it violates the usual model for camel
calls. Probably either a smaller change (keeping the
blocking/syncronous/useful return values in place) or a bigger one
(general asyncronicity) would be a better idea--at least in a perfect
world of infinite coding time.:) In fact, your idea with folder open
preserves the expected features of the camel API.
--
Ross Boylan wk: (415) 514-8146
185 Berry St #5700 [EMAIL PROTECTED]
Dept of Epidemiology and Biostatistics fax: (415) 514-8150
University of California, San Francisco
San Francisco, CA 94107-1739 hm: (415) 550-1062
_______________________________________________
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers
