Re: [Evolution-hackers] Contacts database modifications history

[Tristan Van Berkom <tristan upstairslabs com>]

On Wed, 2014-04-23 at 08:26 +0200, Milan Crha wrote:
[...]
> It's like the direct read access for books, more or less, you also
> expose private eds API to client side, which should stay server-side
> only, but you expect that the client will behave sanely with it.
>
> I have the same expectations for the EBookSqlite plugin(s), thus, if the
> plugin will follow the rules, then I do not see any problem in exposing
> the sqlite table. It has its advantages to access the same table, thus
> I'm all for it.

Hi Milan,

I don't altogether agree with your analogy, DRA is offered through the
EDataBook APIs yes, and those APIs need to be better protected indeed,
it's hard to police who has access to calling them, however the DRA is
only supposed to ever be accessed by API/ABI stable user facing APIs
(i.e. we *expect* that users will use DRA via EBookClient APIs, and we
reserve the right to break API in libedata-book so long as we preserve
the functionality of stable user facing APIs - arguably the EBookBackend
entry points for people to develop plugins should also be a stable API
but are not quite there yet).

That said, even though I don't quite agree with your analogy you do make
a fair point, in my point of view we should be striving to strengthen
our API and improve control over what EDS code can be leveraged by third
parties, thus limiting what is considered a valid use case of EDS. 

This is my prerogative and I can accept that it is not shared with the
maintainers of EDS, nevertheless I would still like to caution against
opening up the SQL tables owned by EBookSqlite to be shared with plugins
(it may take a little more time in the beginning to flesh out a well
defined interactive API that satisfies the needs of plugins, but this
will pay off in better long term stability, anyway this is my opinion).

Best Regards,
    -Tristan