Re: [Evolution-hackers] Sqlite cache for address-book storage in EDS

[Matthew Barnes <mbarnes redhat com>]

On Thu, 2011-03-10 at 08:13 +0100, Milan Crha wrote:
> do not forget that the DB cache is compiled conditionally, because some
> distros do not ship libdb. Using SQLite for this was mentioned months
> ago, only no-one got time to actually do it, so go for it.

Also, as far as I know there is still licensing issues between Berkeley
DB's Sleepcat license and [L]GPL, which is how libebackend was born.

https://bugzilla.gnome.org/show_bug.cgi?id=465374

I'm +1 on dumping Berkeley DB.


> Only think of two things:
> - using binary storage for this kind of data is bad for cases where
>   the binary file breaks, either due to an update/downgrade of the
>   library providing access to it, or just by a crash. It's not so hot
>   with camel as SQLite has there only summary data, but if you want to
>   store also real data in it, then it can be a problem. There are people
>   having issues recovering their data from addressbook storage already,
>   but if you are going to do any change on it, then it would be good to
>   think of that from the beginning. It would be good to store raw vCards
>   in some plain text file(s) which will be "indexed" by SQLite summary.
>   This plain text file(s) will be then easy to import to evolution if
>   something goes wrong, and with erasing SQLite file user will not
>   loose any valuable data. (I'm thinking of a flat maildir approach
>   here.)

Milan raises a good point about binary formats versus text.  Would be
good for the raw data to remain human readable.

Okay, this might be a long shot but I'm gonna throw it out there anyway:
would it make sense to look at using Xapian to index a directory of raw
vCards?

We've been talking about moving to "notmuch" [1] for mail indexing, and
"notmuch" is built on Xapian.  Trying out Xapian for address books might
be a good test drive for using it with mail.

The catch is, Xapian is written in C++.  So we'd likely have to hand
write our own GObject bindings for it in C.  That's what makes it a long
shot.  But we could look to "notmuch" even WebKit/GTK+ for examples of
binding C++ to C.  My C++ is rusty but I still have my Stroustrup text
book.


[1] http://notmuchmail.org/