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
