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@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/telepathy
signature.asc
Description: This is a digitally signed message part
_______________________________________________ telepathy mailing list telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy