RE: 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.
+1
RE: So I am +1 with attempting to do websockets as part of this JSR,
+1
Those are the two things I agree with the most about your response. :)
The rest are just sorting out the details.
But some short responses below.
- 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.
*** I don't agree, but sort of a moot point if we are going to add support.
- Websocket indeed needs some stream based API, rather than something
based on byte[], mostly due to the unlimited size of frames.
*** Agree strongly with this.
- 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.
*** Fundamentally, I don't agree, but would love to see Rajiv's proposal. I
went through the mailing, list and somehow must have missed it. Where can I
find it?
*** My understanding is.... in order to stop frame corruption, you can't
really have two threads writing to the same client at the same time. At some
level something has to coordinate threads writing to the same client. This
is not a forever block, but a block used to coordinate message sending. Just
imagine two clients trying to write to the same TCP/IP connection. You can't
have half a message from one thread intermixed with half a message from a
second thread, intermixed with a third and so on.
*** Please correct my understanding if it is flawed. I will continue to
think about this as well and look at Rajiv's proposal.
- 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.
*** Give an example where it would be used. To implement what?
People use TCP/IP all the time, is there a packet filter in the servlet spec
so that
developers can inspect packets? No. WebSocket frames are at a very low
level.
I am not saying never. I am saying it does not have to be in the first
release.
If you feel it is a must, I would rather have it then not have WebSocket.
I just think it is a distraction.
- 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
** The threading model is split. The handlers are handled like Servlets.
It is non-blocking. It is only the writing that needs sync and the writing
can and most likely will happen in another thread.
use multiple threads to service many clients using a blocking API [if it
was non blocking, then this model is also wrong].
** I would agree which is why it was not proposed.
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.
** see earlier comments on frame corruption when writing to the same client.
- 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.
** What would the callback do? Come up with a use case for it. I can't think
of any.
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).
** Running my monkeys to school. Ran out of time for a longer response, but
it will be there. :)
On Wed, Oct 5, 2011 at 5:17 AM, Remy Maucherat <rmaucher_at_redhat.com> wrote:
> 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.
>
> - 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
>
>
--
*Rick Hightower*
(415) 968-9037
Profile <http://www.google.com/profiles/RichardHightower>