-----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 <marky...@gmail.com> wrote: > >> On Fri, Jul 20, 2012 at 2:16 AM, Gunnar Hellström < >> gunnar.hellst...@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-----
