I've taken this discussion to jetty-dev as it would be good to get wider feedback on the next steps.
We have a new implementation of the websocket protocol ready to be integrated into Jetty-10. It is pretty much a total rewrite that applies a few years of experience with the protocol, current best practises from other protocols, plus knowledge of the demands of the JSR API and interest in a reactive streams API as well.
So next steps are to get it integrated back into the main branch of jetty-10.0.x and there are a number of challenges and choices for that:
The websocket core is currently in a single maven sub-project with top level package of org.eclipse.jetty.websocket.core. It has been structured to be JPMS ready so that implementation classes are in 'internal' sub packages.. It also includes client and server sub packages with the client and server specifics (only a few classes for each). The server and client dependencies are brought into the sub-project as provided dependencies, so they will not be included as transitive dependencies - so a client need not have server dependencies and versa vice. However, it has been suggested that split into core, core.server and core.client sub-projects and matching jpms modules. To me, that feels like a little bit of overkill, but unless there is a loud shout of "don't bother" I will go ahead as I think it will tie in well with the JPMS work we have been doing and will provide good JPMS modules that will provide a websocket client or server.
The JSR websocket API implementation has been taken on the refactor ride using jetty-core as it's protocol layer, but it has been a bit neglected, so that while it current compiles, but has a few failing tests. Thus we need to focus on cleaning up this API layer and passing all it's tests. We also need to check recent changes to jetty-9.4 JSR implementation and make sure we have all the needed updates. That's just a bit of work and we'll get on with it in the next few weeks... There is also probably similar packaging questions to core that need to be considered and resolved.
- Just dump the old jetty websocket API and it will not be available in jetty-10. Users can use either the JSR API if they want the standard, or program directly to the public parts of the websocket-core module, which effectively become the new jetty websocket API. This spares a lot of effort, which can be redirected into creating a reactive stream based API on top of websocket-core.
- Revert the websocket-api in the development branch to exactly the same as what is in jetty-9.4, and then write a new implementation of it using websocket-core. This is a bit of work.
- Advance with jetty-10 development based on option 1 above.... it the screaming becomes too loud then switch to option 2.
Once we get some feedback and decide the direction, we will prepare some pull requests to get this work back into the main jetty repository.
cheers
--
