As discussed on dev@...
Apache TinkerPop should provide, out-of-the-box, at least 3 Gremlin language variants. It would be cool if these were:
I think each of these should be generated using the reflection-model presented in http://tinkerpop.apache.org/docs/3.2.1-SNAPSHOT/tutorials/gremlin-language-variants/. Moreover, on every mvn clean install, the code for these variants is generated.
Given the desire to separate language variants from language drivers, I think that a language driver for each variant above should be "plugable." Moreover, we should provide one driver implementation for each – simple GremlinServer REST.
Next, each variant implementation should be testable. This is PAINFUL if we have to implement each g_V_out_repeatXasXaXX test case in ProcessXXXSuite. Perhaps some RegEx transducer magic could be used to convert all those tests from Gremlin-Java to the respective host language? However, even if we do that, we still have the problem of how to test the returned results.
I think what we should test the returned results using the JVM. For instance, JRuby, Jython, JPHP (does it exist?). If we do this, we will save ourselves a massive headache. All we have to do is create a GraphProvider that uses TinkerGraph and whose TraversalSource is some sort of wrapper around reflection-generated Ruby (e.g.).
That Ruby iterator should be converted to a Java iterator and then the ProcessXXXSuite can verify the results.
With this, most everything is reflectively constructed.
Thus, the testing data flow would be: