On Tue, Nov 3, 2015 at 9:02 PM, Christian Vogler < [email protected]> wrote:
> 2. No problems whatsoever - in fact, the spec was remarkably easy to > implement overall. [...] > Thanks for the compliments! On Tue, Nov 3, 2015 at 9:02 PM, Christian Vogler < [email protected]> wrote: > a. I don't see the use case for tracking RTT state by full JID. It seems > to me that in most situations, tracking by bare JID would result in the > most consistent and best user experience. This could perhaps be made > clearer. > I should stress doing by full JID is OPTIONAL. Conversely there have been people in the past who say bare JID makes no sense. Different people have argued in both directions in the last 4 years. Some example use cases: -- Tracking by full JID can allow RTT message switching to be faster during device-switching situations. By tracking by bare JID, you have to wait for the next Message Refresh before the RTT message "switches over" to active typist. But by keeping track by full JID, synchronization of all Simultaneous Logins is maintained, you can control the timing of the switchover (and even animate it, such as fade-in, or poof-reappear animation, etc) independently of the timing of Message Refresh events. With full JID tracking, the implementer of the recipient has more timing control over which RTT message to display during a device-switch situation. Tracking multiple RTT messages doesn't necessarily have to mean displaying all of them at once. -- Tracking by full JID can work well in clients that choose to implement a MUC-style user interface. Clients can choose to display all of the RTT messages simultaneously. The full JID would have separate real time messages during simultaneous logins with different typists. (e.g. husband and a wife logging in on two devices using same ID in the same IRC-style channel). Simultaneous Logins often work anyway with IRC-style chatting, and I didn't want to make it impossible for an implementer to map RTT seamlessly into that, if they wished. It's an implementer's choice how to design the user interface. The protocol just simply makes it possible. > b. RTT init and RTT cancel look like a lot of extra work to implement, and > since XEP-0301 is fully compatible with turn-based messaging, there is no > apparent usability benefit. The only benefit seems to be to cut down on > network bandwidth, by not transmitting RTT if the remote side is not > interested in displaying RTT. Is this worth the price of a more complicated > spec? > I understand that view. That's why we all made it OPTIONAL. However, some counterpoints: -- For UX in some implementatiuons, it is important that the sender knows that the recipient is no longer seeing their real time text. -- When you end audio/video as a recipient, the sender knows you ended audio/video. The 'init' and 'cancel' makes it possible that RTT can be the same start/stop experience that audio and video is. -- It also keeps a consistent Total Conversation experience (audio/video/realtimetext). This is an implementor's decision. -- Some clients (talky.io) are video with real time text captions on them. -- Other clients are traditional message-by-message like most XMPP chats. Others provide an IRC-style UI. -- Yet other clients are splitscreen chat (like UNIX talk, old-fashioned ICQ chat). RTT init/cancel makes various user interface experiences (UX) possible that would otherwise not be, for situations where an implementer needs them. These are necessary inclusions as an OPTIONAL feature as these are of interest to other implementers. In this case, again, it is an implementer's choice how to design the user interface: The protocol just simply makes it possible. Thanks, Mark Rejhon
