Thanks for this detailed proposal. Folks certainly needs some work with respect to performance, so all ideas are welcome. I agree with the issues that Philip brought up, so I'll just add a couple other points below. Conclusions after the quoted text. On Tue, 2012-10-30 at 15:40 +0100, Xavier Claessens wrote:
Addressbook uses cases ====================== 1) The Contact list app, it needs to load all contacts, let user (un)merge some of them. 2) The Chat/Call/FileTransfer/etch apps, they need to load only one, or small subset of individuals. 3) It needs to scale with 5-10k personas in some stores. Blocking 2s to display an incoming call window is not an option. Pre-loading the full addressbook in multiple apps is suboptimal as well. 4) We want to be smart to implicitly merge contacts, but user always has the final word and could unmerge some contacts we decided to merge.
We've had concern from the beginning, reflected in our API and behavior, that not only could we accidentally link together unrelated people, but that someone could /maliciously/ get themselves linked to someone else in an automated system. This would allow them to pose as someone else (particularly for text chat, but theoretically for anything that didn't involve video or audio communication). That being said, I hate requiring users to manually link personas. We automatically link in the very few cases that we are guaranteed that there's no way to spoof identity, but it doesn't help most people (it essentially only affects self-contacts). Our best option is probably a nice helper application that presents all the suggested matches but makes it easy to unselect some matches before linking the rest. See my other mail in this thread for more detail. Factoring all these in, how much of the original proposal do we all agree on? I think it's these points (with some of mine added): * The aggregator needs a lot of performance work, but we really need solid tests before making any changes to it, as it's unfortunately very complicated. As Philip suggested, I'm inclined to predict most benefits would come from better data structures. * Doing caching at the Telepathy level, not in Folks * Pushing everything into a daemon and making it send everything over D-Bus or putting all our linking data in DConf would probably make performance worse, not better * Specific use cases, like looking up an Individual for a given Persona, need to be fast. The case of "we have an incoming call; fetch the avatar, name, and a couple other critical pieces of data for the caller, QUICKLY" may need to be special-cased, but hopefully not. * Search API (bgo#646808) may speed up some retrieval cases * Support lazy-loading contact attributes (bgo#648805) should also speed up our start time in most cases. Applications would tell Folks exactly the details they care about, and we would only load that. Less data to manipulate everywhere means less work to do, less total time, etc. Regards, -Travis
Attachment:
smime.p7s
Description: S/MIME cryptographic signature