Re: [Evolution-hackers] EBookBackendSqliteDB comments

[sean finney <seanius seanius net>]

Hi!

On Thu, May 05, 2011 at 11:20:45AM +0530, Chenthill wrote:
> >  * 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.

Ah, yes, I think that would work fine.

> 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.

Right, so I think that whole bullet point could be discarded.

> >  * _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 ?

Okay, I think I worded this one poorly.  What I meant was having the
"singular" form of _add_contacts/_remove_contacts (that doesn't use
a GSList but instead a single contact).  So that the calling application
doesn't need to make a 1-item list every time some async callback
acts on a single contact.

> >  * 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 ?

My own preference would be for something leaner and not requiring XML ,
since it would be embedding one structured/serialized data (xml) within
another (sqlite column), which I suspect would result in code more
complicated than it needed to be (getting/setting and
serializing/unserializing vs just getting/setting, esp with multiple
threads, is what jumps to mind).

But I don't have a particularly strong feeling on this, and it's probably
not ever going to be enough on the critical path to matter though.
It's just more of a gut feeling about how the metadata would be used,
and how it might be simpler/safer/cleaner/faster on the implementation
side key/value storage was used to reflect the key/value api unless
there's a pressing reason to have XML.

But I will defer to what you and the other evo folks think, since ultimately
the caller shouldn't be too concerned with the implementation details,
as long as the API provides the key/value functionality.

> > @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 :)

Okay, sounds like a plan!



	sean

--