Re: [Evolution-hackers] Sqlite cache for address-book storage in EDS
On Mon, 2011-03-14 at 10:09 +0530, Chenthill Palanisamy wrote: > On Thu, Mar 10, 2011 at 6:54 PM, Matthew Barnes 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 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. ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Sqlite cache for address-book storage in EDS
On Mon, Mar 14, 2011 at 3:53 PM, Adam Tauno Williams wrote: > On Mon, 2011-03-14 at 10:09 +0530, Chenthill Palanisamy wrote: >> On Thu, Mar 10, 2011 at 6:54 PM, Matthew Barnes 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 ? > > 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. - Chenthill. > > ___ > evolution-hackers mailing list > evolution-hackers@gnome.org > To change your list options or unsubscribe, visit ... > http://mail.gnome.org/mailman/listinfo/evolution-hackers > ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Sqlite cache for address-book storage in EDS
On Mon, 2011-03-14 at 18:57 +0530, Chenthill Palanisamy wrote: > On Mon, Mar 14, 2011 at 3:53 PM, Adam Tauno Williams > wrote: > > On Mon, 2011-03-14 at 10:09 +0530, Chenthill Palanisamy wrote: > >> On Thu, Mar 10, 2011 at 6:54 PM, Matthew Barnes 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. ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] Branch date?
It's getting to be branching time again. I think in the past we've usually branched when the hard code freeze starts, which would be next Monday. Shall we go with that again or does anyone have a desire to branch sooner? (Speaking for myself, I don't really have anything ready to land yet.) ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Branch date?
On Tue, Mar 15, 2011 at 3:07 AM, Matthew Barnes wrote: > It's getting to be branching time again. I think in the past we've > usually branched when the hard code freeze starts, which would be next > Monday. Shall we go with that again or does anyone have a desire to > branch sooner? Am fine with branching on Monday after the hard-code freeze.. - Chenthill. > > (Speaking for myself, I don't really have anything ready to land yet.) > > ___ > evolution-hackers mailing list > evolution-hackers@gnome.org > To change your list options or unsubscribe, visit ... > http://mail.gnome.org/mailman/listinfo/evolution-hackers > ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
