Nice post, I'm going to jump straight to the end. I think that one of the problems of doing an abstraction similar to remoteGraph is that in reality the overhead of communicating with the server is too big to make this viable. It's imperative that you have the ability to group multiline scripts into a single query or the reactivity of your applications will greatly suffer.
The Gremlin-java base also has a few limitations that some query builders try to fix (which can only be done if you abandon the idea of a natural gremlin language variant in favor of a query builder). Namely having the ability to edit/modify/add steps to an already defined traversal. Though in time it might be nice to have these be part of the original implementation. I personally love the idea of gremlin language variants. I just don't think they're production value is any good without some extended functionality (beyond what gremlin-java currently is). On Wed, Apr 20, 2016 at 3:23 PM, Stephen Mallette <spmalle...@gmail.com> wrote: > This thread on Gremlin Language Variants has been very interesting: > > https://pony-poc.apache.org/thread.html/Zcazrw7k442xcwc > > I think that this work goes a long way to address two issues I've been > concerned about: > > 1. Greater consistency in how different languages do Gremlin > 2. Less fragmentation in terms of libraries and how they work so that users > aren't confused with how to get started (though I don't think the goal here > is to restrict choices or slow down innovation) > > One of the first things we should probably do is start thinking in terms of > the types of libraries that are built on TinkerPop (outside of those things > that are Graph Systems) and those are listed here currently: > > http://tinkerpop.apache.org/#graph-libraries > > Marko mentioned to me that he saw the libraries we listed here breaking > into three categories: > > 1. Gremlin Language Variants - which the other thread demonstrates quite > nicely > 2. Gremlin Drivers - the Gremlin Server protocol implementations - those > things that send traversals to Gremlin Server and get back results. > 3. OGM and others - I say "others" because there might be plugins and other > similar odds and ends > > I like Marko's category system here and I think that having these kinds of > categories will help folks organize their libraries to fit into one of > these spaces and make it easier for users to know what they need to get in > order to start doing TinkerPop in their language. > > Anyway, the category thing is just setting the stage for this big > bombshell. I think TinkerPop should consider maintaining the Gremlin > Language Variants. > > Heresy! right? > > Well, I think it's the best way to achieve consistency across languages. > Under this model, TinkerPop provides the base language variant and people > can choose to extend upon it, but the base stays tied to our archetype of > Java and we end up with a much more clear story for virtually any > programming language. > > So how do we do this? Slowly and deliberately. We should look to only > include language variants where we: > > + have good automation in place (like what Marko did for Python), > + some competence on the committer list in that language > + a nice testing framework that operates in our standard build/release > process. > > That's setting a high bar, but if we don't keep it high, I think we will be > left unable to properly support and maintain what we hang out there. > > I'd also like to express that we should not be looking to maintain language > drivers. I think that should remain a third-party community effort just > like Graph Systems. In other words, we remain a repository for reference > implementations for everything else. Why? Because, as it sits right now, > just based on the level of effort for what Marko did with Python, > maintaining a "base" Gremlin Language Variants shouldn't be hard. We won't > be building tons of add-on capabilities to the base variants - they will > pretty much just stay on par with the java archetype. Drivers on the other > hand have lots of implementation details, with many different technologies > that could be used, etc. They have similar complexity to Graph System > implementations in many ways. I also think that the drivers can afford to > have different APIs and approaches without being detrimental to the > community. > > If gremlin-js-driver wants to do: > > client.submit("g.V()") > > and gremlin-python-driver wants to do: > > client.send("g.V()") > > that's not a big deal. > > The last point that I'll make is that I think Gremlin Language Variants, > that don't operate on the JVM (e.g. Jython) and use Gremlin Server, should > have some abstraction that is similar to RemoteGraph. RemoteGraph exposes > a DriverConnection interface that is currently implemented by > gremlin-driver. The DriverConnection is responsible for sending a > traversal to the server and returning results. It would be nice if the > language variants had a similar interface that the various community > drivers could implement. In that way, the user never has to do any form of: > > client.submit(someGremlinString) > > in any language. We really need to try to make that pattern go away across > the TinkerPop community. > > So - that's was a long email. Looking forward to hearing some discussion on > this. > > Stephen >
