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

[Matthias Braun <matze braunis de>]

Am Montag, den 14.03.2011, 08:40 -0400 schrieb Adam Tauno Williams:
> 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.

The problem here is that obviously contacts on the server could have
changed since the last search. How else can you detect this? Do the
propfind results get an ETag, then this would be a good way to speed
things up.

Apart from that I could obviously add some timout, which would only
query the server every N-minutes and do faster queries from cache
only...

Anyway I'd be happy to get more input from people on the server side - I
wrote and used it only for my own contact collection which is ~200
contacts on an apache mod_dav server, because that was enough for me and
I never managed (and wanted) to setup one of the "big" groupwares just
for myself.