> > 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) > > Does it have to be a separate sqlite database? You could also use a new table > directly in the sqlite datbase also used for the contact data. > No, it don't need to be separate sqlite database, but I was thinking about case where database will be locked because some operation like locale update is ongoing, with separate database modifications data could be still concurrently accessed.
> > Cons: > > > > - Quite complex implementation, especially if some API needs to > > be exposed by EBookClient > > Perhaps the API for reading the changes could be limited to direct read > access, > potentially outside of the core libebook? Direct access will be fine for me > > 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). > > Note that the EBookView could also be used as-is by doing the detailed check > of > what was modified in the receiving process. For new contacts it is very > likely that > the fields of interest were added, and updating contacts happens rarely enough > that the overhead of sending updated data that then completely gets filtered > out shouldn't matter. I'm not sure about using EBookView as-is and checking what was modified in receiving process, because notification will be sent when data in contacts database will be already changed, so receiving process should first get all contacts from database before starting synchronization to be able to do detailed check of what was modified, which in case of large number of contacts may unnecessarily increase memory consumption, especially as you've said that updates happens rarely. > > 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. > > I see that as the most important reason why I would prefer the more integrated > approach. What is the probability of failure of emitting signals ? Intel GmbH Dornacher Strasse 1 85622 Feldkirchen/Muenchen, Deutschland Sitz der Gesellschaft: Feldkirchen bei Muenchen Geschaeftsfuehrer: Christian Lamprechter, Hannes Schwaderer, Douglas Lusk Registergericht: Muenchen HRB 47456 Ust.-IdNr./VAT Registration No.: DE129385895 Citibank Frankfurt a.M. (BLZ 502 109 00) 600119052 _______________________________________________ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
