Mailing-List: contact dev-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Developers List" <dev@tomcat.apache.org>
Received-SPF: pass (nike.apache.org: domain of costin@gmail.com designates
 209.85.214.173 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <4F232EBC.4040902@apache.org>
References: <4F1F1F55.807@apache.org>
	<4F1FB94A.7030101@apache.org>
	<4F1FFCDB.60201@apache.org>
	<4F200100.2080902@gmail.com>
	<4F21DE79.6020604@apache.org>
	<4F232EBC.4040902@apache.org>
Date: Sat, 28 Jan 2012 17:20:35 -0800
Message-ID: 
 <CAP8-FqnPvsckj46sROg24zg1KFtwsUfX-rVvX2E8B=+ngXhc+w@mail.gmail.com>
Subject: Re: WebSocket progress report
From: Costin Manolache <costin@gmail.com>
To: Tomcat Developers List <dev@tomcat.apache.org>
Content-Type: multipart/alternative; boundary=f46d0447f2d86d1b3704b7a08954

--f46d0447f2d86d1b3704b7a08954
Content-Type: text/plain; charset=UTF-8

On Fri, Jan 27, 2012 at 3:09 PM, Mark Thomas <markt@apache.org> wrote:

> On 26/01/2012 23:15, Mark Thomas wrote:
> > Good news. The WebSocket implementation has reached a state where you
> > should be able to play with it. Receiving and sending of binary and text
> > data via streams/writers and messages is all working as long as you
> > don't use continuation frames. See the Echo example for the general idea.
>
> Some minor tweaks and clean-up [1]. Main improvement is that now if you
> write more data than the buffer can handle it doesn't fall over.
>
> > I'm leaning towards committing this
> > on the grounds that it changes very little of the existing code and -
> > fingers crossed - it should stay that way. It will be easier for the
> > wider community to experiment and provide patches once it is in trunk. I
> > expect that the back-port to 7.0.x will wait until things were more
> > feature complete and any obvious performance issues had been addressed.
>
> No-one has complained about this (yet) so I'll probably commit this some
> time next week.
>

Not complaining - it's great to add this feature, please commit it - but
I'm wondering
if a lighter interface wouldn't be better. From looking at the
implementation, it seems
 after the upgrade it keeps the InputBuffer/OutputBuffer ( and the whole
 Request / Processor / etc tree ).

Would it be possible for example to release the Request, like it's done
after request,
in keep-alive, and use a lighter parser/callback on the socket ? I think
one of the use cases
 for websockets is to support a _lot_ of open connections. Also the
interface may be
simpler without InputStreams.

Costin


>
> > Anyway, I hope you enjoy playing with this. As always, feedback welcome.
>
> Mark
>
> [1]
> http://people.apache.org/~markt/patches/draft/2012-01-27-websocket.patch
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>

--f46d0447f2d86d1b3704b7a08954--