Re: [Evolution-hackers] New 'eclient' branch in eds

[Milan Crha <mcrha redhat com>]

On Mon, 2011-04-18 at 15:36 +0100, Philip Withnall wrote:
> I haven't had a chance to look at it all in detail, but two things
> strike me from a quick glance:
> 
>  • If we're following the GIO async pattern, why do the
> e_data_book_respond_*() functions still exist?

	Hi,
the server part (e-data*) didn't change much, not with respect of API
changes, apart of dropping outdated functions. The part which changed
was the client side. The 'respond' functions are there to tell the
client, from the server, that the certain operation was finished.

What I forgot to mention in the previous mail is that the "asynchronous"
server operation have been divided into two parts, the first is to start
the operation by calling particular function on the client side, and
then notifying the client from the server that this operation was
finished. It's done by a "done" signal for the particular operation. It
avoids timeouts on DBus, as long as the main thread isn't stuck, because
when an operation is started, then the first thing the EDataBook/Cal
does is a response to the client with an operation ID, (this ID can be
used to cancel this particular operation). Only after that is the
function run and is considered running until backend finishes it by the
'respond' function.

The only disadvantage I faced with this approach is that the _sync
client calls are supposed to run their own mainloop, to behave like
blocking, but still being able to receive the done notification, when
invoked from the main thread.

>  • Please, please, please add some documentation to the new EDataBook.
> Trying to understand how the old one was supposed to function was a
> nightmare, and I would hope that the same mistake isn't repeated with
> the shiny new version.

Yeah, can be added any time later, though you may use EBookBackend
documentation, rather than a wrapper around dbus and factory, for which
the EDataBook is.

	Bye,
	Milan