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

Mark Rejhon markybox at gmail.com
Mon Aug 20 16:11:19 UTC 2012


On 2012-08-20 11:47 AM, "Peter Saint-Andre" <stpeter at stpeter.im> wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 8/20/12 9:39 AM, Mark Rejhon wrote:
> > 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)
>
> I think event='new' is probably fine for both. Clearly, somewhere
> along the line someone thought that the distinction was valuable
> (e.g., because a client might have expected a message with a <body/>
> at some point and never received it). That reminds me, is there value
> in describing the state machine a bit more completely?
>
> Peter
>
> - --
> Peter Saint-Andre
> https://stpeter.im/

I am the one who decided the distinction was useful.

I mention that it is useful to know when a new message was just begun, and
do presentation behaviors (such as flash a highlight), versus whether the
message was started a while back.

If a client receives event=new, it means the message was started just now.

If a client receives event=reset, without ever receiving event=new, it
typically means the message was started before the recipient entered chat.
See "Keeping Real-Time Text Synchronized" (e.g. connecting after the sender
already started typing)   It applies to both one-on-one and MUC.

Different presentation behavior could occur with event=new such as a green
flash, or a color code for the first few seconds, or a "new" icon, etc.

Presently, RealJabber has no such presentation-related distinction, and
thus looks the same whenever I interchangeably use event=new vs event=reset
against their intended purposes.

That is why I am suggesting a fourth attribute (other than event, seq, id)
for indicating the start of a new message, to distinguish it from a
reset.   But that sounds somewhat messy.

Opinions, Peter?
I know it is not a hill to die on, but it is a legitimate concern that
implementers may misunderstand new/reset (which is logically identical
except for optional presentation purposes)

Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20120820/cd6f02ac/attachment.html>


More information about the Standards mailing list