On 2012-08-20 11:47 AM, "Peter Saint-Andre" <[email protected]> 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
