GNOME Bugzilla – Bug 696215
add convenience API to get a Persona by its UID
Last modified: 2018-09-21 16:01:32 UTC
Individual.id's documentation says: * If an identifier is required which will be used for a long-lived link * between different stored data, it may be more desirable to use the * {@link Persona.uid} of the most relevant {@link Persona} in the Individual So, suppose I saved a uid in a file last time my application ran. Now I'm running it again and I want to get the Persona for that saved UID. According to comments in Persona, the UID might look like telepathy:jabber:foo@xmpp.example.org or key-file:relationships.ini:joe@example.org. Using Persona.split_uid() I can split it into its three colon-separated parts, and unescape them. So far so good. As far as I can tell, the first part is a backend ID, which I can resolve to a Backend with: var backend = BackendStore.dup ().dup_backend_by_name (part1) The second part is a persona store ID, which I can resolve to a PersonaStore with: var persona_store = backend.persona_stores[part2] (It might be less Gee-centric and more introspectable if there was a method "PersonaStore? Backend.dup_persona_store()" here.) ... but it stops there. The third part is a "Persona ID" which does not seem to be the same thing as a Persona.iid. PersonaStore.personas is keyed by Persona.iid, so unless I'm missing something, I can't look up a Persona by its "Persona ID", except via: foreach (var persona in persona_store.personas) { if (persona.id == part3) return persona; } which hardly seems optimal! In the e-d-s backend, the IID happens to be "eds:" + the third part of the Persona.uid (which, confusingly, is also called a UID in e-d-s jargon) but in the Telepathy backend it's the Telepathy protocol name (e.g. jabber) + ":" + the third part of the uid. Straw-man API proposal: any of these: /* takes the uid, throws away the first two components or perhaps * asserts/g_return_if_fails that they match it */ Persona? PersonaStore.dup_persona_by_uid (string uid); /* takes only the third component */ Persona? PersonaStore.dup_persona_by_id (string id); /* not necessarily very good: if null, you can't tell why you failed */ Persona? BackendStore.get_persona_by_uid (string uid); Persona? BackendStore.get_persona_by_uid (string uid, out Backend? backend, out PersonaStore? persona_store);
(In reply to comment #0) > ... but it stops there. The third part is a "Persona ID" which does not seem to > be the same thing as a Persona.iid. I’ve been labouring under the misconception that the two were the same for a while. This is very saddening, both for the API and for what it says about my memory. > Straw-man API proposal: any of these: > > /* takes the uid, throws away the first two components or perhaps > * asserts/g_return_if_fails that they match it */ > Persona? PersonaStore.dup_persona_by_uid (string uid); > > /* takes only the third component */ > Persona? PersonaStore.dup_persona_by_id (string id); > > /* not necessarily very good: if null, you can't tell why you failed */ > Persona? BackendStore.get_persona_by_uid (string uid); > > Persona? BackendStore.get_persona_by_uid (string uid, > out Backend? backend, out PersonaStore? persona_store); I’d be inclined to go with the fourth proposal, but calling it ‘look_up_persona()’ for symmetry with IndividualAggregator.look_up_individual(). I think we should be moving towards using UIDs for personas and deprecating IIDs (then we can drop the ‘_by_uid’ from the method name). The ‘persona IDs’ you mention above should be rebranded to be backend-specific (e.g. an EDS UID, or a Telepathy contact ID). So my API proposal (modified from 4 above): async Persona? BackendStore.look_up_persona (string uid, out Backend? backend = null, out PersonaStore? persona_store = null) throws GLib.Error; This is async and throws an error so that it can call BackendStore.load_backends() if necessary. (As IndividualAggregator.look_up_individual() does.)
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/folks/issues/57.