[Telepathy] Folks status, the addressbook problem

Travis Reitter travis.reitter at collabora.co.uk
Fri Nov 2 09:14:11 PDT 2012

On Fri, 2012-11-02 at 09:52 +0100, Xavier Claessens wrote:
> Le jeudi 01 novembre 2012 à 14:24 -0700, Travis Reitter a écrit :
> > On Thu, 2012-11-01 at 21:19 +0000, Philip Withnall wrote:
> > 
> > > Are you thinking of Tpf.Persona.dup_for_contact()? It takes a TpContact
> > > and spits out a Tpf.Persona. From the Tpf.Persona, you can get a
> > > Folks.Individual from its ‘individual’ property.
> > 
> > No, I meant a general any Persona -> their Individual. It's also
> > possible that it was something like Persona.uid -> their Individual.
> Afaik you can do that only if you loaded the full aggregator. Which is
> IMHO not something we want to do in half a dozen processes.

Right. That would be true in any case though - even if we cached all the
links in some special DB (it would just load much more quickly).

Maybe a link cache is one of the things we need. In the common case, any
updates we would do after loading the cache should be invisible to the
user. The problem this introduces is that the "notify::is-quiescent"
signal signifies all the major dust has settled (which, in the worst
case, isn't true immediately after the cache would be loaded). But we
could introduce a signal like "notify::cache-loaded" for just after the
cache load. Most applications would replace all their instances of
listening to is-quiescent with this new signal.

And we could amortize the work done by the aggregator after the cache
load over a longer time period to impact the CPU less, since the set of
Individuals should be in a decent state immediately after the cache load
in most cases.

Even farther in the future, we might be able to come up with a heuristic
that lets us refresh the Individuals (and their Personas) who are most
likely to have changed since we last wrote out the cache. I can hear
Philip cringing audibly already.

What does everyone think about that?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4042 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/telepathy/attachments/20121102/13a241ae/attachment.bin>

More information about the telepathy mailing list