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? 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? > 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. -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. _______________________________________________ SyncEvolution mailing list [email protected] http://lists.syncevolution.org/listinfo/syncevolution
