Bug 13419

It might also be worthy to consider extending other interfaces similarly. One such example is the Renaming interface - one can rename contact groups in many interfaces, and I can imagine that some protocol might allow renaming chat rooms as well. Note that this is in contrast with the Aliasing interface, which just deals with display names and such instead of the underlying unique IDs.

(In reply to comment #1)
> It might also be worthy to consider extending other interfaces similarly. One
> such example is the Renaming interface - one can rename contact groups in many
> interfaces,

in many PROTOCOLS, obviously.

The current proposal for a better (channel-free) ContactList API is Bug #21787. One earlier draft had opaque object paths for groups, but the current proposal just has an array of strings (display names) as a contact-attribute on each contact.

Does it really make sense to have groups with the same name, though? How would a UI present them in any sane way? I don't like the look of:

    Mikhail Zabaluev    |------|
                        |  o   |
    [x] Telepathy       | /|\  |
    [ ] Collisions      |------|
    [x] Collisions
    [ ] Cambridge

I wonder whether if a CM for a protocol where visible names can collide sees groups (ABC, "Collisions"), and (XYZ, "Collisions"), it should present ABC as "Collisions (1)" and XYZ as "Collisions (2)", or something?

It seems to me that that doesn't negatively affect... well, anything I can think of, really.

(In reply to comment #1)
> It might also be worthy to consider extending other interfaces similarly. One
> such example is the Renaming interface - one can rename contact groups in many
> interfaces, and I can imagine that some protocol might allow renaming chat
> rooms as well. Note that this is in contrast with the Aliasing interface, which
> just deals with display names and such instead of the underlying unique IDs.

Renaming a group isn't the same as renaming a contact, so I think it's out of scope for Renaming, but the API proposed in Bug #21787 does cover renaming groups.

(In reply to comment #3)
> I wonder whether if a CM for a protocol where visible names can collide sees
> groups (ABC, "Collisions"), and (XYZ, "Collisions"), it should present ABC as
> "Collisions (1)" and XYZ as "Collisions (2)", or something?

I agree the complexity is not really useful, and nobody really cares about XDM anyway :)
This leaves the question of what should a CM for such a protocol do when it's told to create a group. But as the group ID syntax would be opaque to the client, it cannot be expected to come up with usable IDs, meaning the CM needs to have the discretion to synthesize one out of available information.
I'm retracting this request on considerations provided. Thank you.

Excellent, I can stop caring about this when designing Bug #21787. Thank you for your feedback :-)