[standards-jig] FW: [Foundation] Motion for Last Call - Chat State Notifications (JEP-0085)
Matthew A. Miller
linuxwolf at outer-planes.net
Mon Jan 19 22:01:19 UTC 2004
Just a few of notes from my perspective on Chat State Notifications
(CSN) vs. x:events.
Tying message events to a particular message id has many, many
problems. I wasn't really around when the decision was made to do this
in x:events, but I have a feeling it was because clients couldn't
(wouldn't) understand threads. Using the message id instead is a kludge
to work around this, and it's a very tricky kludge to get working
right. Most of the clients that have x:events support get it wrong,
which then creates inconsistencies between different clients' reactions
The "offline" and "delivered" events are missing from CSN because they
are handled by AMP (or Advanced Message Processing, JEP-0079). It was
determined by many that it is better to separate client-side and
server-side events. Since AMP includes support for these two events,
the CSN authors felt it was better to simply leave this support there
and not burden a client-side only protocol with server requirements.
The "displayed" event, however, falls into something of a gray area,
since it isn't strictly a state of activity, but definitely isn't a
server-side event. It is not currently part of CSN, and may or may not
fit well within it. Some people like having that notification possible,
but I've seen very few clients really do anything with this event.
Maybe someone can convince the authors of CSN to include this.
And finally, a number of the arguments against CSN that I read were
essentially, "we already spent all this time implementing x:events, and
now we have to implement this?!". To that, I have two things to say:
1) The "spent all this time..." part of the argument should be put
under serious consideration. If you spent a lot of time implementing
something, that usually means it wasn't simple. I firmly believe that
notifications (especially of this type) should not take a lot of time to
implement. Someone has already posted to this list about how long it
took them to implement both. That comparion still weighs quite heavily
in my "pro-CSN/anti-CSN" list.
2) You don't *HAVE* to implement Chat State Notifications, or
x:events. You could do one or the other, neither, or invent your own.
However, it most likely be in your best interest to implement CSN
(provided that CSN progresses to draft).
Again, these are just my thoughts, so your milage may vary.
 By "client-side", I mean "edge-side", or the ultimate recipient of
the message. But since it seems easier for people to think in terms of
clients and servers, those are the terms I use (-:
Dudley Carr wrote:
> I also had problems deciding on what to do with both JEP-22 and JEP85
> for our client. In the end, we decided to implement both. To be fair,
> if you've implemented JEP-22 then JEP-85 isn't a big step.
> Choosing exclusively between the two JEPs is difficult. Part of the
> reason why we chosen to implemented both JEPs is because there were
> non-overlapping features that we needed from both JEPs. The breakdown
> in terms of features is as follows:
> Intersection of JEP-22 and JEP-85:
> Composing notification
> Cancel composing notification
> <id> to associate a notification to a received message
> offline, delivered, and displayed notifications
> Gone notification
> A lot simpler to get correct
> Aside from the Gone notification, JEP-85 is pretty much a subset of
> JEP-22. My proposal would be for client developers to as a minimum
> implement JEP-85, and add on JEP-22 for advanced functionality.
> Standards-JIG mailing list
> Standards-JIG at jabber.org
More information about the Standards