On Fri, 2012-11-02 at 09:14 -0700, Travis Reitter wrote: > 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).
Agreed. > Maybe a link cache is one of the things we need. In the common case, any *snip* All sounds pretty similar to thoughts I’ve had. A cache should speed initial aggregation up, but it can imagine lots of corner-case bugs where the cache gets into a stale state. > 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. I think that kind of work should only be done after all the low-hanging fruit has been picked by the cache, and then after a lot more profiling work. Philip
signature.asc
Description: This is a digitally signed message part
_______________________________________________ telepathy mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/telepathy
