-----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-----
