On Tue, Jul 17, 2012 at 6:24 PM, Lance Stout <[email protected]> wrote:
> Yeah, my first thought was "why not just allow adding a <replace /> in > each RTT update?" but that can add a lot of overhead, even though it makes > the intent very explicit. > Imagine situations where the original message took 2 seconds to create (Enter was accidentally hit), but last message editing take minutes. How do you replace 2 or 3 <rtt/> elements in a proper manner, with over 100 to 1000 <rtt/> elements, while preserving all behaviour of XEP-0301? You could transmit 1000 action elements in a single <rtt/>, but that becomes quite unwieldly, especially, if you continue, and then go back to edit some more. So for this reason, I feel that <rtt/> doesn't belong in <replace/> I think the inclusion of the id attribute with event="reset" has strong > enough semantics to make this work. You're resetting a previous message for > amendment via RTT, and the final <replace /> gives the result of editing. > Yes, and it's backwards compatible -- clients that ignore 'id' of <rtt/> would still display the real-time text usably in its usual location, even if not "in-place" I can see already that the description of the reset event will need to be > updated to cover the new semantics. For example, the current XEP-0301 text > does not sound like this method would be acceptable if one attempted to > replace a message sent before RTT was enabled. > That wouldn't be a problem. This is because <rtt event='reset'/> is treated exactly like <rtt event='new'/> if there was no existing message. My version 0.3 update made that clearer. Can you clarify? Does this handle the case where a user begins a replacement, but then > decides to not commit to the replacement? Or is that simply not a case that > makes sense in a RTT session? > Then it is harmless. The message reset just essentially does nothing, when you move on back to the next real-time message (i.e. going back to current message). Thanks, Mark Rejhon
