> I see, so you'd drop the idea of a handler altogether? I've been
> wondering about that one, too. Seems a bit redundant.
Yes, I think we can unify processing logic per application, instead of
having it per connection.
Alexey.
>
> 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
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>