[Evolution-hackers] Restructuring direct access mode

[Matthew Barnes <mbarnes redhat com>]

I'd like to restructure the new direct access mode for address books a
bit for Evolution-Data-Server 3.9.1.

Tristan's client-side implementation looks to me like it really wants to
be a subclass.  It basically intercepts and overrides entire EBookClient
methods with its own behavior, which is what subclasses are for.

Unfortunately we never anticipated a need for subclassing EBookClient or
ECalClient, and they currently lack overridable method pointers in their
class structures.

I suggest we suffer an ABI bump and correct this for 3.9.1.  It's a bit
of a backward-compatibility break for anyone already using this feature,
but better to make the course correction now while it's still relatively
fresh, as it will only get harder to fix with time.


Specifically:

* Flesh out EBookClientClass and ECalClientClass definitions with
  synchronous and asynchronous method pointers, similar to what we
  already have in Camel.  Also insert plenty of struct padding for
  future expansion, while we're at it.

* Split direct access into EBookDirectClient and EBookDirectClientView
  subclasses.

* Repurpose the e_book_client_connect_direct_sync() function to
  instantiate and configure an EBookDirectClient.

* Split the direct mode APIs into a new library: libebook-direct

* And finally revert the awkward libebook / libebook-contacts split,
  which I doubt anyone will notice.


That would give us a more straight-forward dependency chain:

   libebook <- libedata-book <- libebook-direct


I already have this partially prototyped, and it's passing the test
suite, so I'm confident it will work.

To help ease the transition from 3.8 to 3.10, we could add a fake
libebook-direct.pc file to the gnome-3-8 branch, which would just
require libebook.pc.

There's still time to get the libebook-direct.pc file into 3.8.0,
which is why I'm bringing this up now.

Any objections?

Matthew Barnes