> I just committed what'll likely be the API (for the most part) in
> the websockets branch. There's a little more lifecycle stuff to
> handle (socket closures, e.g.) but i'm working on the chat sample now.
Looking forward to see it :)
>
> On 2/17/10 10:39 AM, Paul Sandoz wrote:
>> On Feb 17, 2010, at 3:37 PM, Justin Lee wrote:
>>
>>> 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. 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
>>>
>>> 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.
>>
>>
>> OK. A low-level approach such as that makes sense to me. Alexey and
>> other Grizzly developers are in a much better position than I to
>> comment on the specifics.
>>
>> My concern is we should try and avoid duplicating stuff that is
>> already in Atmosphere and instead plug into it for such
>> requirements, and it should be easy to plug in to. But from what i
>> gather there will be no such duplication.
>>
>>
>>> 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. 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. 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.
>>
>> Excuse my ignorance but on this particular matter how would
>> WebSocket be any different to the demands of say Comet+Bayeux in
>> this respect?
>>
>> Paul.
>>
>> ---------------------------------------------------------------------
>> 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: dev-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>