[Telepathy] Folks status, the addressbook problem

[Xavier Claessens]

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.