On Wed, 2014-04-16 at 09:02 +0000, Potrola, MateuszX wrote: > > > 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.
Doesn't sqlite allow reading while a write is ongoing? > > 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. This is a valid concern. Both doing the diff inside the EDS backend (as part of the write) or in SyncEvolution would work better. -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. _______________________________________________ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
