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

Mark Rejhon markybox at gmail.com
Tue Jul 17 23:08:43 UTC 2012


On Tue, Jul 17, 2012 at 6:24 PM, Lance Stout <lancestout at gmail.com> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20120717/0006b00b/attachment.html>


More information about the Standards mailing list