[Standards] NEW: XEP-0308 (Last Message Correction)- Interop with XEP 0301 RTT

Mark Rejhon markybox at gmail.com
Fri Jul 20 06:34:19 UTC 2012


On Fri, Jul 20, 2012 at 2:16 AM, Gunnar Hellström <
gunnar.hellstrom at omnitor.se> wrote:

>  Your current sentence is:
>
> "to have improved presentation of real-time text during message correction"
>
> Without the added feature of real-time edit, there is no presentation of real-time text during message correction. There will be a freeze and wait until the edit is done and sent as an XEP-0308 replace. So there is nothing there that can be enhanced or improved. Real-time text presentation during correction is introduced by the feature.
> therefore my proposal is still:
>
> "to have presentation of real-time text during message correction"
>
> No -- Not necessarily.
It's still possible for software to support XEP-0301 and XEP-0308, and
still be able to do real-time text during retroactive, without supporting
the 'id' attribute.  The behavior is just slightly different.
I am re-quoting the behavior written in an earlier message.

*Backwards compatible behavior (End User Viewpoint)*
The retroactive real-time edit will temporarily appear as if it was a brand
new message.   Basically, the real-time message will be a *copy* of the old
message, while the retroactive edit is taking place.   When the edit is
finished, the real-time message disappears and the edit shows up above in
the last message.

*Backwards compatible behavior (Developer viewpoint)*
Technical reasoning in 0301+0308 clients that don't do 0301 retroactive:
Why this works 100% backwards compatible is due to section 4.2.2 and
section 4.3 of XEP-0301.   For retroactive RTT, to remain backwards
compatibility, I would always require event='reset' everytime you begin to
reference a retroactive edit.  Clients are REQUIRED to follow the
event='reset' behavior described in XEP-0301 section 4.2.2 ....
http://xmpp.org/extensions/xep-0301.html#event
The client doesn't know it's a retroactive edit (it ignores the id
attribute), so the real-time message temporarily shows up as a new message
-- a *copy* of the previous line.   It's as if the user copy and pasted the
previous line, and began editing.  When the retroactive edit begins, the
end user see a copy of the previous message, because the software thinks
it's a new real-time message being started.   (event='reset' is treated as
event='new' thanks to the current version 0.3 wording of section 4.2.2)
 ... Now, when the retroactive edit is finished, the <body/> gets
delivered, which forces the real-time message to be cleared. (Section 4.3
says so)
http://xmpp.org/extensions/xep-0301.html#body_element
Thus, the real-time message disappears when the edit is finished,
simultaneously with the previous message being replaced by this.  To the
user, it looks like the edit suddenly moves upwards to the previous line.

The "enhanced" user experience would occur, when the software decides to
interpret the 'id' attribute.
The developer has several legitimate choices:
-- don't show RTT during retroactive (your scenario but it is not the only
possible one)
-- support RTT for retroactive (without id, or ignore id) and tolerate the
'acceptable' behavior described above,
-- support RTT for retroactive (with id) for enhanced UI behaviour.

But, observing that I have had to explain this scenario several times, is
slowly convincing me to add an example for XEP-0308.  I shall, however,
wait, till v0.5 or v0.6, since I want feedback from Kevin/Peter sooner than
later, and I want to refocus my work on XEP-0301 for the BEEM-Android demo
for the August 20th Access Board stuff (the more LAST CALL is delayed, the
less we'll have to show for Access Board).  Also I already added more
examples (Which you haven't seen yet).

Thanks
Mark Rejhon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20120720/b4b45113/attachment.html>


More information about the Standards mailing list