On 2012-08-20 4:20 AM, "Mark Rejhon" <marky...@gmail.com> wrote: > > > On 2012-08-20 4:15 AM, "Mark Rejhon" <marky...@gmail.com> wrote: > > > 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.
One last thing -- for time smoothed display, time smoothed playback should be omitted for the first element of any new/reset (or merged element). Most message refreshes will likely be one <t/> element at the beginning of a message, and this is sufficient, for hiccup-free time smoothed playback. I don't think I need to include specific presentation info in the spec on this, as most implementers will never do time smoothed playback, instead doing the Wait Intervals (key press intervals) as that is easier and preferred with the 0301 architecture on GUI systems.
