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

Mark Rejhon markybox at gmail.com
Fri Jul 20 06:45:24 UTC 2012


About the agreed XEP-0308 and XEP-0301 compatibility:
I would like to amend the list of advantages that I sent earlier, due to
the improved retroactive editing protocol that is already agreed between
myself, Peter, Kevin, and Lance.  (Except potential disagreement about
whether to have a third separate 'disco' which I still think is unnecessary)

Advantages of the now-agreed 'id' attribute of <rtt/>

....It would still work in clients that didn't support either XEP-0301 or
XEP-0308
Result: The retroactive edit may appear as a separate message (third
message)
(If software persisted in trying to do this regardless of recommended disco)

....It would still work in clients that supported XEP-0301 retroactive but
didn't support XEP-0308
Result: The retroactive edit shows up as a new real time message, and then
transmitted as a separate message.
(If software persisted in trying to do this regardless of recommended disco)

....It would still work in clients that supported XEP-0308 retroactive but
didn't support XEP-0301
Result: The retroactive edit shows up only when the edit is finished (no
real time at all)

....It would still work in clients that supported XEP-0308 retroactive but
only supported XEP-0301 non-retroactive
*Result: Real-time text at all times, and real-time retroactive editing
occurs where the "new message" normally is.*

....It would still work in clients that supported both XEP-0301 retroactive
mode and XEP-0308
Result: Real-time text at all times, and real-time retroactive editing can
occur "in-place". (enhanced user experience)


Thanks,
Mark Rejhon

On Fri, Jul 20, 2012 at 2:34 AM, Mark Rejhon <markybox at gmail.com> wrote:

> 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/87fdb6e2/attachment.html>


More information about the Standards mailing list