One other thing to note with the removal of Sessions is that there will no longer be any ability to send Groovy scripts that depend on one another.
For example: "x = 1 + 1" "y = x + 1" won't work anymore because the x variable won't be saved to a Session's bindings. The impact of this change should be reduced because we will also be switching to gremlin-lang by default which never had this capability. This mostly affects users that want to use gremlin-groovy to send remote commands to the server. On Wed, Apr 3, 2024 at 5:01 PM Ken Hu <kenhu...@gmail.com> wrote: > 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 >>>> > >>>> >>>
