[Telepathy] The Renaming interface and its interaction with channel-specific handles

[Simon McVittie]

While finishing off telepathy-glib I ran across an interesting issue in
the API - the existence of the Renaming interface. Various bits of
telepathy-glib expose handles as structure members, so we need to define
what will happen to those handles when Renaming is invoked. As a result
I've been reviewing the Renaming spec and came across a number of
issues.

The main issue is that as implemented in Idle, if a client doesn't
listen for the Renamed signal, it loses. In particular, no
MembersChanged is emitted for group channels when a member renames
themselves, and there is no signal that could indicate that the
self-handle, or the associated handle of a "directed" channel, has
changed. I think the Renaming interface is a fairly core one, since changing
your unique identifier is a fairly fundamental action, so this is
perhaps reasonable; I suggest we add some text to the spec explaining
that support for Renaming is strongly recommended, though.

It's also unclear how Renaming interacts with channel-specific handles.
This doesn't affect us at the moment, because our only CM with Renaming
is Idle (although thinking about it, perhaps SIP should support it as a
stronger form of call forwarding?), which doesn't have channel-specific
handles. However, we should introduce more renaming support soonish to
support MUC rooms properly.

So, issues:

* I'll explain in the spec how the Renamed signal does not emit any
  MembersChanged or anything like that - clients are expected to listen
  for Renamed and update their internal state without needing any
  further prompting

* If handles were held with HoldHandles, should the "hold" be
  transferred to the new name after a rename? My thought is "no" (this matches
  Idle behaviour), but "yes" would be consistent with everything
  higher-level.

* Do we assert that channel-specific handles are in a distinct namespace
  from global handles, as they are on XMPP? For instance in XMPP, if
  room at conference.jabber.org/Fred is a channel-specific handle,
  then room at conference.jabber.org/Fred cannot also be a global handle
  (if only because we'd normalize to room at conference.jabber.org).
  However, I could imagine a hypothetical protocol where global handles
  were short nicks (as in IRC) but on joining a room, you can choose a
  different short nick. (Pathological example: on battle.net you have a
  short global account name, and when you join a game of Diablo or something,
  your character in the game has a different short name.) Would we
  always avoid this clash by adding some sort of namespace (like the room
  name) to the room-local name?

* If the user themselves is in a group channel with channel-specific
  handles (think: a MUC), do they rename themselves by calling a new
  RequestRename method on the group, or by setting a well-known property
  'nick' or something?

* If someone in a group channel with channel-specific handles renames
  themselves, do we signal this by the global Renamed signal, or by
  a new Renamed signal on the channel itself? If we insist that
  channel-specific handles are globally unique by applying some sort of
  namespacing, then we can use the global Renamed signal without
  ambiguity.

My suggestions are:

1. Do not transfer the "held by client" state of a handle across renames -
  the client is expected to hold the new handle and release the old one
  (if necessary) while it's updating its internal state.

2. Insist that channel-specific handles are namespaced somehow (if not in
  the protocol then in the CM), so given any string, if it is a global
  handle then it is not a channel-specific handle, and if it is a
  channel-specific handle in a channel A then it is not a
  channel-specific handle in any other channel B != A.

3. Define a well-known property name "nick" or "identifier" or "self" or
  something, to be applied to MUCs and the like. Its semantics should be
  that it can only be writeable if the MUC has Channel_Specific_Handles
  (to avoid accidental global renames!) and that when set, the CM is
  allowed to mangle the name (e.g. to transform Fred to
  room at conference.jabber.org/Fred).

4. Use the global Renamed signal to signal renames, even if they involve
  channel-specific handles, because by (2.) that's unambiguous.

All of these should be written up in the spec - I'll sort out some
reasonable wording now and send it as a follow up.

Comments please (tell me if I'm on crack),
	Simon
-- 
Simon McVittie, Collabora Ltd.: http://www.collabora.co.uk/