Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jetty-dev] Websocket in Jetty-10?


On Sat., 29 Sep. 2018, 21:43 Joakim Erdfelt, <joakim@xxxxxxxxxxx> wrote:
Greg,

In your proposal to dump the Native Jetty WebSocket API and using the websocket-core instead.
Can you detail what this means?  
What would we gain?  

We would save a bit of effort as we would not need to port and maintain the old API.

We would have a new API that is more up to date and without legacy stuff.

What would we lose?

We would lose backwards compatibility for all those who have implemented against the current API.

The new core API is simpler but offers less features.  This may result in pressure to add features to core... which is kind of against the while idea of core.


What will the changed API look like?

Basically just what is in the current collaboration core package... Perhaps split to client and server sub projects. There is a chat room example in tests that shows basic usage.


Another option is that we do port the old API into core, but deprecate it so that we don't need to maintain long term. If timing was different we could have done this in 9.4 so 10 could drop it.

Note that I'm undecided and had thought we'd support the existing API as is or with minor modifications. But the suggestion was made to drop it, so I'm sounding out that option... But deprecating first would be better practise.

Cheers


Joakim Erdfelt / joakim@xxxxxxxxxxx


On Fri, Sep 28, 2018 at 11:50 PM Greg Wilkins <gregw@xxxxxxxxxxx> wrote:

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.

This implementation is in https://github.com/webtide/jetty.collaboration/tree/jetty-10.0.x-websocket/jetty-websocket/websocket-core and it is passing it's own extensive tests plus the autobahn test suite.

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.

The next big question is what to do with the current jetty websocket API  https://github.com/eclipse/jetty.project/tree/jetty-9.4.x/jetty-websocket/websocket-ap:i ? This too was taken on the refactor journey with the development of the websocket-core, which is precisely the wrong thing to have done... as this has changed the API and will break backwards compatibility.   So there is a choice of which way to go forward:
  1. 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.
  2. 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.
  3. 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






--

Back to the top