Hi Justin,
> If you've been following the issues, you will have seen that I've
> finally been able to address a number of long standing issues with
> websockets on the trunk. Specifically today, i'm tackling https://grizzly.dev.java.net/issues/show_bug.cgi?id=841
> . This one has never sat well with and I'm going to clean that up.
> Here's what I'm thinking. I'm going to remove all notion of IO from
> the WebSocket on the server. (Client obviously still has to deal
> with stuff). Already on the server, we have an object capturing the
> key selection events and notifying the WebSocket object to read an
> unframe data. I want to move this out so that all the reading from
> the wire is done outside the WebSocket object. Once the data is
> read, the DataFrame will be passed to the WebSocket to handle as it
> wishes.
Sounds good!
> Going the other way, the WebSocket will build the DataFrame and
> notify the WebSocketEngine that it's ready to send. The WSE will
> have at least one thread to handle the actual writing of messages
> out to the client. This will give us an NIO-oriented approach to
> sending data while simultaneously simplifying any server side
> WebSocket classes. It also makes testing these classes *really*
> simple as there is no network layer that needs to be mocked away.
> It also paves the way for dramatically simplifying the internal code
> as it would potentially let us refactor the client and server sides
> to much more common code. (The difference being the handling of
> network traffic).
Can you pls. explain, you're planning to do actual writing in a
separate thread?
WBR,
Alexey.
>
> Hopefully this makes sense. If there are any objections, please
> speak up as I'm trying this now to test its general feasibility. It
> should work rather nicely and clean up the code quite a bit as
> well. If there are no objections, and if this approach works, it
> should be in svn in a day or two.
>
> Now's the time to speak up, though. :)
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>