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

[Chenthill Palanisamy <pchenthill gmail com>]

On Thu, Mar 10, 2011 at 6:54 PM, Matthew Barnes <mbarnes redhat com> wrote:
>
> 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.
Yes, it makes senses to store it that way. If we can index the data in
sqlite summary and store
VCards in the way we store individual mail data, it should be sufficient..

>
> 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?
Am not sure if its worth doing this for adress-book. Am just making an
assumption that the
address-book content may not be as huge as mail data. The only address-book data
that would be large enough would be GAL (exchange) and
SystemAdressBook (groupwise).
I think sqlite should suffice in indexing this..

>
> 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.
To be honest, I wont be having that much time for testing this for
address-book. Jony
was trying to evaluate the performance between sqlite and notmuch mail indexing
for mails, any updates there Jony ?

- Chenthill.
>
> 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/
>
> _______________________________________________
> evolution-hackers mailing list
> evolution-hackers gnome org
> To change your list options or unsubscribe, visit ...
> http://mail.gnome.org/mailman/listinfo/evolution-hackers