Trying again:
Agreed. A client should definitely be under consideration or we'll see the
proliferation of APIs like we do for HTTP (and there are efforts to bring
that under a JSR as well) so we should try to be ahead of the curve there.
As for relying on the servlet spec, I'm with Greg on that. The upgrade
mechanism being bandied about there might be useful but the rest of the API
is largely irrelevant. One of the more common requests I've gotten for the
grizzly/glassfish API is a way to access the HttpSession so I think we
should keep an eye out for that but beyond that, we shouldn't have tie
ourselves to anything servlet related.
As for exposing queues and encoding mentioned above, I'm not sure about
them... Folding in encoding into the JSR is almost certainly a bad idea.
Even on this one app here at ${work} we have at least 3 ways to map an
object to json depending on what we're using it for and who's going to see
it. There are enough serialization schemes and libraries that I feel it'd
be more of a handicap than anything else to codify that into the spec. As
for queues, I'm not sure we have a need as such. In the grizzly
implementation, we have some partial buffering internally based on how the
NIO code works. But we never really expose that implementation detail to
the user. I'm not sure exposing a queue would gain us anything really. I
could kinda go either way on this one but I feel it's largely unnecessary.
On Tue, Apr 24, 2012 at 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
>>
>>
>>
>>
>> --
>> <http://www.oracle.com> * Danny Coward *
>> Java EE
>> Oracle Corporation
>>
>
>
--
You can find me on the net at:
http://antwerkz.com http://antwerkz.com/+
http://antwerkz.com/linkedin http://antwerkz.com/twitter
http://antwerkz.com/github