Re: [Evolution-hackers] Restructuring direct access mode

[Tristan Van Berkom <tristanvb openismus com>]

On Fri, 2013-03-15 at 13:57 -0400, Matthew Barnes wrote:
> 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

So you would put the client facing direct access api in a separate
library, with only one function ?

I'm not sure this makes more sense than the current way
we have libebook (client side) and libedata-book (serverside)
both depending on libebook-contacts (addressbook related types).

In fact, libebook-contacts even becomes an interesting API all
on it's own without pulling in the EDS ecosystem (an interesting
and practical API dealing with VCards).

What makes you propose that a different dependency chain would
be any more straight forward than the one we've successfully
created for EDS 3.8 ?

> 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?

One particular objection.

I like the idea of providing subclasses and the like, and perhaps
we can achieve that in any case, but what I was aiming for
with e_book_client_connect_direct_sync() achieves two things
that I would like to protect:

  a.) e_book_client_connect_direct_sync() should not fail
      just because direct access is not possible, instead
      it should fall back to normal access.

      So the API to connect to the addressbook should
      perhaps only create a EBookClientDirect object
      if possible and fall back to creating a regular
      EBookClient if the backend does not support it.

  b.) Basically a main reason why we designed the API
      the way we did (i.e. fallback instead of error out),
      is because assuming that direct access works well,
      we would like to propose that eventually
      e_book_client_connect_direct_sync() be deprecated.

      e_book_client_connect() should IMO eventually do
      everything that e_book_client_connect_direct_sync()
      currently does.

In other words, there's no reason for client code to
explicitly decide to use direct/indirect access, direct
access, being more efficient, should be used in any
case that it's available.

We only thought that for the next release or two it would
be less intrusive if the direct API was only available
with an explicit call.

We expect that, given a release cycle or two to mature,
direct access will just become the default behavior for
any backend which supports it.

Best Regards,
     -Tristan