Hi Florian, I've started this thread to understand if the TinkerPop repo is the best place for a C# GLV, now that I understand that the answer is yes, I've created a JIRA ticket to discuss the C# GLV specifically: https://issues.apache.org/jira/browse/TINKERPOP-1552
I'm mainly focused on having a well defined C# GLV API and serialization, but we should also include a Gremlin Server driver. I'm interested in any kind of collaboration: via code / reviews / improvements / ... Thanks, Jorge On Mon, Nov 14, 2016 at 5:44 PM, Florian Hockmann <f...@florian-hockmann.de> wrote: > 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:spmalle...@gmail.com] > Gesendet: Montag, 14. November 2016 17:10 > An: dev@tinkerpop.apache.org > 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 <f...@florian-hockmann.de > > > 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:spmalle...@gmail.com] > > Gesendet: Montag, 14. November 2016 13:36 > > An: dev@tinkerpop.apache.org > > 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 > > <f...@florian-hockmann.de> > > 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:jorgebaygon...@gmail.com] > > > Gesendet: Montag, 14. November 2016 09:51 > > > An: dev@tinkerpop.apache.org > > > 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 > > > <spmalle...@gmail.com> > > > 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 < > > > > jorge.gon...@datastax.com > > > > > 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 > > > > > <spmalle...@gmail.com> > > > > > 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 < > > > > > > jorge.gon...@datastax.com > > > > > > > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
