> 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
>