[Telepathy] Folks status, the addressbook problem

[Simon McVittie]

On 30/10/12 14:40, Xavier Claessens wrote:
> So I suggest CM should store on disk the full roster

Maybe...

> 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)"?

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?

> 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.

> 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.)

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?

The fact that a contact can have more than one URI (e.g.
xmpp:NNNNNNNN at messenger.live.com is also
msnim:add?contact=alice at example.com) complicates matters, though.

On IRC - always the complicating case for identifiers - we could just
say "this protocol doesn't have permanent enough identifiers to publish
URIs or link contacts", or use e.g. irc:smcv at irc.oftc.net (complicating
factor: irc:smcv at irc.eu.oftc.net is equivalent, but without
Freenode-specific knowledge, you can't know that).

>  * 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.

> We need change notification when that DB is changed. Probably something like
> dconf where a daemon does the writing and clients does direct reading.

Perhaps.

> 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.

    S