On Wed, 2011-05-04 at 13:04 +0200, sean finney wrote: > Hi Everyone, > > I spoke with chen on IRC this morning and got hinted at a preliminary > implementation of EBookBackendSqliteDB sitting in -ews. Since there > are some benefits of something something like this make it's way to > a common place that could be used by -mapi as well, I thought I'd do > a quick feasability review to see what problems there might be. > > Questions/commments/suggestions follow. Please let me know what you > think! > > * No backend _get_contact/_get_contacts equivalent. Should be > easily implemented. _get_vcard_string ==> _get_contact, i have not added an API return EContact to let the callers decide whether they want to parse the string to EContact.
i have not observed any use cases for get_contacts needed by the backends. _book_backend_sqlitedb_search would server the _get_contact_list API in the backend and also for querying using a search query to fetch the contact list. > * _add_contact/_remove_contact should be renamed to > _add_contacts/_remove_contacts to be consistant with other backend > methods that take lists. Makes sense as it already acts on multiple contacts. > * but also having a _add_contact/_remove_contact that takes just a uid > (similar to other backends) would be useful remove_contacts already takes only uid. I do not know how far _add_contact with just the uid would be helpful. Which backend would need it ? > * -mapi seems to use one cache per-profile-per-folder, but the sqlitedb > backend takes these as calling parameters. Not really a problem and > I think it may be reasons to have one cache db anyway, so this is > just more of an observation. > * _get/_set/_delete interfaces are needed for cache metadata (last modified, > etc). Am working on it atm. > * if folder metadata is going to be free-form, it could be better to have > a key->value table ( folder_id_id int, key_name text, value text ) rather > than arbitrarily numbered text/binary fields. I was thinking of allowing the backends to store key value pairs using a bdata column which could be populated with xml key-value data. Would be it be good idea ? > * not sure of this one: given there may be multithreaded access to the db, > do we need to provide any external "big locks" on reads/writes? maybe > the built in sqlite stuff is sufficient. > * not sure of this one: beyond the COMMIT statements, should there be > something to periodically sync the db beyond the backend "finalize" > method? afaik it would be taken care of sqlite vfs and commit should be enough. > Unsure with commit is sufficient to get consistant on-disk in case of > crash, etc. > * do we need a set_populated/is_populated equivalent? or maybe that could > be solved in the cases it's needed wtih metadata. I think I added it and removed later thinking it might be redundant with sync_data column, but re-thinking now am clear both are independent. Will get that added... > * do we need a set_time/get_time equivalent? or maybe that could > be solved in the cases it's needed wtih metadata. There is a sync_data column which can be used for the same with either last_modified date or sequence numbers or some synchronization text. > > @chen: I don't know how active you plan to be on this, but if you're looking > to offload any work, I can pick up anything that results from the above if > you like. Just let me know! The work is almost over, but will let you know once i finish the testing and you can directly make changes if you require anything more there :) - Chenthill. > > > Sean > _______________________________________________ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers