Re: [Evolution-hackers] Contacts database modifications history

[Tristan Van Berkom <tristan upstairslabs com>]

On Thu, 2014-04-24 at 15:28 +0200, Patrick Ohly wrote:
> On Wed, 2014-04-23 at 16:08 -0400, Tristan Van Berkom wrote:
> > 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).

Hi Patrick,

Sorry if I've slowed you guys down by not replying sooner.

I did reread this thread, from what I understand there are two
requirements, one of them is to receive more information in change
notifications (i.e. perhaps providing the old vcard and new vcard of a
given modified contact will solve this completely) and this requirement
can be satisfied without any intimate knowledge of the backing SQLite DB
(the EBookBackendFile already has all the needed information to emit a
better notification to EBookClientViews).

The other requirement if I understand correctly is to record change
notifications, and we want to persist these in the same DB because in
the case of a power loss or crash, it would be nice to have the
modifications saved at least until which time they are "claimed" later
on by some software which was interested in receiving the change
notification - this strategy minimizes the risk of lost "change
records".

> I agree with you, plugins should not make assumptions about the content
> of sqlite database. This needs to be documented clearly.
>
> However, the goal is not to let plugins access the existing tables.
> Instead, the goal is to let plugins create their own custom tables and
> update them as part of the same transaction that EBookSqlite uses to
> update its own tables. Name clashes need to be avoided, but that is a
> minor issue. We might also want to add hooks for DB updates and locale
> changes.
>
> Does this address your concern?

Honestly not really no, but it shouldn't stop you from getting things
accomplished, perhaps there is a middle path which can be walked.

> From what I understand, fleshing out a good API for tracking a history
of vcard records/changes is too complicated to be done quickly (there is
a lot to consider, is there one global history that is flushed
automatically by the EDS backend ? is there a separate copy of the
history for every external entity which is interested in later
collecting the changes ?).

In this case I might propose that a plugin be developed in-tree, sharing
a private header file giving the experimental plugin access to some
internal functions such as:
  ebsql_exec(), ebsql_exec_printf(),
  ebsql_start_transaction(), ebsql_commit_transaction(),
  ebsql_rollback_transaction()

This would allow us to continue development without making premature
decisions about the plugin API - the experimental "history plugin" could
be usable in it's current in-tree form and not have strong API/ABI
guarantees.

When the experimental plugin matures and we are finally satisfied with
it's API then we could easily adapt it's functionality in EBookSqlite
proper - all of this without ever having officially exposed the DB
handle in any public API (and without preventing you from using the
experimental plugin API in the meantime).

Does this sound reasonable ?


Cheers,
    -Tristan