Skip to main content

[jsr356-experts] Re: [jsr356-users] Re: High level Requirements and Example scenarios

  • From: Justin Lee < >
  • To:
  • Subject: [jsr356-experts] Re: [jsr356-users] Re: High level Requirements and Example scenarios
  • Date: Tue, 24 Apr 2012 13:50:54 -0400

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 < " target="_blank"> > 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 < " target="_blank"> > 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




--
Danny Coward
Java EE
Oracle Corporation




--



[jsr356-experts] High level Requirements and Example scenarios

Danny Coward 04/20/2012

[jsr356-experts] Re: High level Requirements and Example scenarios

Mark Thomas 04/22/2012

[jsr356-experts] Re: High level Requirements and Example scenarios

Scott Ferguson 04/22/2012

[jsr356-experts] Re: High level Requirements and Example scenarios

Scott Ferguson 04/23/2012

[jsr356-experts] Re: High level Requirements and Example scenarios

Greg Wilkins 04/24/2012

[jsr356-experts] Re: High level Requirements and Example scenarios

Wei Chen 04/24/2012

[jsr356-experts] Re: High level Requirements and Example scenarios

Remy Maucherat 04/24/2012

[jsr356-experts] Re: [jsr356-users] Re: High level Requirements and Example scenarios

Justin Lee 04/24/2012
 
 
Close
loading
Please Confirm
Close