https://issues.apache.org/bugzilla/show_bug.cgi?id=51181
--- Comment #26 from Mark Thomas <ma...@apache.org> 2012-01-18 22:35:07 UTC --- I dug out my old ideas and have been updating them. You can see how far I have got in [1]. Note that this is all very early days and pretty much everything is subject to change and a lot of the detail is missing. That said, I think the broad strokes are heading in the right direction. Key points are: - Limited connector (BIO/NIO/APR) specific code (thanks to the previous re-factoring) - Write apps by extending WebSocketServlet - Also interface to implement / base class to extend for reading / writing - Provide stream-based and message-based APIs (stream will be implemented first and then message-based with configurable buffers on top off the streaming API) - message-based API likely to be similar to Jetty's - will align to common API if at all possible - reading/writing will use blocking IO per message (much, much simpler to implement and only the NIO connector could do non-blocking - could possibly add non-blocking IO later if there is sufficient demand) As soon as I have something that roughly works end to end (i.e. I can get the WebSocket equivalent of HelloWorld working) I'll commit this to trunk with the aim of back-porting it to 7.0.x once the integration points are stable. It looks as if the integration points are going to be few and well defined so they should be stable pretty quickly which bodes well for getting this into 7.0.x. The message-based API isn't dissimilar to the Comet-style API proposed above but rather than a single call-back with different event types, there will be one call-back per event type (close, text message, binary message). Control messages will be handled at a lower level. One caveat and I can't stress this enough. The devil will be in the detail and experience with the Servlet 3.0 async work has shown that what appears to be a complete, working implementation may need a major re-write to make it stable. It isn't beyond the realm of possibility that there is a huge logical flaw in the approach I have taken so far that necessitates ripping most of this up and starting again. Finally, there has been an awful lot of interest in this enhancement request but not much in the way of contributions. Hopefully as the code starts to get committed, contributions will be easier. Discussions on the patch are best held on the dev mailing list. I only wrote this progress report in BZ in case folks who are cc'd on the bug aren't on the dev list. [1] http://people.apache.org/~markt/patches/draft/2012-01-18-websocket.patch -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
