Well -- As it stands now, reprogramming RealJabber to use event=reset only (for both new and reset), or use event=new only (for both new and reset), yields exactly identical behavior in RealJabber. Absolutely no UI difference, when starting a new message with event=reset, or refreshing a message in progress with event=new. There is a legitimate question of confusion: Why have both?
Does this mean event=new should be merged with event=reset? I'd just add a separate minor indicator (e.g. fourth attribute that is purely optional) for those implementers that want to make a distinction between new/reset in presentation purposes (e.g. green flash or similar, for the start of a new message) On 2012-08-20 11:10 AM, "Peter Saint-Andre" <[email protected]> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 8/20/12 2:15 AM, Mark Rejhon wrote: > > > > On 2012-08-20 3:32 AM, "Gunnar Hellström" > > <[email protected] <mailto:[email protected]>> > > wrote: > >> > >> On 2012-08-19 21:21, Gunnar Hellström wrote: > >>> > >>> On 2012-08-19 19:11, Mark Rejhon wrote: > >>>> > >>>> > >>>>> My proposal has now become: > >>>>> > >>>>> event='new' Senders MUST use this value when transmitting > >>>>> the first <rtt/> element containing Action Elements (i.e. > >>>>> when sending the first character(s) of a new message). > >>>>> Recipient clients MUST initialize a new real-time message > >>>>> for display, and then process action elements within the > >>>>> <rtt/> element. If a real-time message already exists, from > >>>>> the same sender in the same chat session, its content MUST > >>>>> be replaced (i.e. cleared prior to processing action > >>>>> elements). Senders MAY send subsequent <rtt/> elements that > >>>>> do not contain an event attribute. > >>>>> > >>>>> event='reinitialize' For recipients, both 'new' and > >>>>> 'reinitialize' are logically identical, and can process > >>>>> exactly the same [[[Action Elements]]], in any > > number, in > >>>>> any order. They differ only for implementation purposes > >>>>> (e.g. highlighting newly-started messages). Recipient > >>>>> clients MUST initialize a new real-time message for > >>>>> display, and then process action elements within the <rtt/> > >>>>> element. If a real-time message already exists, from the > >>>>> same sender in the same chat session, its content MUST be > >>>>> replaced (i.e. cleared prior to processing action > >>>>> elements). Senders MAY send subsequent <rtt/> elements that > >>>>> do not contain an event attribute. Recipients MUST be able > >>>>> to process 'reset' without first receiving 'new'. In > >>>>> addition, a common purpose of 'reinitialize' is > >>>>> retransmissions, including Message Reset, used for Keeping > >>>>> Real-Time Text Synchronized and Basic Real-Time Text. > >>> > >>> These definitions were fine before and still look good. > >>> > >>> I think the remaining problem is the talk about retransmission, > >>> when > > in reality it is retransmission and new transmission together. > >>> > >>> I withdraw my proposal to see the reset as just the part of > >>> the > > message that really is a retransmission. That view does not match > > your description of use of reset for the "Basic real-time text". > >>> > >>> So, instead we can accept your definition that results in that > >>> the > > message reset contains both the retransmitted and new text and > > other elements. > >>> > >>> Instead we need to adjust the words around retransmission. The > >>> first > > sentence in > > 4.6.3http://xmpp.org/extensions/xep-0301.html#message_reset needs > > to be modified. > >>> > >>> It is now: " A message reset is a retransmission of the > >>> sender's > > partially composed text. " > >>> > >>> How about: "A message reset is a transmission of the sender's > > partially composed text from the beginning of the real-time > > message." > >>> > >>> > >>> > >> Mark, you are on the right track when trying to change > >> nomenclature. The 'reset' event and the 'Message Reset' operation > >> are two quite > > different things and need to be clearly differentiated and > > described with different names. > >> > >> I think the name 'reset' is fine for the event. It is a command > >> for > > emptying the real-time message display buffer before acting on the > > action elements in the same and subsequent <rtt/> elements. The > > current description in 4.2.2 look fairly ok, even if I want to > > suggest a few small changes. > >> > >> But "4.6.3 Message Reset" is confusing by having nearly the same > >> name > > as the event 'reset'. > >> And it needs a slightly changed description. I suggest to change > >> the name to "Refresh" and introduce a bit of > > needed procedure description. > >> > >> You want the Refresh operation to contain both a retransmission > >> of the > > real-time message and any action elements caused since latest > > transmission. Some rules need to be applied on these two parts. > > The retransmit part need to be played out rapidly, while the > > latest additions need to be played with normal smoothing or obeying > > <w/> wait elements. > >> > >> That can be achieved in two ways. 1. Separate the retransmission > >> part from the latest additions in > > separate message stanzas and add a rule on 'reset' event that no > > smoothing and no wait elements shall be acted on during playout. ( > > wording may still need to be tuned to allow the "Basic Real-time > > text" in a simple way) > >> 2. Add the requirement on composing the retransmission part that > >> it > > may not contain any wait elements and require that other types of > > smoothing shall not be done during playout of a 'reset' event. ( > > this will make time-smoothed display of combined retransmissions > > and latest additions be jerky, I do not now see how we can indicate > > the border between retransmission and latest additions sent in the > > same <rtt/> element.) > >> > >> Mark, it is apparent that you have so far been thinking in terms > >> of > > alternative 2. > > > > No, I am thinking of: 3. All action elements at the beginning of > > <rtt/> containing either event='new' or event'='reset' must be > > played immediately (up to the first Wait Interval, if any) after > > clearing the real-time message, at the time <rtt/> begins to be > > processed. This is to prevent the flickering of a blank message in > > either situation. > > On first reading, I conceived of event='reset' as meaning "as a > reminder, this <t/> element specifies where we stand so far". The > possible confusion I saw was figuring out what to do with <rtt/> > children other than <e/> or <w/> (or <t/> attributes) in the reset. I > thought of those as needing to be delivered in future <message/> > stanzas. However, I hadn't considered the possibility of an empty <t/> > in the reset. In any case, there's really no way to programmatically > enforce any such rules (e.g., only bare <t/> if event='reset'). That > said, I do think we need to be clear about the generation and handling > of event-'reset'. > > > This also covers <rtt/> buffering/playback mechanisms including > > section "Receiving Real-Time Textt" > > > >> Section 4.6.3 can be amended to describe that alternative: > >> > >> 4.6.3 Refresh > >> > >> A message reset is a transmission of the sender's text from the > > beginning of the real-time message. > > To my mind, that could mean two things: > > 1. The message as produced so far (i.e., the equivalent of <body/> > except that it's expected further <rtt/> elements will be sent and > received). > > 2. A replay of everything that the sender sent so far, including > erases and waits and insertions and all that. > > > The recipient can redisplay the real-time message as a result. > > Redisplay the state of the message so far, or replay how that message > was generated? > > > It allows real-time text conversation to resume quickly, without > > waiting for senders to start a new message. > > > > I like your idea, except I will permanently change "Message Reset" > > to "Message Refresh", including the first few words of the > > paragraph (where you suggest I continue using the "message reset" > > phrase when it should really be "message refresh", to give it a > > distinction to "reset") > > I think that distinction is helpful. > > >> When the sender composes the part of the refresh that has been > > transmitted before, <w/> elements shall not be included.When the > > recipient acts on a refresh, no other waiting shall be applied than > > what <w/> elements indicate. > > > > The exact same rule applies for 'new' so I do not like adding any > > differences in behavior between 'new' and 'reset'. > > > > I may instead merge 'new' and 'reset' to solve the confusion > > altogether. I need to do some thinking, since I intend exact > > behavior and I want to prevent vendors from doing different. > > As I understand it so far, 'new' means we're starting a brand new > message after a message with a <body/>, whereas 'reset' means we're > doing a level-set on a message in progress. But I might be > misunderstanding things... > > Peter > > - -- > Peter Saint-Andre > https://stpeter.im/ > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.18 (Darwin) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAlAyTDUACgkQNL8k5A2w/vzyDgCg2Ssw3HGuvcS55ZRbC/q6c3Ov > ZRoAn1YuJUTkyZiwn03GoKthWTeF1HZ0 > =TGK7 > -----END PGP SIGNATURE----- >
