On Fri, Jul 20, 2012 at 1:07 PM, Matthew Miller <linuxw...@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 <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----- >
