Please just don't forget that chat is completely different text _editing_...
On Fri, Mar 25, 2011 at 16:42, Mark Rejhon <[email protected]> wrote: > 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 > -- Nicolas Vérité (Nÿco) mailto:[email protected] Jabber ID : xmpp:[email protected]
