Re: [Evolution-hackers] Contacts database modifications history

[Milan Crha <mcrha redhat com>]

On Tue, 2014-04-22 at 13:53 -0400, Tristan Van Berkom wrote:
> Sorry to interject, I don't have time to write such a lengthly email,
> but I would like to warn against exposing the database pointer in the
> EBookSqlite API to the world.

        Hi,
no problem, I was waiting for your insight, to be honest.

> Handing out access to the internal DB handle seems to be an open door to
> a world of trouble (I can envision bug reports going INVALID because
> said user has some kind of non-compliant plugin that is messing directly
> with the tables *owned* by EBookSqlite, or creating tables that
> EBookSqlite might try to create in a future EDS release)... in other
> words, EBookSqlite can only ensure the stability/reliability of it's DB
> if it can at least insist to be the only API that is ever used to access
> the said DB. 

I do not consider this a problem. Any change can cause similar trouble,
being the sqlite table accessible from outside or not. All that stands
on an expectation that the hypothetical plugin will behave sanely and
will be good to others. That might mean that the plugin will create its
own tables with some prefix, like plugin name, and so on. Ideally, the
plugin may not touch the tables of EBookSqlite directly, but only
through the API. Just implicit basic rules. You can always get
"malicious" software, of course, but then the only real way to deal with
it is to get rid of that malicious software.

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.
        Bye,
        Milan