On Thu, Mar 10, 2011 at 6:54 PM, Matthew Barnes <mbar...@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"  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. > > >  http://notmuchmail.org/ > > _______________________________________________ > evolution-hackers mailing list > email@example.com > To change your list options or unsubscribe, visit ... > http://mail.gnome.org/mailman/listinfo/evolution-hackers _______________________________________________ evolution-hackers mailing list firstname.lastname@example.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers