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/ccdb01c5bef7f1d25d86bcb563fc4a59cb3b59e0/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 > > > > > > > > > > > > > > > >
