On Wed, Jun 27, 2012 at 12:14 PM, Kurt Zeilenga <[email protected]>wrote:
> Can you provide (on list and in the XEP) an example of the RTT exchange > when a user who begins to compose a message decides not to send that > message (or any message) to the recipient, such as if they close the window > in the U/I during composition of a message? If I missed such in the XEP, > please point it out to me. > Specification issue: -- Sender software that closes windows, should send <rtt event='cancel'/> (section 4.2.2) so recipient software knows that the message is now stale. What is done next is a user interface issue, rather than protocol issue. User interface issue: UI issues are not in the spec, but generally, there are some suggestions: -- Recipient software that have blank real time text (i.e. sender changed mind and backspaced the message), can simply decide to hide the real time text buffer automatically when the real time text is blank. -- Recipient software can use Chat States to decide whether or not to show/hide the real time text. -- Software can time-out orphaned real time messages (hide them) if they're still up for prolonged periods. (i.e. other end crashed or lost reception permanently)... My spec isn't responsible for defining what is done with them, it's a user interface issue at this stage. They could be hidden after a time period. -- Temporarily hidden real time text can be re-shown, for example, by mouseovering the word "Typing..." -- There are lots of creative UI ideas to reduce RTT clutter, especially in the chaotic environment of a MUC (i.e. only show the most active RTT or two, and auto-hide the real time text of slower and idle typers until they "send" the fully composed message or resume typing fast) .... Some of the information was also written in the now-outdated RTT Supplements document at http://www.realjabber.org/XMPP-RTT-Supplement_2011-06-17.pdf -- Even when RTT messages are hidden, recipient software need to continue keeping internal track of the current state of the real time message each sender in an open window. However, this is not always critical, since message reset events should occur regularly (thus, it's safe for senders to resume typing a partially-typed message even hours later). Section 4.6.4 recommending message resets every 10 seconds during active typing, covers this concern already. (so RTT can even safely auto-resume hours later if the recipient has lost the original RTT a long time ago) Your question is a good question -- and probably a future FAQ item -- I plan to have a FAQ on realjabber.org and this is one good candidate question to be answered, because there are huge numbers of legitimate ways how a user interface can decide to handle a stale real time text message, that don't belong in a specification document. Bottom line; perhaps we need to add a small paragraph to the Implementation Notes for general guidelines. Opinions? ...Especially generic/generalized note about handling two most common scenarios (closing a chat / changing mind about message), in order to mention the use of <rtt event='cancel'/> during closing of a chat window. Maybe a short <rtt event='cancel'/> example. And only to briefly mention the concept of "stale messages" -- a user interface responsibility -- and that an implementor may need to deal with stale messages that stay static for a long time. -- i.e. battery dies in the middle of composing a message, wireless reception gets lost for prolonged period, etc.) Just one or two generalized sentences? Thanks, Mark Rejhon
