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? Regards, -Travis
Attachment:
smime.p7s
Description: S/MIME cryptographic signature