Re: [Evolution-hackers] Contacts database modifications history

[Milan Crha <mcrha redhat com>]

On Tue, 2014-04-15 at 13:16 +0000, Potrola, MateuszX wrote: 
> I would like to have ability to receive some kind of notifications (or
> store information in some additional database) about modifications
> made to contacts database during synchronization.
        Hi,
the compose of a "diff" for done changes is probably the hardest thing
on this whole thing you'd like to achieve. There is always (at least)
one place where this "diff" should be computed. I'm not much willing to
add it into evolution-data-server itself, because it has no good use for
it (at least not as of now).

As Patrick pointed out, the previous implementation had sever issues
which made the feature basically unusable. If we cannot make it done for
all backends, then it probably might not be part of the
evolution-data-server.

I think the best parallel is the Exchange Web Services protocol with its
ChangeKey-s. The ChangeKey is used to identify a state on the client
side, with which the client asks for a list of changes being done since
this state. I have no idea how the history is managed in the background,
but it works pretty well. I would be still afraid of the actual disk
usage of the history, but the ChangeKey marker is the part which was
missing in the previous implementation an the eds side.

Anyway, I would prefer if you could create a plugin to SyncEvolution
(does it support plugins?), also because it's the software you are
targeting, not evolution-data-server code, and use EBookClientView on
the book used by SyncEvolution, with optional usage of fields of
interest. The flow, from my point of view, would look like this:

a) user initiates a synchronization in SyncEvolution
b) before SyncEvolution starts the addressbook synchronization,
   the new plugin opens the EBookClientView on the same book and
   sets it up according to its needs (either fields of interest, or
   a basic "not field-is-empty X" filter (filters might be better here,
   also because it's possible that fields of interest will be dropped in
   a favor of Tristan's cursors)).
   Note that once the EBookClientView is started, the client receives
   notifications for all the satisfied contacts, which does the initial
   population of the view (as you mentioned, many contacts will mean
   performance and memory usage impacts).
c) once the EBookClientView receives a "complete" signal, which
   indicates that the initial fill of the view is done, the
   SyncEvolution can starts its synchronization
d) each of the modifications will be received in the EBookClientView
   signals, newly the "objects-added" signal will be emitted also for
   old contacts which satisfy the filter now, same as
   the "objects-removed" signal not necessarily mean that the contact
   had been completely removed from the book.
f) once the SyncEvolution is done, the EBookClientView can be also
   stopped and released.

Still, all this looks too complicated, adding unnecessary burden,
consider that you specifically target SyncEvolution changes, thus why
not to extend SyncEvolution to write its own backlog of done changes in
some place, where your application may just read them from? If the
changes are marked with a date+time+sequence "ChangeKey-s", then you can
get a very nice overview what SyncEvolution did and when. I think of the
changes in the SyncEvolution side also because all the EBookClientView
engagement feels like a reinvent of the wheel, considering that
SyncEvolution does the changes and it knows what it does the best.

On Wed, 2014-04-16 at 09:02 +0000, Potrola, MateuszX wrote:
> What is the probability of failure of emitting signals ?

The probability is close to 0. If it happens, then it's a bug in the
backend (or the related code) and should be fixed as soon as discovered.

        Bye,
        Milan