On Wed, Aug 22, 2012 at 4:40 PM, Gregg Vanderheiden <[email protected]> wrote: > I suggest we keep it simple. > anytime the mode is switched the equivalent of "an ellipsis and SEND" is sent. > - for real time text switched to message: the text will have already been > sent up to the switch, so terminating that string with and ellipse and > send... and then sending the rest as a following message would seem logical.
Ellipsis is an idea, but that's a presentation related-behaviour, and thus should not be included in the spec, and the ellipsis isn't transmitted in the RTT channel (and shouldn't be for obvious reasons) but rather a client can decide to handle messages (save them, clear them, highlight them, show a temporary ellipsis, etc), and this is a close cousin to the sectsion "Stale Messages" http://xmpp.org/extensions/xep-0301.html#stale_messages There are many user-friendly ways to highlight an incomplete real-time message. I don't want to consider the message as sent, because the sender might resume composing, then turn back on real-time text later, or actually click Send. > - for message switched to real-time text: the message up to that point would > simply be transmitted as real-time text and the person would then continue in > real time. Yep. The event=new or event=reset can be used either way for this purpose. Technically, it is also possible for a sender to turn on real time text on/off many times while in the middle of composing a message. There may be use cases for "advanced clients", e.g. turning off real-time text before pasting private information that needs to be edited, then turning on real-time text when finishing editing private information. XEP-0301 is designed to gracefully allow sender clients to quickly refresh the entire contents of the real-time messages on recipients in all conceivable situations (whether connecting/joining/switching clients/etc after sender started composing, or even simply turning on real-time text while still composing mid-message) Because real-time text can be turned on/off multiple times while in middle of composing a message, a message is NOT considered "sent in full" (from a XMPP-IM <body/> perspective) until the real <body/> is actually sent. However, recipients MAY decide to do presentation-related behaviours whenever real-time is turned off mid-message (e.g. receiving <rtt event='cancel'/> without receiving a <body/> first) ... including, of course, automatically displaying an artifical temporary ellipsis logo/graphic [...] .... at least until the message is resumed (<rtt> resumes) or until the sender finishes and sends the complete message (sends <body/> Thanks, Mark Rejhon
