[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 
to x:events.

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[1] 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.


-  LW

[1] 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
>
> JEP-22:
>   <id> to associate a notification to a received message
>   offline, delivered, and displayed notifications
>
> JEP-85:
>   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.
>
> Regards,
> Dudley
> _______________________________________________
> Standards-JIG mailing list
> Standards-JIG at jabber.org
> http://mailman.jabber.org/listinfo/standards-jig





More information about the Standards mailing list