One thing to add to this is that SASL is difficult to support with HTTP/1.1 so it will likely need to be dropped. This means that only Basic Auth will be supported with HTTP/1.1. Support for SASL can be added back when we move to HTTP/2. However, I'm not sure how widely SASL was used. If there aren't any complaints from users when it is temporarily removed for HTTP/1.1 then maybe we should just consider dropping support for it altogether and not adding it back.
On Mon, Mar 4, 2024 at 3:02 PM Ken Hu <kenhu...@gmail.com> wrote: > I believe that I've answered most questions about this and there doesn't > seem to have been any objections. Therefore, I'm going to assume consensus > has been reached and that we will move forward with HTTP only in the next > major release. > > As part of the work to move to HTTP, I would like to simplify some other > parts of the server that I believe aren't being used. This will help to > simplify some of the options and arguments used in the HTTP API. > Specifically, I would like to remove support for OpProcessors, Sessions, > and the UnifiedChannelizer. OpProcessor is an interesting concept to allow > providers to add and modify server functionality but it doesn't seem like > it was ever used (other than by the default ones provided). Sessions are > tied to WebSocket connections and the threaded nature of the current > Transaction API. However, the Transaction API will get reworked and > WebSockets is being removed which makes the Session concept obsolete. The > UnifiedChannelizer, I believe, was supposed to simplify Sessions but since > sessions don't make much sense anymore, it probably doesn't make sense to > keep the UnifiedChannelizer around either. > > Is anyone aware of any implementations that are actively making use of > these? If not, I think it makes sense to remove or replace them in the next > major version as well. > > On Thu, Feb 29, 2024 at 12:52 PM Ken Hu <kenhu...@gmail.com> wrote: > >> Thanks for the responses so far. >> >> I think we're still open to having multiple protocols as long as there is >> some form of commitment to maintaining it and there is demand for it within >> the community. This would mean that we could add grpc but someone would >> have to be willing to step up to maintain it. Also, I view HTTP/1.1 as a >> starting point for the transition from WebSockets to HTTP. The features you >> mentioned that would be beneficial are part of HTTP/2 which, I think, is >> where we probably want to head longer term. >> >> From an end user perspective, there should hopefully be little to no >> change at all. The underlying protocol used to communicate with the server >> is mostly transparent to them when they use the GLVs. The only real >> difference is that they will probably have to adjust some of their >> connection options which is something users have raised issues with before >> and this would improve that situation. The users that potentially will get >> affected the most are those that use a third party driver, they may have to >> continue using 3.x unless those drivers are updated. For providers, this >> change shouldn't affect them as long as they use the Gremlin Server (which >> from what I can tell includes most providers). In the end, I believe this >> is a change that may cause some minor differences for users, but will >> mostly help with the continued maintenance of the project. >> >> On Wed, Feb 28, 2024 at 4:38 PM Josh Perryman <joshperry...@gmail.com> >> wrote: >> >>> I understand the cost/complexity argument. But do we have any sense of >>> the >>> value / feature side of things? What's the implementation look like among >>> providers? Is it exclusively HTTP or do some implement both, or just >>> Websockets? From there, what about actual usage among users? Do the >>> implementers see any preference on that side? >>> >>> I think this a reasonable ask, but the way it is presented is heavily >>> biased toward developer preferences. Do we have any information on the >>> user >>> side? >>> >>> -Josh >>> >>> On Tue, Feb 27, 2024 at 4:29 PM Ken Hu <kenhu...@gmail.com> wrote: >>> >>> > Hi All, >>> > >>> > I would like to start the discussion of making HTTP the only protocol >>> that >>> > Apache TinkerPop supports starting with the next major version. There >>> are >>> > several reasons I'm suggesting this. First, we already support both >>> > WebSockets and HTTP in Gremlin Server which causes a maintenance >>> burden of >>> > having to support both. Also, I ran some tests and a streaming version >>> of >>> > HTTP using chunked transfer encoding performs just as well as >>> streaming via >>> > WebSockets so there won't be a performance loss in terms of latency. >>> > Second, HTTP is significantly more popular so it will be easier for >>> other >>> > third party clients to connect to. Third, this is an opportunity to >>> rework >>> > the remote Transaction API which in its current form causes unnecessary >>> > complexity in the server. This will also serve as a good opportunity to >>> > make the connection options more similar among all the GLVs. >>> > >>> > I've experimented with replacing WebSockets with HTTP (both 1.1 and 2) >>> and >>> > noticed similar performance in most cases. For HTTP/1.1, there was some >>> > slowdown in cases where thousands of queries with few results were >>> issued >>> > per second as lots of HTTP connections needed to be opened, but I feel >>> like >>> > this isn't a practical use case. My recommendation for now is to go >>> with >>> > HTTP/1.1 as it has all the features we need and it has mostly been >>> > implemented already on the server side. >>> > >>> > To ease the transition, I'm suggesting that we maintain WebSockets for >>> the >>> > foreseeable future in the 3.x line while the 4.x line is moved to use >>> HTTP >>> > exclusively. This will also give more time for us to build out support >>> for >>> > transactions over HTTP which is the only missing feature that is >>> supported >>> > when using WebSockets. >>> > >>> > I'd like to hear any thoughts regarding this. >>> > >>> > Thanks, >>> > Ken >>> > >>> >>
