On Tue, 2012-10-30 at 17:02 +0100, Xavier Claessens wrote:
One of the main problems as I see it with folks is that it's a library, not a daemon. Because of this, every application that uses folks has in memory all the information of each persona and individual. Besides memory use, this takes time as folks IndividualAggregator populates itself with data from the different backends. I have wondered from time to time how much of a speed and memory improvement could be made by making folks a daemon and letting applications talk to it via dbus rather than link to it and load all the data in each separate application. The idea to put the links into a database solves part of this problem by making the linking data persistent on disk, but each application that uses folks still would need to load the whole contact list if displaying a contact list, so if you have Gnome-contacts and Empathy both running that's already two copies of the same data. Maybe that's a moot point since getting the data by dbus would give a copy in each application also, not sure. Feel free to debunk any of my ideas, I could very well be missing something here.I'm not sure we want yet another daemon, with yet another dbus spec. If we can avoid it, like my proposal hopefully does, that's a plus, IMHO. One thing I did not discuss where we already have a daemon, is contact search in gnome-shell. I'm not sure how current search engine works there, but how I would make it is a daemon that keeps a full aggregator loaded (because you'll need to lookup all vcard fields). You give a search string and it returns a list of individual uids. Then your app can load only those individuals and not the whole thing. This was done for gnome-shell because we don't want to block the WM with addressbook change notifications, etc. Note that search dbus API could be implemented by gnome-contact/empathy process if we keep one of them always loaded in background.
Note that there is a (fairly bit-rotten) branch to add search capability natively to Folks: https://bugzilla.gnome.org/show_bug.cgi?id=646808 It needs to be rebased, needs a little re-writing to address issues I brought up in later comments, and I'm not sure when we'll have time to do this, but it could make life easier for at least some of our clients (including a search plug-in for the Shell). -Travis
Attachment:
smime.p7s
Description: S/MIME cryptographic signature