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