Re: [Evolution-hackers] Heads-up: EBookBackend/EBook ECalBackend/ECal ongoing API changes

[Milan Crha <mcrha redhat com>]

On Thu, 2010-07-01 at 12:43 -0400, Matthew Barnes wrote:
> If I understand all this correctly, it looks like what's being done here
> is allowing backends to report both an error code and a detailed error
> mesage to the client library, rather than having to set some generic and
> often less-than-helpful message from an error code alone.
> 
> Looks like most of the impact in libecal and libebook is in the callback
> function signatures for asynchronous operations.  The synchronous APIs
> will remain unchanged AFAICT.  Chen/Milan: correct me if I'm wrong.

	Hi,
yes, correct, and the "cal-opened" signal in ECal. (See my reply to
Patrick's email.)

> You know, this might be a good time to starting talking again about a
> common base class for ECal and EBook.  That would allow us to resolve
> some of the stupid inconsistencies between the two classes for common
> operations like opening, online/offline mode, ERROR REPORTING (ties into
> this thread), server crash detection, etc.  It would also let us rewrite
> some of the async ops GIO-style.

Well, you named pretty much everything what is common, there's nothing
more, and error reporting is already in there, as ECal uses GError in
the front end, same as synchronous API for EBook. There is one
difference in ECal, it can report backend error message in any time, and
it's propagated through signal to listeners on ECal object. From my
point of view we are talking about approximately two functions and few
signals being common for them both, which, I thing, doesn't worth the
effort. And the async API can be done even without EClient, right?

Just my opinion. Maybe take it in a separate bug.
	Bye,
	Milan