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

[Adam Tauno Williams <awilliam opengroupware us>]

On Mon, 2011-03-14 at 18:57 +0530, Chenthill Palanisamy wrote:
> On Mon, Mar 14, 2011 at 3:53 PM, Adam Tauno Williams
> <awilliam opengroupware us> wrote:
> > On Mon, 2011-03-14 at 10:09 +0530, Chenthill Palanisamy wrote:
> >> On Thu, Mar 10, 2011 at 6:54 PM, Matthew Barnes <mbarnes redhat com> wrote:
> >> > 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).
> > This is a self-fulfilling prophecy;  I and others have tried to have
> > large address books... which doesn't work... so address books remain
> > "small".
> I agree, the *only* should be removed from the third sentence of mine,
> there could be other address-books.
> While thinking of Xapian for address-book, am not still convinced.
> One could search on various fields such as sender, subject,
> recipients, full-text search etc. in mailer often and xapian is said
> to work much better.
> Although I have not got any profiling information as such, but its
> just from hearing from multiple people.
> But for address-books, the most often used searches would be based on
> name and email. Even if the address-book has 21k or more data,
> a db with good indexing should perform better. The information stored
> will be small when compared to mail content.. Well these are just
> my observations, are there any other cases am missing ?

This makes sense to me [I've no idea really how it is currently
implemented or what the practical alternatives are].  But funny side
note: if I just walk the DAV collection and save all the vcf files to a
directory ... a simple python script can parse each file [using the
vobject module], compare the values to a criteria, and report what items
match... an order of magnitude faster than Evolution.  But the reason
for this is mentioned below.

> > I have a CardDAV/GroupDAV collection of ~21,000 contacts I'd love to
> > have access to via Evolutions WebDAV address book.  But anything more
> > than a thousand or so gets to be unbearably slow.
> AFAIR, there are some UI issues involved here which should be dealt
> with separately.

True,  most importantly [at least for WebDAV address books] why the &@^
$*&@ it issues a PROPFIND to the server to enumerate the collection at
every search?!  Just search the data you have;  it really seems like
update / synchronizing the collection and searching the collection
should be independent events.

I suppose I should get around to filing a bug about that.