[Telepathy] Folks status, the addressbook problem

[Philip Withnall]

On Tue, 2012-10-30 at 18:21 +0100, Xavier Claessens wrote:
> 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?

The linking information will be stored in whichever persona store is the
primary persona store. This is typically an EDS address book, but could
be a folks key file.

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

Even if the heuristics were 90% accurate, there would still be a number
of personas which the user would end up manually linking; and they would
have to do that on every device.

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

 1. It should work with any kind of web-synchronised address book (e.g.
WebDAV), not just Google Contacts.
 2. UI problem.
 3. Bugs, which can always be fixed.

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

You’re right. Telepathy can load a single contact. EDS can load a single
contact, but some of its backends don’t implement that. The vCard file
backend can load a single contact; but the Google backend loads the
entire contact list first then selects the requested contact.

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

My point is that I think time would be better spent optimising the
existing architecture, rather than rearchitecting it. The current
implementation of the aggregator was not designed to be speedy (it was
designed to be correct), and as far as I remember, no significant
optimisation work has gone into it. Simply coming up with a better set
of data structures for storing the link map would probably speed things
up. I’d suggest taking a look at the algorithmic complexity of some of
the operations in the aggregator (such as what Jeremy was doing) and
seeing if there is some low hanging fruit there.

Philip

> Regards,
> Xavier Claessens.
> 
> _______________________________________________
> telepathy mailing list
> telepathy at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/telepathy

-------------- 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/20121031/6bb9b9c3/attachment.pgp>