I've considered Option 1 more than once. Perhaps it is just time to do it. I'd be in favor of that, however it would have to be done for 3.7.x as it does represent a breaking change in a sense.
Or maybe it isn't a breaking change if you don't change the package names? gremlin-driver already depends on gremlin-core so maybe it doesn't matter? so, for 3.5.x you just move stuff and for 3.7.x I think we'd want to rename the package - "driver" doesn't seem suitable for gremlin-core to me for some reason. thoughts? On Mon, Oct 24, 2022 at 12:20 PM Cole Greer <[email protected]> wrote: > Hi Stephen, > > I was hoping to get some additional feedback regarding the pitch I made to > make the SimpleSocketServer available to all the GLV's. I agree with your > suggestion to create a new module gremlin-tools/gremlin-socket-server as it > seems like a good first step towards some sort of universal test server. > Unfortunately it doesn't immediately resolve any dependency issues. > TestWSGremlinInitializer which I would want to include in this new module > depends on several components of gremlin-driver including RequestMessage, > ResponseMessage, and some of the serializers. This is precisely the reason > that gremlin-server has a dependence on the driver as well and creates a > cyclic dependency problem between the driver and the new test server > module. After discussions with the BitQuill team we see 3 options: > > 1. Refactor gremlin-driver and extract all classes which are needed by the > server into gremlin-core or some other new module. By moving all of: > > tinkerpop.gremlin.driver.message.* > tinkerpop.gremlin.driver.ser.* > tinkerpop.gremlin.driver.MessageSerializer > tinkerpop.gremlin.driver.Tokens > > into a new package, the gremlin-tools/gremlin-socket-server will have > access to all of the classes it needs without a dependency on > gremlin-driver, resolving the cyclic dependency issue. Furthermore this > change would allow us to reduce gremlin-server's dependency on > gremlin-driver to a test scope which I believe is an improvement. > Pros: Most robust and long term solution. Allows the extraction of > SimpleSocketServer from gremlin-driver without losing and functionality or > ability for future extension. Allows all GLV's to depend on the test server > without a dependence on gremlin-driver. Provides a good foundation to build > a universal test server for all the GLV's. > Cons: Represents a huge structural change to gremlin-driver. Would need > a lot of consideration in how to handle this move to minimize user impact. > 2. Create a docker image from the simple-socket-server as it currently > exists as part of the java driver. Publish this image to dockerhub, and > configure GLV’s to run tests against this image. > Pros: Allows the socket server to continue with all its current > features and be accessible to all GLV’s without creating a direct > dependency on the java driver. No significant changes required to java > driver. > Cons: Having a published test image represents a barrier to changing > and adding new functionality or testing behaviours to the socket-server. > > 3. Extract Simple-Socket-Server to a new module and remove all dependencies > on the java driver. Dependence on serializers and ResponseMessage classes > could be stripped out in favour of hardcoded response strings. As it stands > right now the socket server is only used to test for a small handful of > scenarios and it would be fairly straightforward to have a few hardcoded > responses to select from. > Pros: Completely removes dependency on java driver without any large or > breaking changes. > Cons: Limits the ability to grow and extend the current socket server. > Not a useful step towards the universal test server which Stephen has been > talking about. > > Of all of these my preference is to go with number 1. I believe it would be > a good improvement to the structure of tinkerpop, but I'm not sure how best > to handle the migration. 2 and 3 both represent shorter term solutions to > get some use of SimpleSocketServer in the GLV's but don't make the same > progress towards standardizing the testing between all the GLV's. I suppose > a 4th option is to shelve all of this for now and proceed with maintaining > independent connection tests for all the GLV's but my preference would be > to try and improve on this where possible. > > Thanks, > > > *Cole Greer* > > On Mon, Oct 17, 2022 at 5:03 AM Stephen Mallette <[email protected]> > wrote: > > > If you think it's helpful, I'd say that's fine. Are you suggesting it be > > moved from gremlin-driver/src/test to gremlin-server/src/main? maybe it > > would go best in a new /server/util/test package? > > > > The only problem with moving it is that you end up with a circular > > relationship. gremlin-server depends on gremlin-driver so if you move it > > the gremlin-driver tests that depend on it won't work anymore. It's a bit > > weird but maybe you keep it in gremlin-driver and just move it to > > gremlin-driver/.../util/test? > > > > Or I guess the driver tests could move to gremlin-server along with the > > SimpleSocketServer related classes? that's a bit weird too though. > > > > Or maybe a new module is on order? create > > gremlin-tools/gremlin-socket-server? i think you'd avoid dependency > issues > > there between gremlin-driver and gremlin-server and the GLVs. Maybe this > is > > the best way as it would allow the independent development of a really > > robust test server without muddying existing packages with test > components. > > > > Sorry, I just sorta rambled my way to that last point which seems like it > > could be the best one. > > > > > > > > > > On Fri, Oct 14, 2022 at 4:27 PM Cole Greer <[email protected] > > .invalid> > > wrote: > > > > > Hi everyone, > > > > > > I have been working on TINKERPOP-2480 according to Ken's recent > > > proposal ( > > https://lists.apache.org/thread/x8lt6mk04r7h0nsdy9q3pz1pbo1t28tj > > > ). > > > I have found that the SimpleSocketServer combined with > > > TestWSGremlinInitializer in Gremlin-Driver to be a very useful > > > resource for creating tests which require custom response behaviour > > > from the server. From what I have seen this is something which the > > > other GLV's are currently lacking. I believe having such a test server > > > accessible to the other GLV's would be a useful step towards > > > standardizing the testing between all the GLV's and bringing more > > > behavioural tests to the GLV's. In order to do this I would propose > > > moving the SimpleSocketServer from the tinkerpop.gremlin.driver > > > package to tinkerpop.gremlin.server and running it in the existing > > > gremlin-server-test docker container on a new port. > > > > > > I would greatly appreciate any feedback on this idea, whether you find > > > it to be useful or have any concerns. > > > > > > Thanks, > > > > > > Cole > > > > > >
