So your WebSocketApplication is the same as WebSocketContext?
On 2/17/10 10:20 AM, Oleksiy Stashok wrote:
> Hi Justin,
>
> first of all, thank you very much for websockets implementation!
>
>> I'm thinking we'll need something along the lines of comet's handler
>> classes. Being able to register a handler and listeners and the like
>> opens up a lot of options.
> Agree, IMO the important thing here is to provide some higher level
> API for dealing with websockets. Hide low-level details as much as
> possible.
>
>> For example, currently the chat demo can't be nicely ported because
>> we don't/can't keep track of all the websockets opened up to the
>> system. So at a rough pass here are some of the objects I'm thinking
>> we'll need:
>>
>> * WebSocket (probably an interface so we can mock out portions for
>> testing) -- this would, of course, handle all de/framing issues
>> when reading/writing and notify the listeners of events
>> * WebSocketListener -- listens and handles events
>> * WebSocketHandler -- performs the actual operations needed
>> * WebSocketContext -- general meta class that could, for example,
>> keep track of all the open sockets for a given URI for broadcast/push
>> operations
>> * WebSocketEngine -- this would serve as the base entry point for
>> processing WS connections. This would serve to register contexts,
>> e.g., and create WebSocket instances based on the appropriate scheme
>>
> Just my 2 cents :)
> WebSocketsEngine as analog of CometEngine - agree. So it will be some
> centralized registry for WebSocketsApplications.
>
> WebSocketsApplication will process websockets connected to a specific
> URI:
>
> WebSocketsApplication {
> Set<WebSocket> getConnectedWebSockets();
> onOpen(WebSocket newWebSocket);
> onMessage(WebSocket webSocket, SomeMessageType message);
> onClose(WebSocket webSocket);
> }
>
>
> WebSocket - represents particullar web socket connection.
>
>
>> I'm not 100% on all of this but between looking over the grizzly
>> comet stuff, talking to jeanfrancois about his work with jetty's
>> implementation and atmosphere, and looking at other implementations,
>> I think something along these lines is probably what we'll end up
>> with. I'm by no means married to this approach though it's what I'll
>> start with unless there's some huge outcry. I plan on branching
>> today to play with this so any feedback is certainly welcome.
>>
>> I go back and forth about how to handle processing the websockets
>> threading wise. Currently it uses the same threadpool as the async
>> executor which, i think, is just the general worker thread pool.
> Right.
>
>> I'm wondering if we shouldn't use a (semi)private threadpool and
>> selector in either the engine or the context to manage these
>> connections. It might be ok to reuse the common worker thread pool
>> but I'm afraid of consuming all the threads for HTTP traffic while
>> processing these websocket requests. For now, i'll just continue to
>> reuse what we have but I'd really like some feedback there.
> IMO we have to use worker thread pool. Not sure why we may want to
> separate HTTP traffic from websockets traffic. For sure Websockets
> have to leverage NIO, and do not block during I/O operations.
>
>> I'd hate to have to reimplement so much of the NIO processes (that
>> was one of the problems with the original websockets code) but it
>> might be beneficial to move some of this processing off the main
>> pathways so that normal HTTP processing isn't affected too much.
> IMO it's not needed.
>
> Thanks!
>
> WBR,
> Alexey.
>>
>> On 2/17/10 8:13 AM, Paul Sandoz wrote:
>>> On Feb 16, 2010, at 4:37 PM, Justin Lee wrote:
>>>
>>>> This morning I committed basic support for websockets to the
>>>> trunk. It's located in modules/websockets and is more or less
>>>> ready to be played with. There are a few basic unit tests
>>>> included. Probably the most interesting is
>>>> WebSocketFilterTest.testSimpleConversation. It's a servlet-based
>>>> approach in which the servlet is largely unaware of the underlying
>>>> websockets work. This works well enough, but it does impose a
>>>> slight burden on the servlet author. This attempted complete
>>>> transparency does lead to a little bit of awkwardness in use, however.
>>>>
>>>> So now that it's working, we'll be doing some work on the API
>>>> itself to provide a cleaner way to register your components for use
>>>> in a websockets conversation.
>>>
>>> Great stuff.
>>>
>>>
>>>> So please play with it and give some feedback. We'd like to have a
>>>> nice, clean API we can all live with so if you have any input now's
>>>> the time. I'll be looking over what jeanfrancois has done with
>>>> atmosphere and jetty to see how much we can borrow
>>>
>>> I guess it depends on what you mean by "borrow" w.r.t. atmosphere.
>>> If it means copy from atmosphere then i would strongly suggest not
>>> and instead lets integrate with atmosphere, making changes as
>>> appropriate either way, as there is way more value in doing that.
>>> Especially at the higher level such that JAX-RS and Jersey can be
>>> leveraged and utilized with many useful Atmosphere features.
>>>
>>> Paul.
>>>
>>>
>>>> . Any suggestions are completely welcome. I want this to be
>>>> useful and usable for someone other than myself. :)
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
>>>> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
>>> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
>> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>