[Standards] review of XEP-0301 [ event='reset']
markybox at gmail.com
Mon Aug 20 21:22:37 UTC 2012
On Mon, Aug 20, 2012 at 5:13 PM, Gunnar Hellström
<gunnar.hellstrom at omnitor.se> wrote:
>>> That would include many <w/> elements.
>>> If such a message refresh would be sent, it would take a long time to
>>> display, with severe flicker as a result.
>> That's right. However, again, (1) it's not "enforceable", and (2) I
>> don't want to confuse vendors about introducing a distinction (while
>> legitimate), might lead to incompatible new/reset differences in some
>> other implementations. That is my fear.
>> So that overrides a good reason to mention <w/> for reset, even though
>> normally <w/> will never be used as the first element of a reset.
>> So, I'm thinking of merging new/reset, once I hear Peter's response
>> and some other responses from this mailing list.
>>> Another (probably better) method would be to just recreate the resulting
>>> text and send the retransmitted part as a single <t/> element, possibly
>>> followed by new elements.
>>> Therefore I think it is still valid to insert a sentence in 4.6.3
>>> "When the sender composes the part of the refresh that has been
>>> before, <w/> elements shall not be included".
>> If I do not merge new/reset, then I have a preference towards
>> "Although there is no restriction on action element usage in
>> new/reset, it is advisable that the first element of <rtt
>> event='reset'/> is typically a <t/> whose purpose is to refresh the
>> I'd rather say that sentence (or a improved derivative thereof). It
>> 100% perfectly meet time-smoothed needs, and you simply skip doing a
>> time-smooth delay for the first <t/>.
>> But give me a few days to test alternative protocol designs that
>> resolves the confusion altogether, or alternative methods of wording
>> the current protocol (using "Message Refresh" terminology instead of
>> "Message Reset" terminology)
>> Mark Rejhon
> I do not at all mind if you settle the same rule for new as for reset. And I
> do not mind if you merge them ( to a 'renew' ?)
> I just wanted to make clear how the contents of the retransmitted part must
> be composed for the refresh to work as intended.
> Some implementers might get the impression that the event='new' or 'reset'
> or 'renew' has some specific influence making the action elements read out
> fast for the refresh action even if they include the old <w/> elements
> already transmitted.
Consider the scenario of when somebody immediately clears the
whole buffer (e.g. select all text with mouse, then hits Delete, then
starts typing), then the message reset starts shortly after. There
are many other edge cases that might cause a vendor to put legitimate
<w/> elements at the start of a <rtt event='reset'/> ...
There is legitimate <w/> in this case because it's an intentional
erased-message immediately followed by typing. One can do an empty
<t></t> to solve this problem of always expecting a <t> at the
beginning of a reset, but I am not going to enforce it. Implementer
software should be designed to be able to handle all possible orders
of action elements in <rtt/> ... I don't want to enforce anything
beyond the most important item below:
Anti-flickering is encouraged by, potentially adding this paragraph:
"Although there is no restriction on action element usage in
new/reset, it is advisable that the first element of <rtt
event='reset'/> is typically a <t/> whose purpose is to refresh the
message. In addition, all action elements at the beginning of <rtt/>
containing either <rtt event='new'/> or <rtt event'='reset'/> must be
processed immediately (up to the first Wait Interval, if any) after
the moment of clearing the real-time message (as specified by event
attributes of new or reset). This is to prevent the flickering of a
blank message in either situation, during regular [[[Message
I don't want to introduce potential confusion so that specific
implementations might cause problems or fail if they receive
unexpected elements at the beginning of <rtt/>. That's why I really
explicitly mean that new/reset is exactly the same logically, and I
don't want to define special behaviours other than the "immediate
instant playback after clear" -- which is the only important thing
that needs to be defined, that is currently missing, especially if I
don't merge new/reset.
Your suggested explanation would clear up your confusion, but would
introduce new confusions for others about the distinction of
new/reset. I am testing an alternate protocol that merges reset/new,
but I might keep them separate -- I need some time to think about how
to mitigate the risk of developers implementing incompatible
behaviours for new vs. reset. I'd rather come up with an
_enforceable_ protocol, but ordering of action elemements is not
_enforceable_ and there's no reason why it should be enforceable -- it
should be able to gracefully continue, no matter what action element
is the first action element of event=new/reset.
More information about the Standards