[Telepathy] Folks status, the addressbook problem

[Xavier Claessens]

Le mardi 30 octobre 2012 à 15:43 +0000, Simon McVittie a écrit :
> On 30/10/12 14:40, Xavier Claessens wrote:
> > in a format/location defined in the spec.
> 
> I'm somewhat less happy about this: the natural way for a CM to store
> the contact list for its own use is either in whatever its native format
> is (for instance the roster XML for Gabble), or in a sqlite database or
> something.
> 
> I don't think we really want to lock-in "the roster is stored in
> (XML|sqlite3) format at *this* location" as part of the Telepathy API.
> Even with the proposed Avatars redesign for 1.0, we've been able to
> avoid locking-in the specific location: all we lock-in is that there are
> files *somewhere* containing the avatars, and files of the same name +
> ".mime" containing the MIME-type.
> 
> Straw-man alternative 1: access the cached roster via a D-Bus API on the
> Account, and have MC cache it (in a CM-neutral, MC-specific format,
> which means we don't have to duplicate the cache code in every CM).
> LastKnownRoster, defined as "the last known value that would have been
> returned by GetContactListAttributes([some set of interfaces], False)"?

I actually though about having the cache done by MC, it makes sense
indeed. An Account is already the place where we have persistent info
when offline. What motivated me to move it to CM is the hope it would be
shared with incremental roster, and XMPP vcard cache. But maybe that was
just premature generalization.

If we go with a GetContactListAttributes that works offline (either on
Protocol or Account object) tp-glib could share a lot of code with
TpContact. That sounds great, even if implementation could be tricky.

> Straw-man alternative 2: access the stored roster via a D-Bus API on the
> ConnectionManager or Protocol, keyed by... I don't know what, actually.
> NormalizedName is almost what we want, except for in protocols where
> identifiers are non-namespaced, where it's worse than useless.

> IRC, AIM, Skype are the usual examples of non-namespaced identifiers,
> but AIM and Skype are proprietary single-implementation protocols, and
> IRC doesn't have contact lists. Do we know of any protocol that has
> contact lists but has multiple, non-federated servers with overlapping
> sets of "unique" identifiers? Maybe SILC?

Doing on the Account solves this question, and the account is likely
what client will monitor to know if it's online or not.

> > Of course when folks read the disk DB, since account is offline, the DB
> > is immutable, so we don't need any fancy change notification.
> 
> So the change notification needed is limited to "account is now online,
> reload from there"? I do like that idea - particularly if this is API on
> the Account, which would mean you're naturally monitoring the Account
> anyway.

exactly.

> > This means we have to define persona and individual uid:
> > 
> >  * Persona uid: I suggest using N9 format:
> >    "telepathy://<account path>/<contact-id>",
> >    "eds://<ESource id>/<EContact id>".
> >    Or anything from which we can fetch a TpContact or EContact.
> 
> I remain opposed in principle to things that try to look like URIs but
> are neither IETF-registered nor universal :-P but I'm also (at least
> somewhat) pragmatic about them.
> 
> If we're going to encode (account, contact) tuples in a
> thing-that-looks-like-a-URI, because / appears in account paths but :
> cannot, I would recommend something more like:
>     telepathy:gabble/jabber/smcv_40example_2ecom:xavier%40example.com
> 
> (or possibly with the /org/freedesktop/Telepathy or /im/telepathy1 part
> included, or with some other punctuation.)

Yeah, URI-like, or whatever format contains all the info we need.
Actually on N9 we had a bad surprise when tracked suddenly forced that
uri-like to really respect uri draft... So if anything we have to
explicitly say it looks like URI just by coincidence :)

That uid format is folks implementation detail. In public it's just
opaque string.

> I wonder whether we actually need to encode the account, though. Would
> it be enough to publish the URI or URIs of each contact
> (xmpp:xavier at example.com) via our existing Conn.I.Addressing1, and
> identify personas by those?

What I want is to fetch a TpContact from that uid, without loading a
full AM and all account rosters to lookup. So if I have 
"telepathy:gabble/jabber/smcv_40example_2ecom:xavier%40example.com"
I can directly get a TpAccount for it, then do
tp_connection_dup_contact_by_id_async(). That means I had to prepare 1
TpAccount, 1 TpConnection and 1 TpContact, nothing else.

> >  * Individual uid: there are 2 cases, does it have just one Persona or more?
> >    - just one: use its persona uid.
> >    - more than one: use a uuid and keep it in the DB.
> 
> Does this mean that if I have you as an XMPP contact, and then I add you
> to my Evolution address book, your Individual ID changes from
> telepathy:blahblah to urn:uuid:foobar? I don't think that that's desirable.

Right... The thing is 2 apps must have the same id for the individual,
so if the id is not decided from a common DB it must be decided based on
the persona id. What about:

- When the individual has just one persona, it uses a hash of its
persona id (that's what folks currently does).
- When we merge other personas into that individual, instead of creating
a new uuid, we can just keep its current id and write it in the DB.

> > Maybe
> > crazy idea but could we actually use dconf for this?
> 
> I'm pretty sure this is not configuration and should not live in dconf.
> We could perhaps use gvdb (the "GVariant database" that is dconf's
> binary format), though.

Right, it's abusing dconf. I just don't want to reinvent a DB with a
daemon telling when things are changed. I don't know much about existing
DB solutions, so I'm not sure what's the best solution here. gvdb looks
good idea indeed.

Regards,
Xavier Claessens.