Hello, I am authoring the Real Time Text, along with members of realtimetext.org (Gunnar, etc). The old draft is at http://www.realjabber.org/realtimemtext.html ... but is currently being rewritten and simplified for 0.02 resubmission.
I have a private extension to my real time text standard that allows unlimited retroactive editing via indexing the message line via a "msg" parameter. It would have been useful for: - critical writing where deep-retroactive edits are desirable. - Real time transcription of court reporting - Real time captioning workflows where a caption editor works at the same time as a transcriber on adjacent computers. - it is MUC compatible (although not supported by my 0.02 spec except as a private extension) for one-to-many transmission, like to multiple audience members or several TV stations, that needs a hook into the feed. They can reject or accept edits before X lines automatically, as needed... Logging would have been done by: - Retransmitting any changed lines in a body element, everytime Enter is hit, or cursor arrow up/down goes out of bounds of the current line (cursor moves to adjacent line) Edits prievious to the current line can be automatically color-coded and highlighted automatically, to make it much harder to miss edits. My real time text standard also includes support for cursor position transmissions (which can be optionally rendered for a visible cursor) which makes it even easier to watch somebody make an edit. The retroactive editing feature is not an official part of my real time text standard as I had decided to leave it out, but to allow it to be added on as a private extension, if needed. Please be noted all of this is being left out of 0.02 of my real time text standard for simplicity. However, it would be worth some thought how your retroactive edit standard, may help (or interfere) with my technique of retroactive editing, and to make sure that our standards are compatible. Thanks! Mark Rejhon (Authoring the XMPP Real Time Text Standard) On 3/25/11, Remko Tronçon <[email protected]> wrote: >> Only the latest message seems overly restrictive (especially if the last >> message you send it "oops"). I'd say a buffer of, say, the last 5 >> messages might be appropriate. > > For the same reason, I think that only one edit is overly restrictive. > I have needed several edits to get a one-sentence IM message right :-) > > I don't see a reason to put in arbitrary restrictions in the protocol > (different use cases can warrant different limits); i wouldn't mind > recommendations, though. > > As long as the client indicates that a message has been edited X times > (and provides the original message), i don't really see any issues. > > cheers, > Remko > -- Sent from my mobile device
