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 mbar...@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 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 awill...@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 mbar...@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 ? 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 awill...@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 mbar...@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. ___ 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 mbar...@redhat.com 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
