[Telepathy] Folks status, the addressbook problem

[Xavier Claessens]

Le mardi 30 octobre 2012 à 16:51 +0000, Philip Withnall a écrit :
> > 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.

Ah right, it can still be a keyfile, right?

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

Right, but only if you search contacts. tbh gnome-contacts made itself
useless, I still have to battle with their designers... But good point,
so that works well :-)

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

Yep, it's just about moving stuff to the level where I think it could
makes more sense.

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

Having to manually merge hundred of contacts is a bug in itself,
heuristics should suggest you almost all the merging.

For this thing to be useful you have to 1) have google contacts 2)
understand what gnome-shell asks you (which I didn't myself) and have
your google account configured before starting gnome-contacts. 3)
probably pray for addressbook sync to work in EDS.

tbh, I think this only helped a few folks devs, but is useless to the
rest of the world... And it comes with a huge price...


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

Really? Telepathy backend certainly can load a single TpContact. EDS
backend can load a single EContact as well with
e_book_client_get_contact(), or does it internally load the whole thing?

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

indeed it is really complex, and that's what motivated me to rethink how
it's done. I hope that my suggestions would make it simpler (I rekon
it's always how it looks like on paper, then implementation makes it
much more complex). Also working well is useless if it cannot be used in
any serious way because it's way too slow.

Regards,
Xavier Claessens.