I agree that we should lower the requirement on Sevlet version (to, e.g.
2.5). Is there a reason that Web Socket has to use Servlet 3.1?
Thanks.
- Wei Chen
On 4/24/12 2:40 AM, "Greg Wilkins" <gregw_at_intalio.com> wrote:
>
> Danny,
>
> 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:
> * [Explore] Standalone Java client API derived from/sharing much in common
> with the EE API
> 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.
>
> cheers
>
>
>
> On 21 April 2012 08:29, Danny Coward <danny.coward_at_oracle.com> wrote:
>>
>> Hello experts,
>>
>> 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.
>>
>> Thanks,
>>
>> - Danny
>>
>>
>>
>>
>>