Note again - I'm leaving retroactivity out of the real time text standard. I'm just requesting to make sure that there is compatibility between standards...
-- Even if only editing the last line, there's some potential interplay/incompatibility that I (or you or we) might need to resolve. -- Even without retroactive editing, we might need to say our standards are incompatible with each other depending on what the group agrees on (ie, enabling real time text may disable the edit-last-line standard) -- Wild idea out of the blue: what about the idea of a different standard (third standard) called a message indexing standard, a method of referencing a specific historical line, that both your standard and possible future versions of my standard, can take advantage of? Probably not a pratical idea, but it might reduce future headaches. Retroactive editing is very useful for real-time-text, and it is in my interests to see compatibility. You can download my realjabber test software -- or email me to ask for a copy. (Has no retroactive editing, but may give you ideas of how to make our standards compatible) Mark Rejhon On 3/25/11, Mark Rejhon <[email protected]> wrote: > 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 > -- Sent from my mobile device
