On 30/10/12 14:40, Xavier Claessens wrote:
> 2) The Chat/Call/FileTransfer/etch apps, they need to load only one, or small
>    subset of individuals.

This leads to a new API-use-case apart from the two queries you named
(individual -> all personas and persona -> individual): "tell me about
the persona(s) whose XMPP JID(s) is/are [email protected], as quickly as
possible".

> 1) It does implicit merging based on some persona fields. So if 2 personas
>    (possibly from different stores) have the same email address they will be 
> on
>    the same individual. This is bad because to figure out all the personas of 
> an
>    individual it must parse the full vcard of ALL personas to match the email.

I pretty much agree that ambiguous merges should be done by a "are these
people the same?" UI, like the one on the Marco did for the N900, rather
than by applying a heuristic.

The question that that prompts is: are there any merges that are
sufficiently unambiguous to be considered "the truth" rather than being
a heuristic? (Same name and email address? Same name and XMPP JID?
Having a particular GMail address as email address and having that same
address as XMPP JID? ...)

If you expose particular "backends'" ideas of who is "the same", you're
always going to get into tricky cases when people share an account or
phone number, e.g.:

* Alice Smith has XMPP address [email protected]
* Bob Smith has XMPP address [email protected]
* "Alice and Bob <[email protected]>" is a Persona on my XMPP
  contact list
* It doesn't follow that Alice and Bob are the same Individual - but
  that Persona doesn't really count as an Individual either!

> 2) If user decide to merge 2 individuals, the information that their 
> respective
>    personas belongs together is arbritary stored in EDS as vcard field. Again
>    this means that to figure out all the personas that belongs together you 
> need
>    to parse ALL vcards.

I'd be interested to hear why Folks doesn't already use a separate
lookaside database - I'm sure there must be a reason?

> 3) Telepathy backend does some obscure offline caching. I'm not sure any app
>    actually use that, and I'm not even confident that works correctly.

Isn't the solution to this "give it test coverage and fix it, then"?

    S
_______________________________________________
telepathy mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/telepathy

Reply via email to