Re: [Evolution-hackers] Contacts database modifications history

[Milan Crha <mcrha redhat com>]

        Hi,

On Wed, 2014-04-16 at 14:00 +0200, Patrick Ohly wrote:
> It just means that whatever API
> gets added that only works with local storage needs to be clearly marked
> as "local only" in the documentation and/or there has to be a discovery
> mechanism for determining whether a  certain EBookClient instance
> supports it.

Right, there are the backend capabilities, which can be used for this.
If the backend supports some functionality, it also advertises that in
its capabilities.


> The more likely failure is that EDS emits the change, but then the
> computer is shut down before the receiving side gets a chance to handle
> it => EDS DB was modified, change log in the receiver was not.

I see, you want a fool-proof solution. That makes perfect sense.

You already mentioned that it would be better to use the same sqlite
database as the contacts are stored in, rather than using a separate
sqlite database file, one for data and one for backlog.

The local address book uses EBookSqlite, thus what about making it an
EExtensible? That way, with some EBookSqlite (internal and external) API
changes, you would be able to create a new module, which will be loaded
for each EBookSqlite instance and which will be able to step in during
e_book_sqlite_add_contact/s, e_book_sqlite_remove_contact/s, possibly
updating an internal table with a list of changes as needed, within the
same transaction as actual contact's update? With a good API changes you
might be able to even get the contact before and after the change, so
you can create your diff. You definitely do not want to do the backlog
for each EBookSqlite, because it's supposed to be used as the current
local contacts cache (to be replaced with an OfflineCache in the future
for the remote backends), thus some checking whether the backlog should
be created, based on the actual book being this instance used with [1],
is necessary.

I believe the use of the same transaction is the most important part for
you, while that should be satisfied with this EExtensible solution, with
absolutely no changes on the EBookClient* public APIs.

        Bye,
        Milan

[1] Either check based on the actual folder being used for the
EBookSqlite, or pass also an ESource to the e_book_sqlite_new functions
and create a new ESourceExtension, where you would be able to turn on
backlogging selectively, without any guessing. The ESourceExtension can
be done in the same module as the backlog creator.