On Wed, 2011-10-05 at 02:38 -0700, Rick Hightower wrote:
> The purpose of this proposal is to table the needs for WebSocket, and
> state emphatically that WebSocket needs to be in JSR-340. WebSocket
> support in JSR 340 needs a simple streaming interface. Two small
> interfaces and one additional method to ServletRequest is all that is
> proposed. This WebSocket package is at the same level of abstraction
> as the Servlet API but geared toward WebSockets.
Ok, this is too long for me to fully comment in only one reply, but:
- There is indeed a need to amend the JSR to encompass a separate
websocket API. I am rather ok with that.
- Websocket is labelled as the next big thing. To be honest, I think it
has serious issues, especially the unlimited frame size. It means no
corruption detection for missing data, and the API becomes exponentially
more complex.
- Websocket indeed needs some stream based API, rather than something
based on byte[], mostly due to the unlimited size of frames.
- What you propose is a blocking API equivalent to Servlet 1.0 for HTTP,
and this is not acceptable. For the most immediate issue, you can look
at Rajiv's first proposal which adds non blocking to a stream API.
- No filtering is a problem, it does not sound good to label it as "if
needed". I simply don't understand how it would not be needed
immediately.
- The portion on lock design for output based on hijacking close()
methods from streams is not right. The goal is to use one thread to
service as many clients as possible [using a non blocking API], not to
use multiple threads to service many clients using a blocking API [if it
was non blocking, then this model is also wrong]. A model where multiple
async threads are supposed to wait on locks is wrong, because the
threads will soon all be waiting on slow clients.
- I think integration with Servlet API needs something. There is no
callback at all here, on purpose, but I don't agree with that choice.
So I am +1 with attempting to do websockets as part of this JSR, but -1
on doing a quick and dirty API for it (it needs to have at least the
same level of non blocking IO functionality as its HTTP counterpart,
plus likely some filtering).
--
Remy Maucherat <rmaucher_at_redhat.com>
Red Hat Inc