Mild thread necromancy: 2011/11/11 Gunnar Hellström <[email protected]>: > Mark says: "2. Allow real time text (RTT) to occur with previous messages. > I would add an optional 'id' attribute to <rtt> elements. " > > I can imagine that the action will be something like this: > 1.The transmitting user positions the cursor to a point in the previous > message, and start adding, deleting or replacing some text. > 2.That should generate messages with <rtt> elements and <id> elements at 1 > second intervals as long as changes are made. > 3. When the change of the message is complete, the transmitting user client > sends the complete message with <body> and <replaces> with <id>. That > finalizes the change. > 4. Next character typed will cause an <rtt><new> element, with new <id> and > the display will be done to show that a new message is started after all > earlier.
That sounds largely reasonable to me. > Questions: > a. Would we need to retransmit the message up to the point of change in the > first <rtt> element to be sure that it can be displayed correctly, or can we > just start with the positioning or first modification within that message? I think that you can just start rtt-ing on the previous message without retransmitting it in advance, unless you care about the edge case where a user has switched clients very quickly and so doesn't have that message. I would think that case isn't work optimising for. > b. Can we keep the description about Last Message real-time correction by > <rtt> completely within XEP-0301, and let the implementor understand that > the modified message <body> after all <rtt> elements shall be sent with a > <replaces> and<id> element? Or do we need to mention XEP-0301 in XEP-0308 > and XEP-0308 in XEP-0301 and synchronize their approvals? It seems reasonable to me to keep this within 301. /K
