[Standards] review of XEP-0301, sections 1-5 (Advice needed on Peter's comments)

Gregg Vanderheiden gv at trace.wisc.edu
Wed Aug 22 21:27:55 UTC 2012


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 <markybox at gmail.com> wrote:

> On Wed, Aug 22, 2012 at 4:40 PM, Gregg Vanderheiden <gv at trace.wisc.edu> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20120822/6089c3c6/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 7318 bytes
Desc: not available
URL: <http://mail.jabber.org/pipermail/standards/attachments/20120822/6089c3c6/attachment.bin>


More information about the Standards mailing list