On Thu, 2012-11-08 at 10:17 +0100, Patrick Ohly wrote: > On Tue, 2012-11-06 at 11:44 -0800, Travis Reitter wrote: > > On Tue, 2012-11-06 at 20:35 +0100, Patrick Ohly wrote: > > > > > > I would encourage not re-using an ID during a single session, if > > > > possible. Telepathy makes this unlikely by incrementing contact handles > > > > indefinitely until they overflow the storage type (which would pretty > > > > much never happen in a single session, so it shouldn't be an issue). > > > > > > My preliminary implementation just exports the FolksIndividual id. That > > > avoids another layer of indirection inside the server. Does that ensure > > > that IDs are not getting reused during a session? The folks > > > documentation doesn't specify that. > > > > See the documentation for Folks.Individual.id for more details, but the > > summary for this case is that it's a deterministic hash based upon what > > we interpret as the most important Persona attached to that Individual. > > How is that determined when automatically linking two Persona that are > both in an EDS local address book?
That falls down to our 4th sorting order: alphanumerically by the Persona's UID (effectively their EContact UID). So, it's really not an order the user can predict, but we've already fallen through 3 levels of identical criteria at that point. I don't think EContact UIDs are stable chronologically, so that could explain some instability in those Individual IDs when extra EDS address books are added or removed. That might make it worth updating our heuristic for generating the Individual ID, but we'd need some solid logic to avoid changing it again in the near future. What criteria would make one EDS contact universally more interesting than another? > I've seen some unexpected "individual removed" + "individual added" > instead of "individual modified" when enabling/disable address books. I > did not pay attention to the Individual ID in that case, but perhaps the > Individual had to be recreated with a different ID (instead of being > modified) because the "most important Persona" changed - does that sound > likely? It certainly seems possible based on the code, described above. > > So, in a single session, if you add a Persona (and they get their own > > Individual), then remove that Persona, and re-add it later, that > > Individual will have the same ID both times. > > > > The case where an Individual id would be re-used for a different > > combination of Personas is if lower-"priority" Personas also attached to > > an Individual get added or removed. But, in this case, the Individual > > should almost certainly represent the same actual person regardless of > > minor changes in the Persona list. So any application re-using the ID > > should essentially be referring to the same person (which should be > > acceptable). > > In the PIM manager API I'd like to reserve the freedom to use IDs which > don't promise stability across sessions or remove/add, so I'd rather not > document this aspect of the IDs, at least not yet. Seems reasonable. Regards, -Travis
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ SyncEvolution mailing list [email protected] http://lists.syncevolution.org/listinfo/syncevolution
