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
I've seen some unexpected "individual removed" +
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
It certainly seems possible based on the code, described above.
> So, in a single session, if you add a Persona (and they get
> 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
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.