[standards-jig] FW: [Foundation] Motion for Last Call - Chat State Notifications (JEP-0085)

Dudley Carr dudley at cs.stanford.edu
Mon Jan 19 21:19:51 UTC 2004


> i still think we dont need that JEP. And i know that there are difficulties
> and different opionions on the <id> tag. I started some threads to solve
> this in the standards list. Without success :(. I think its no solution to
> create a new completly different and not compatible JEP to solve the
> 'issues' in JEP22. Most clients use JEP22 for a very long time now. And it
> works pretty well. JEP22 Also supports displayed and delivered. And i dont
> wanna spend time on implementing JEP85 in our client. And im also not
> interested to replace JEP22 with 85 or supporting both side by side. This
> doesnt bring Jabber/XMPP forward. Its slows down all our development. I
> wanna spend my time on implementing other important JEPS. When we make new
> stuff or change smth then it should be compatible. MUC is the best example
> for this.
> 
> Alex

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



More information about the Standards mailing list