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 _______________________________________________ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers