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. 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. thoughts? Jeremy On Tue, Oct 30, 2012 at 8:53 AM, Xavier Claessens <[email protected]> wrote: > Le mardi 30 octobre 2012 à 15:40 +0100, Xavier Claessens a écrit : >> Folks DB >> ======== >> Folks is about merging Personas, so I suggest having a separate DB that does >> just that. An individual is in the DB if and only if it has more than one >> Persona. The DB must be optimized for 2 types of queries: 1) given an >> individual >> uid, give all its linked persona uid. 2) given a persona uid, give its >> individual uid. >> >> This means we have to define persona and individual uid: >> >> * Persona uid: I suggest using N9 format: >> "telepathy://<account path>/<contact-id>", >> "eds://<ESource id>/<EContact id>". >> Or anything from which we can fetch a TpContact or EContact. >> >> * Individual uid: there are 2 cases, does it have just one Persona or more? >> - just one: use its persona uid. >> - more than one: use a uuid and keep it in the DB. >> >> We need change notification when that DB is changed. Probably something like >> dconf where a daemon does the writing and clients does direct reading. Maybe >> crazy idea but could we actually use dconf for this? we could have >> /org/folkd/<individual uid> keys of type "as" which is a list of persona uid. >> I'm not sure how dconf will scale if we have thousands of such keys? >> >> I think merge/unmerge operations are not something we do daily, so it's not >> the >> most important operation to optimize. > > What I did not cover is the automatic merging. I think an app that loads > the whole contact list (e.g. empathy and gnome-contacts) could suggest > some personas to merge based on heuristics, like Marco's N900 plugin. If > the match is really good it could proceed even without telling the user > (be careful, parents could share a landline number). So I like to keep > those implicit/automatic merging outside of Folks. So Folks does not > make any difference if 2 contacts are merged because they share an email > address, or if user just decided to merge, that would keep things easier > in folks, and in most of the case we really need to ask user in UI > anyway. > > _______________________________________________ > telepathy mailing list > [email protected] > http://lists.freedesktop.org/mailman/listinfo/telepathy _______________________________________________ telepathy mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/telepathy
