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