|
Hi, In my project I’m using EDS as backend for storing contacts synchronized using Syncevolution. 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. What I mean by modification is information about contact id and list of contact’s fields that were modified (creation and removal of contact can be special case - list of all contact’s fields that are set will be returned). I know that current implementation of EBookView allows for something similar - it allows for detecting newly created, removed or modified contacts, but unfortunately it doesn’t provide details of modification. Additionally I would like to be able to define fields of interest, so notifications will be emitted (or new entry in database will be added) only if one of those fields of interest will be modified. I came up with two slightly different approaches how this could be achieved. First one is to create new address book backend (which will be inhering from file backend used by Syncevolution) and add there logic for calculating modifications when creating/modifying/removing contacts. These modifications will be stored
in additional database, so some additional functions for handling this will need to be added to EBookSqlite class. Here are some pros and cons that I can see: Pros: -
If someone don’t want to keep track of modifications history he can still use file backend -
We can be sure that contacts database and modifications database will be in sync, by using attach function of sqlite (databases will be separated but transaction for modifying both of them will be treated as one transaction) Cons: -
Quite complex implementation, especially if some API needs to be exposed by EBookClient Second solution is to extend current implementation of EBookView and add new signals like: contacts_added, contacts_modified, contacts_removed which will be providing ids and list of modified fields. Also new function for setting fields
of interest will need to be added. Again in the address book backend implementation of logic for calculating modifications and emitting this signals will have to be added (it can be added to current file backend implementation or like in previous idea, new
backend can be created based on file backend). Pros: -
Way of storing modifications information is up to the client application, -
In our case we would like to know what modifications were made during synchronization, EDS is not aware of which modification of contacts are part of which synchronization, but client application has this knowledge. Cons: -
We may end up with out of sync data in case if some signals will be not emitted. Does anyone have other ideas for how this could be handled in EDS ? Which kind of changes in the core EDS code would be acceptable? Just some (hopefully minor) hooks or the entire solution? Regards, Mateusz Intel GmbH |