Re: [Evolution-hackers] Issues with new EBook dbus implementation

[Patrick Ohly <patrick ohly gmx de>]

On Fr, 2011-05-27 at 11:59 -0400, Matthew Barnes wrote:
> On Fri, 2011-05-27 at 16:49 +0200, Milan Crha wrote: 
> > Maybe it can pump them, but it doesn't deliver them, as far as my tests
> > showed, because they are usually delivered on idle, which never happen
> > with blocked main loop. That's the reason why I added there this loop.
> > Only notice that this loop is running for "sync" calls, and only if it's
> > done from the main thread. The async calls and sync calls from a
> > dedicated thread doesn't do any such thing. You may not use sync calls
> > in your application, preferably. (Same as evolution shouldn't, which is
> > subject to change, to use the EBOok/CalClient APIs directly.)
> 
> Can't we just consider it a programming error for a D-Bus method to be
> called synchronously from the main thread?  I don't see any reason to
> support this case since it would be by definition a bug.

I beg to differ. A command line tool like SyncEvolution is perfectly
usable with blocking the main thread in the synchronous API calls. Or
rather, it works as good as the synchronous API implementation.

One problem are timeouts. The other is that the calls don't detect when
the server dies because the corresponding D-Bus signal is not delivered
(seen in older EDS releases, not sure how relevant it is on master).

As Alexander said, the synchronous API serves a useful purpose.
SyncEvolution is one, simple tests another. +1 for keeping it and fixing
it so that it really works.

-- 
Bye, Patrick Ohly
--  
Patrick Ohly gmx de
http://www.estamos.de/