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

Matthew Miller linuxwolf at outer-planes.net
Fri Jul 20 17:07:15 UTC 2012


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On Jul 20, 2012, at 00:45, Mark Rejhon wrote:

> 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)
> 

I still don't understand your resistance to disco, and the argument "the software is buggy!" is specious at best.

However, I'm willing to reserve full judgement until I read through the updated versions.


> 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
>> 


- - m&m

Matthew A. Miller
<http://goo.gl/LK55L>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org

iQEcBAEBAgAGBQJQCZBEAAoJEJq6Ou0cgrSPlOAH/0AYTzsBCZIG0U5sdyCUMFJb
DDkbUES5jQS8rthvNgRGv5J4skD5gSsWT+FVg6sWYPnnfMkfu6PaZ5zDZ+CJ+/Hu
Y8zNO2F3f40aifUNfOBpGEVAc00O0NKQrStjbhguGSByudPhmcY9IMrrdYHEWGng
qCEMJxtcB8t/x+Z5C/1BHfXG6N6ZN8fbEKgFUsBdopLuYztAVWGLIVD40cWPPoGH
du6YxyPEWQZa/OvZKEUse7H8lIT3DBib/yNLPMcP+jE2gLwJLTebxmsQkzhhPC4s
Q4oakTk9RSp2h5LyzDPo7Qf7ASsuuxuhIX9GGrlr1NDwjqj/vkeVFKWe6+KwFRQ=
=oR6m
-----END PGP SIGNATURE-----



More information about the Standards mailing list