Le mardi 30 octobre 2012 à 09:30 -0600, Jeremy Whiting a écrit : > Xavier, > > First of all thanks for looking into Folks performance issues. That's > one aspect of Folks I haven't gotten into yet. > > I think your proposal makes sense in that it moves much of the > complexity of merging personas, but I do think automatic merging is > still important and should be handled by libfolks itself, otherwise > automatic merging could happen using two different heuristics.
Is it really a problem to have different heuristics for auto-merging? Once a client decided to merge some personas, it's made permanent for all clients, until user explicitly unmerge. So we would still have the same roster view everywhere. Of course if one buggy client decide to merge everything, you're doomed. But I don't think we can do anything against that anyway. > 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. Regards, Xavier Claessens. _______________________________________________ telepathy mailing list telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
