[Telepathy] Folks status, the addressbook problem

[Jeremy Whiting]

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 <xclaesse at gmail.com> 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
> telepathy at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/telepathy