[Telepathy] Folks status, the addressbook problem

[Travis Reitter]

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
-------------- 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/20121101/4d51378b/attachment.bin>