In that document you say:
- Define an API that can be implemented atop any Servlet 3.1 container
Does that mean the API is intended to work on top of the Servlet 3.1 upgrade support? Ie is the intention to have JSR356 implement the websocket protocol within a library that is part of the WAR/EAR?
I think that is OK to support, but I think it is also very important to support the deployment mode where the container itself provides the implementation of protocol and the WAR/EAR needs provide no more than the annotated POJOs. Jetty currently supports websockets in both 2.5 and 3.0 Servlet containers and we would not want to have to force our users to wait for and then upgrade to 3.1 before using a standards based websocket API. I also think that the protocol will be able to be implemented a lot more efficiently in the container than in the application.
Also you say:
I think this should be more than explore. There already exists standalone java websocket clients, so they should also be able to access the standard API as soon as possible.
- [Explore] Standalone Java client API derived from/sharing much in common with the EE API
cheersOn 21 April 2012 08:29, Danny Coward < " target="_blank"> > wrote:
Before we get to APIs and all that, I want to spend a little time talking about the high level requirements of the JSR. These were more or less laid out in the JSR itself, so that's always a good place to check back on as we get deeper into this.
But I've laid them out again (attached document), together with the deployment settings, and a short description of an example application and how it all works that uses the output of the JSR.
This is intended to surface high level issues, and is mostly a vehicle to see how we collectively see this working.
So, please feel free to post me your thoughts/suggestions/random issues this brings up - either to the list or just to me as you prefer.
[jsr356-experts] Re: [jsr356-users] Re: High level Requirements and Example scenarios