2011/3/25 Mark Rejhon <[email protected]>: > 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
Having experienced chat clients with editing features, I can oppose two clearly different behaviours: 1/ only one edit, only last message: ** no cheat, users feel safe with other's chat messages ** you know what you can do or not, and learn to live with 2/ infinite edits, all messages: ** you just restrict yourself, because you deeply know it's wrong to edit everything every time ** users do not trust the client, nor the contact ** lots of unwanted side-effects in histories and logs ** uncompatible clients suffer ** etc. If it does not appear as mandatory in the XEP, it needs at least to be strongly adviced. > 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 > -- Nicolas Vérité (Nÿco) mailto:[email protected] Jabber ID : xmpp:[email protected]
