Yes exactly, I meant that the GLV just uses a third-party driver that conforms to TinkerPop standards and then the driver can become part of TinkerPop once the GLV gets accepted. This approach would avoid the need to implement a new driver just for the GLV. And I just wanted to know what the requirements or TinkerPop standards / guidelines are, so we can evaluate whether an existing driver conforms to them or at least doesn't require too much work.
Yeah, I noticed that there is still much discussion going on around the topic of testing GLVs. That is also why I put my efforts on hold regarding a C# GLV. > Those tests should produce xunit style output unless there is some good > reason not to. Xunit is basically the default testing tool for .NET Core (it is even used by Microsoft instead of their own MsTest). So, that shouldn't be a problem. >4. The build/deploy process needs to be bound to maven which might be one of >the trickier bits to deal with. I am really not a maven expert, but at least for C# this should be possible to do with .NET Core which is more or less supported by Travis-CI (in "stealth mode" only at the moment): https://github.com/travis-ci/travis-ci/issues/5189 Maven would just have to execute some powershell / bash script that performs the .NET Core build and deployment. -----Ursprüngliche Nachricht----- Von: Stephen Mallette [mailto:[email protected]] Gesendet: Montag, 14. November 2016 17:10 An: [email protected] Betreff: Re: GLV - Languages with no JVM support > 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/ccdb01c5bef7f1d25d86bcb563fc4 > a 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 > > > > > > > > > > > > > > > > > > > > > > > >
