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

[Matthew Barnes <mbarnes redhat com>]

On Thu, 2010-07-01 at 14:57 +0200, Milan Crha wrote:
> for EBook it is, all the async API there uses 'status' as an indicator
> of the operation result in the async callback. I'm changing it to GError
> too. I'm still on ECalBackend, but it seems some similar change will be
> in ECal too, though I'm not sure yet, I'm not that far. I'll summarize
> changes in the bug report when I'll be done with it, to have them
> written somewhere.

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.

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.

The window for API cleanups and ABI breaks in these libraries is closing
fast.  We could at least rough in a common base class now with a private
data section and get the ECal/EBook ABI break out of the way.  Then add
API to it later.

I had the name "EClient" in mind for the base class:

    GObject
      |
      +-- EClient (implements GInitable)
            |
            +-- EBook
            |
            +-- ECal