> 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/>
Ah, I think we had different scenarios playing in our heads then. I was imagining just tagging all of the RTT updates with the <replace /> element referring to the original, complete message that was being changed. Like so: <message to="al...@wonderland.lit" from="b...@wonderland.lit" type="chat" id="102"> <body>First Lixne</body> </message> ... <message to="al...@wonderland.lit" from="b...@wonderland.lit" type="chat" id="106"> <rtt xmlns="urn:xmpp:rtt:0" seq="4" event="reset"><t>First Lixne</t></rtt> <replace id="102" xmlns='urn:xmpp:message-correct:0'/> </message> <!-- begins replacement editing RTT by including <replace /> --> <message to="al...@wonderland.lit" from="b...@wonderland.lit" type="chat" id="107"> <rtt xmlns="urn:xmpp:rtt:0" seq="5"><d p=8/></rtt> <replace id="102" xmlns='urn:xmpp:message-correct:0'/> </message> <!-- replacement editing continues --> <message to="al...@wonderland.lit" from="b...@wonderland.lit" type="chat" id="108"> <body>First Line</body> <replace id="102" xmlns='urn:xmpp:message-correct:0'/> </message> <!-- final replacement body for message 102 --> No changes in XEP-0301 behaviour or protocol; in fact, it plays out identically to your proposal, just with more overhead. The advantage is the increased explicitness that those RTT events are happening within the context of last message correction. It just would probably need an update in XEP-0308 to allow this to be compliant. (I would consider RTT events to be messaging content which satisfies the requirement for inclusion of <replace />, but it's borderline enough that it would need clarification in XEP-0308). Anyway, the above adds a lot of extra bytes in those cases where there are 1000 RTT updates during editing, so your proposed method would be preferable in that regard. > 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? I meant that XEP-0301 makes references to the use of those events in terms of real-time messages, which a message sent before RTT is enabled I would not think qualified under those terms. And, if RTT is enabled and immediately used to edit a message sent before RTT, then the current text mandates that an event="new" be sent instead of event="reset" (since it is the first <rtt /> element containing action elements). A very minor issue and I'm probably just confused by the particular scenario used in your example, but I just want to be sure there isn't an edge case complicating things. -- Lance
