Hello, On Tue, Apr 17, 2012 at 5:35 AM, Kevin Smith <[email protected]> wrote:
> 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. > I think it would work fine that way, although in clients not "aware of combining XEP-0301 and XEP-0308", the RTT message would be a duplicate of the message above it, which might confuse some users. But it would work. There, however, is an interest to make sure that clients know *which* line the <rtt> edits, so that software vendors can decide to do so. I think it's about 3 or 4 years too early to have a serious spec about this, but: One method of last message correction being built into XEP-0301 is to use an 'id' parameter in <rtt> elements, so I could have "X-line" retroactive editing, like being able to edit the last 10 lines of text. (Some additional disco parameter could be use to define X lines). For clients that don't have history, <rtt event='reset' id='oldmsgnumber'/> could be used as a message history downloading technique, i.e. to redownload the last 10 messages. Everytime a cursor moved to a line and the line was begun to be edited, a new <rtt> 'event' would be used. I feel that the ability to add a line 'id' to <rtt> gives XEP-0301 potential as a retroactive editor that is richer than XEP-0308, but it would be of interest to "keep the door open" because XEP-0301 is a potential spec used for live transcriptions, real-time captioning, court reporting (my spouse was a court reporter), etc, as there are times that major errors in captions needs to be retroactively edited within 30 seconds, etc. (Note: Good clients with retroactive editing can decide to color retroactive edits in a different color-code, to indicate a successful edit) -- Then again, the question comes up, as to whether XEP-0301 is appropriate as a retroactive editing spec (if extended with a line 'id' parameter, and using a variant of event='reset' to redownload lines of messages, especially in client-switching situations) ... I intentionally designed XEP-0301 to be theoretically compatible with private extensions that allow XEP-0301 to behave as a basic text editor or an X-line retroactive editor, although that's probably overkill. > 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. > Possibly, but some co-operation is necessary, because I sort of intentionally designed XEP-0301 to *theoretically* behave as a multiline text editor in the future (keeping the court reporting workflow door open, due to my spouse), and that scope overlaps with XEP-0308. Thanks Mark Rejhon
