[Telepathy] Folks status, the addressbook problem

[Philip Withnall]

On Tue, 2012-10-30 at 15:40 +0100, Xavier Claessens wrote:
> First, some definitions (taking Folks words):

Note that folks _links_ things; it definitely does not _merge_ them. I
know what you meant, but let’s use the correct terminology.

> State of Folks
> ==============
> The bad:
> 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.
> 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.

Not necessarily. The information about which personas belong in which
individuals could be cached.

> 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.

gnome-contacts uses it to be able to list IM contacts when those IM
accounts are offline. I’m fairly confident that it works correctly. (At
least, I haven’t seen any bug reports about it since it was last poked.)

> Offline Telepathy account problem
> =================================
> To have the same roster when we are online and offline, we need to cache
> telepathy roster. If the email address of an individual comes from a TpContact,
> it makes no sense to loose it when we go offline.

This is exactly what folks’ “obscure offline caching” does. Moving the
cache into Telepathy would be great.

> Folks DB
> ========
> Folks is about merging Personas, so I suggest having a separate DB that does
> just that. An individual is in the DB if and only if it has more than one
> Persona. The DB must be optimized for 2 types of queries: 1) given an individual
> uid, give all its linked persona uid. 2) given a persona uid, give its
> individual uid.

Problems with a separate DB:
 1. It is not replicated across the user’s systems. Having gone to the
effort of linking all their contacts together on their desktop, they
want the changes to magically appear on their laptop. This currently
works nicely if the user uses a Google Contacts address book in EDS as
their primary persona store.

 2. As far as I remember, many of the folks backends require that the
whole contact list (or equivalent) be fetched by folks, even if folks
only wants a single persona. So there unfortunately isn’t much advantage
to be had in rearchitecting folks to optimise for the first query type
you mention.

> This means we have to define persona and individual uid:

Folks already has a defined format for persona and individual IDs, and
we spent an excruciatingly long time discussing it at the IM, social &
contacts hackfest last year.

> We need change notification when that DB is changed. Probably something like
> dconf where a daemon does the writing and clients does direct reading. Maybe
> crazy idea but could we actually use dconf for this? we could have
> /org/folkd/<individual uid> keys of type "as" which is a list of persona uid.
> I'm not sure how dconf will scale if we have thousands of such keys?

We already get all of this for free from folks’ persona stores (either
EDS or the key-file backend). That’s one of the reasons why they’re used
for storing linking data.

Another reason they’re used for storing linking data is that adding the
linking data generally improves the quality of the user’s address book.
For example, linking a Jabber contact to an EDS contact should result in
the JID being added to the EDS contact’s list of JIDs. (I haven’t tested
this recently, but that’s what the code’s meant to do.) This is
unobtrusive and doesn’t mess up other EDS clients.

> I think merge/unmerge operations are not something we do daily, so it's not the
> most important operation to optimize.

Agreed.

> Questions?
> ==========
> I hope my suggestions makes sense. Of course I could be terribly wrong about
> some stuff, so please tell me your opinion :-)

Massive warning: the individual aggregator code is horrible, and has
many irritating corner cases — but it works well at the moment (albeit
slowly). If you want to rearchitect folks and make it all wonderful, I
would strongly suggest you write a thorough set of unit tests for the
aggregator first, or we *will* end up with regressions. Folks has a
reputation for being unstable which I really don’t want perpetuated.

Philip
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 230 bytes
Desc: This is a digitally signed message part
URL: <http://lists.freedesktop.org/archives/telepathy/attachments/20121030/1445aa09/attachment-0001.pgp>