Ah good points so how about
1) changing from real-time text to messaging - would just result in the characters being stored up until the person sent send. At that point the accumulated text would be sent as a burst of real-time text and a send. The device would then continue in message mode. - If the person switched back to real-time text again (without sending a send) it would just send the accumulated text as a burst of real-time text and then continue in real-time. 2) changing from messaging to real-time text would simply result in the accumulated message being sent as a burst of real-time text. (same as above) Gregg -------------------------------------------------------- On Aug 22, 2012, at 3:52 PM, Mark Rejhon <[email protected]> wrote: > 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
smime.p7s
Description: S/MIME cryptographic signature
