Background: - WebSocket 1.0 will sit on top of Servlet 3.1's HTTP upgrade - HTTP upgrade uses Servlet[Input|Output]Stream - Non-blocking IO has been added to Servlet[Input|Output]Stream for Servlet 3.1 - The way I implemented HTTP upgrade (separate processors so everything is very light weight and scalable) means a separate non-blocking implementation is required (the work Filip did hangs off the AsyncContext)
Current status - I have an initial implementation of HTTP upgrade that supports blocking and non-blocking - I have some very basic unit tests for this implementation - I have hacked the WebSocket implementation to use the new HTTP upgrade implementation Next steps - Start to implement the new WebSocket API - Port the existing WebSocket code to the new API My proposed way forward is as follows: a) Commit the HTTP upgrade changes to trunk b) Start to implement the new WebSocket API c) Port the WebSocket examples to the new API d) Get the Autobahn test suite working with the new API implementation The main issue is that the WebSocket implementation in trunk may be unstable for extended periods of time. Given the choice of instability or large amounts of local development, I'd rather have the instability so folks can see what is happening. It should only be WebSocket that is affected. Everything is nicely decoupled from the normal processing chain. A secondary consideration is that bugs in 7.0.x's WebSocket implementation will need to be fixed directly in 7.0.x once the implementation starts changing in trunk. Before I set git-svn off committing the HTTP upgrade changes, does anyone object to the proposed way forward? Cheers, Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
