> the choice is basically either to implement a new one for the GLV or add an existing one to TinkerPop once the GLV will be added
By "existing one" I assume that you mean that the GLV would include a third-party driver? I suppose that could happen, but the driver code would still have to conform to TinkerPop naming standards and patterns so I would bet that some significant changes would be required to that third-party driver - perhaps enough so that it really just looked like "implementing a new one". Anyway, the GLV probably wouldn't be accepted without some form of driver as it would be inherently incomplete. There has to be some way to connect the GLV to Gremlin Server as a default implementation. I'm not sure that we've formalize the requirements yet, but I'm sure we would evaluate any GLV that was submitted with the following general guidelines that have been discussed on this list in the past: 1. The GLV should keep in line with class/method names of the java API where possible to ensure consistency of feel across languages. 2. There needs to be adequate tests (we're still discussing the approach to testing GLVs and i think that needs to be tackled sooner than later as more GLVs start to come in). Those tests should produce xunit style output unless there is some good reason not to. 3. There needs to be adequate documentation (e.g. Reference docs) 4. The build/deploy process needs to be bound to maven which might be one of the trickier bits to deal with. This list may or may not be "complete" and is obviously quite general in nature, but perhaps at least summarizes some of the concerns we've discussed on the list in relation to new GLVs. Note that we will likely move slowly on bringing in a GLV as it will mean a major change to the TinkerPop code base. Be prepared to be patient and to rebase your PR a lot if you decide to submit something. :) On Mon, Nov 14, 2016 at 10:22 AM, Florian Hockmann <[email protected]> wrote: > Ok, I didn’t know that there is already such an interface for Java. That > is of course a good starting point for a C# GLV. It could define a similar > RemoteConnection interface in C# and therefore allow users to choose any > driver that implements this interface. > > Regarding your point on “TinkerPop native drivers”: Since there currently > is no .NET driver in TinkerPop, the choice is basically either to implement > a new one for the GLV or add an existing one to TinkerPop once the GLV will > be added. > > Are there any requirements for drivers to be included in TinkerPop so they > can be used as a default driver by GLVs? > > -----Ursprüngliche Nachricht----- > Von: Stephen Mallette [mailto:[email protected]] > Gesendet: Montag, 14. November 2016 13:36 > An: [email protected] > Betreff: Re: GLV - Languages with no JVM support > > We've already established that GLVs should have TinkerPop native drivers > i.e. TinkerPop GLVs won't rely on third-party drivers. We have a > RemoteConnection interface that allows the GLV to plug in any driver that a > user wants. Here's the related java implementation: > > https://github.com/apache/tinkerpop/tree/ccdb01c5bef7f1d25d86bcb563fc4a > 59cb3b59e0/gremlin-driver/src/main/java/org/apache/ > tinkerpop/gremlin/driver/remote > > For gremlin-python we sorta did things in reverse and built the GLV around > a very limited "driver" - I say "reverse" because the driver came as a > result of the GLV and I tend to think the focus should initially be a solid > driver implementation that is tied to the GLV, but that's not really an > issue. With some help from David Brown we still intend to build a > legitimate gremlin-python driver that can be used in a standalone fashion. > This would be more in line with how gremlin-java is organized. > > > > > > On Mon, Nov 14, 2016 at 6:56 AM, Florian Hockmann <[email protected]> > wrote: > > > Hi Jorge, > > > > Interesting to hear about your plans for a GLV for C#. > > > > I worked on such a GLV when the topic came up on this mailing list. It > > was basically working, but that was unfortunately before Gremlin > > Bytecode was introduced. So it produced Gremlin queries just as > > strings. I stopped working on that as I wanted to wait until it became > > clearer how GLVs should work exactly. > > Therefore, I concentrated on a Gremlin driver for .Net instead that > > should just offer the basic functionality of sending queries to the > > Gremlin Server and can therefore be used by a GLV. This is now > Gremlin.Net: > > https://github.com/FlorianHockmann/Gremlin.Net (some functionality is > > still missing, like support for clusters) > > > > Maybe we can work together on the C# GLV? > > > > Regarding the integration in TinkerPop: I would also suggest to > > implement the GLV for .NET Core which would allow to build and test it > > on Unix systems. > > > > Another question is the choice of the driver for the GLV. You probably > > want to use your DataStax driver, but that would limit the GLV to just > > DSE Graph. Using Teva Gremlin or Gremlin.Net would allow to work with > > all TinkerPop compatible systems, but then your customers cannot use > > your driver anymore. Maybe, the GLV can define an interface that all > > drivers can implement so users can switch the driver? Then the GLV > > could use a default driver without restricting users to it. > > > > Best Regards, > > Florian > > > > > > -----Ursprüngliche Nachricht----- > > Von: Jorge Bay Gondra [mailto:[email protected]] > > Gesendet: Montag, 14. November 2016 09:51 > > An: [email protected] > > Betreff: Re: GLV - Languages with no JVM support > > > > Sounds good, we can evaluate the possibilities per each non-JVM > > language GLV. > > > > In the case of C#, there is now a new runtime and build tools ".NET Core" > > that runs in any major platform, that could be suitable for building > > and running the tests of the GLV. > > > > Thanks, > > Jorge > > > > > > On Fri, Nov 11, 2016 at 2:44 PM, Stephen Mallette > > <[email protected]> > > wrote: > > > > > Thanks for clarifying. > > > > > > I guess I would say that it would be ideal if we had the code in > > > TinkerPop, as TinkerPop should be responsible for the interfaces of > > > a GLV. Of course, I'd acknowledge the technical challenges of doing > > > that, plus I'd further note the lack of a testing framework for > > > non-JVM languages, which has been part of other discussions. I came > > > up with a good way to get gremlin-python worked into the standard > > > TinkerPop build. I suspect the same pattern would work for gremlin-js. > > > The key to those is the .glv file that tells maven whether to even > > > bother trying to build it or not. In this way, the project stays > > > generally buildable with mvn clean install, even if your environment > > > isn't setup to handle python (for example). So, if you aren't setup > > > to build gremlin-js in your environment, just omit the .glv file and > > > focus > > on the rest of the project. > > > > > > Does that pattern make sense for gremlin-csharp? i sorta think so. > > > If I'm on linux without NET then it would simply be ignored. If i > > > get linux running with mono (i assume that is still a thing) then i > > > add the .glv file and presumably we can get maven to automate a > > > csharp build > > somehow??? > > > > > > I think the short answer from my perspective is that I'm not against > > > having these non-JVM GLVs be in TinkerPop so long as we have a good > > > means for building, testing, and deploying. If we find having all > > > these GLVs in our current "JVM" repo doesn't work too well, we can > > > also request additional git resources from Apache Infra. As I > > > generally tend to handle releases, my preference would be to have > > > one repo with one deploy cycle where everything is versioned at the > > > same > > time. > > > > > > > > > On Fri, Nov 11, 2016 at 8:25 AM, Jorge Bay Gondra < > > > [email protected] > > > > wrote: > > > > > > > For specification I mean a formal documentation detailing the GLV > > > > API > > > for a > > > > certain language, including naming convention, return types, > > > > limitations and side effects that can be versioned along with > > > > Apache > > TinkerPop. > > > > > > > > With that specification as part of the TK documentation, an > > > > implementer could state "Supports Apache TinkerPop C# GLV 3.3" > > > > > > > > On Fri, Nov 11, 2016 at 1:03 PM, Stephen Mallette > > > > <[email protected]> > > > > wrote: > > > > > > > > > Could you expand on what you mean by a "GLV spec" that you > > > > > mention in > > > > item > > > > > A? > > > > > > > > > > On Fri, Nov 11, 2016 at 6:38 AM, Jorge Bay Gondra < > > > > > [email protected] > > > > > > wrote: > > > > > > > > > > > Hi, > > > > > > After the [Javascript GLV][1], I'm thinking of creating a GLV > > > > > > for C#, > > > > > but I > > > > > > don't know if a GLV for a language like C# or C++ with no JVM > > > > > > support (decent JVM language implementation nor scripting > > > > > > support) belongs in > > > > the > > > > > > TinkerPop repository as it won't be able to easily integrate > > > > > > with the > > > > > rest > > > > > > of the projects. > > > > > > > > > > > > A) Should we include only a GLV spec for those languages? > > > > > > B) Should we create a full GLV inside the TK repo, adding the > > > > > > build > > > > tools > > > > > > for those runtimes as dependencies to run the tests ? > > > > > > > > > > > > Thanks, > > > > > > Jorge > > > > > > > > > > > > [1]: https://issues.apache.org/jira/browse/TINKERPOP-1489 > > > > > > > > > > > > > > > > > > > > > > > >
