It also operates in chat too. Back in 1992, I created the equivalent of Unix 'talk' that allowed cursor up/down, going back even to the beginning of the conversation.
The real time text standard also allows representation as either a traditional IM conversation, and splitscreen, so the same effect can be achieved. That said, all the concerns about not allowing deep retroactivity is valid, and that is why I leave it out. However, I did like the deep retroactive feature during conversations -- it was useful, and due to the cursor movement capability (which also exists in the real time text standard), it allows the remote person to backscroll too -- so was useful for showing me stuff I missed, too. Mark Rejhon On 3/25/11, Nicolas Vérité <[email protected]> wrote: > 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] > -- Sent from my mobile device
