| Summary: | Using handle to represent temporary contacts valid during session | ||
|---|---|---|---|
| Product: | Telepathy | Reporter: | Pekka Pessi <ppessi+telepathy> |
| Component: | tp-spec | Assignee: | Telepathy bugs list <telepathy-bugs> |
| Status: | RESOLVED MOVED | QA Contact: | Telepathy bugs list <telepathy-bugs> |
| Severity: | normal | ||
| Priority: | medium | ||
| Version: | unspecified | ||
| Hardware: | Other | ||
| OS: | All | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
|
Description
Pekka Pessi
2008-04-17 03:40:55 UTC
I think there's a synergy to be exploited with XMPP resource IDs as well. What if we have a generic interface where it's possible to retrieve zero or more "UA handles" associated with the regular "address handle". Then, some use cases can make use of the UA handles for precise addressing. There might be also a notion of the default UA handle per address handle, selectable by the client, while addressing should still be limited to address handles to hide implementation differences. I think it can also solve part of the problem with aliasing in SIP text channels implemented with MESSAGE requests (however, if cross-request Call-ID is not maintained, we have no means to track the aliases). This seems quite subtle, and not something we want to rush into! When the "improved RequestChannel API" has landed, we'd like to be able to support XMPP thread IDs, which I think have similar use cases. I'd somewhat prefer to represent related conversations/messages/channels as "part of the same thread" rather than having some sort of "sub-contact" concept. So, instead of sending a MESSAGE to the channel-specific-handle for "Pekka as he appears in this particular call", it might be better if the UI opened a text channel that was somehow marked as related to the call, or had the same thread UUID as the call, or something; then the connection manager could deal with the nasty behind-the-scenes stuff in whatever way it thinks best. Perhaps this would imply that the text channel stopped working when the call closed; that's fine, it was "related" anyway. Channel-specific handles are a necessary evil in XMPP because it's possible to have contacts in a multi-user chat whose identity outside the MUC is not visible. I'd rather avoid polluting other implementations with CSHs if we can help it - they're a real pain to deal with! In XMPP it is in fact possible to have a private conversation with a contact in a MUC whose identity you don't know - in Gabble you open a text channel to their channel-specific handle, which will stop working if you or they leave the MUC. So technically the SIP session/dialog semantics would map closest to Telepathy if the Remote handle in StreamedMedia channel get always converted to a channel-specific handle? While the session is active,the channel-specific handle could be used to set up a text channel. That is an solution, but if you don't like channel-specific handles, perhaps there should be another interface for providing session-specific handle only when needed? -- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/telepathy/telepathy-spec/issues/9. |
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.