I see, so you'd drop the idea of a handler altogether? I've been
wondering about that one, too. Seems a bit redundant.
On 2/17/10 10:47 AM, Oleksiy Stashok wrote:
>> So your WebSocketApplication is the same as WebSocketContext?
> Well, more or less. The difference with CometContext is that
> WebSocketsApplication is the single place, which has WebSockets
> processing logic. Where in Comet, processing logic was implemented
> separately for each connection inside CometHandler.
>
> Alexey.
>
>>
>> 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
>>>
>>
>> ---------------------------------------------------------------------
>> 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
>