[Standards] review of XEP-0301 [ event='reset']

Mark Rejhon markybox at gmail.com
Mon Aug 20 08:20:33 UTC 2012


On 2012-08-20 4:15 AM, "Mark Rejhon" <markybox at gmail.com> wrote:
>
>
> On 2012-08-20 3:32 AM, "Gunnar Hellström" <gunnar.hellstrom at omnitor.se>
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.
>
> 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. The recipient can redisplay the
real-time message as a result. 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")
>
> >
> > 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.
>
> (In realjabber, I can do message resets via event='new' too -- no
difference in visual behavior")

When merging, add a forth attribute or some other tiny indicator for those
implementers who want to signal the start if new message (presentatiton
behavior)

I am not going to specifically disallow any elements and order for either
new/reset. There is no enforcement, even <w/> at the beginning, because the
new/reset both should instantly playback immediately after the moment the
message buffer is cleared, up to the first <w/> element.  That is the only
info missing from the spec, and you have pointed out this excellent
omission that I shall add.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20120820/aded2db6/attachment.html>


More information about the Standards mailing list