In many IM protocols, user-defined contact groups are identified only by a human-readable name. However, this is not universal, one case to the contrary being XDM resource lists in SIP presence (RFC 4826). Each list (corresponding to a Telepathy contact group) under the <resource-lists/> root is identified by a unique handle, and may have a display name with no uniqueness requirements. A Telepathy connection manager cannot generally represent such a list collection as contact groups using display names for handles. Hence the proposal is to allow HANDLE_TYPE_GROUP handle IDs be opaque, and assign display names to the handles using Aliases or other similar API.
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 :-)
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.