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

Mark Rejhon markybox at gmail.com
Fri Jul 20 17:14:28 UTC 2012


On Fri, Jul 20, 2012 at 1:07 PM, Matthew Miller
<linuxwolf at outer-planes.net>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.
>

No, no -- this one is different, evaluated from a different perspective.
This is a completely different matter from the "fallback method", as this
list simply illustrates optimization to the protocol for maximum
compatibility between a variety of combinations of XEP-0301 and XEP-0301 --
it is not something any of my implementations ever plans to do.    (the
fallback method is for a completely different reason).

Let's get back on the topic.   If there's disco debate, let's move it over
to the fallback method -- which is where I have my resistance.

Also, I honoured everyone's request to improve disco to include both
XEP-0030 and XEP-0115.


>
>
> > 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-----
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20120720/50cb3fc0/attachment.html>


More information about the Standards mailing list