I've done a fair bit of work trying to generalize Gremlin-enabled ScriptEngines so that we have a common way to configure any additional ones we may add. Unfortunately, I think I've exhausted what I can do there without introducing significant breaking change. The easiest way to explain where I've reached an impasse is to say that to this point gremlin-groovy has held most of the code related to "ScriptEngines" in TinkerPop going back to 1.x and now, much of that infrastructure needs to live in gremlin-core so that it can be easily shared with gremlin-groovy, gremlin-python, gremlin-whatever, etc. I can't move those things easily without breaking many many many things.
On a positive note however, I don't think that this is a big problem for TINKERPOP-1278. I'm going to switch gears a bit and focus on the changes required to Gremlin Server to better support GLVs. I think that with the work I've already done and the work Marko has done we can have something that remains fully functional but will need a lot of clean-up going forward. So for 3.2.2 we can have gremlin-python working and the pattern for GLV implementation in good shape with the expectation that for 3.3.0 we will get it 100% solid all around (as with 3.3.x we will have some room to maneuver as we expect some breaking change to occur in that line of code). This post is sorta high-level, so if anyone is interested in more details, please ask. On Wed, Jul 13, 2016 at 11:24 AM, Marko Rodriguez <[email protected]> wrote: > Hi, > > TINKERPOP-1278 represents the evolution of Gremlin in that Gremlin can be > (easily) embedded in any host language and can be (easily) compiled in said > host language to a standard Bytecode representation. That Bytecode can then > be shipped to a RemoteConnection-based server (e.g. GremlinServer) to be > processed and have results streamed back. That is, for instance, Python > developers can natively write Gremlin and get results back from a remote > GremlinVM (e.g. Apache TinkerPop’s Java-based Gremlin VM). > > https://gist.github.com/okram/b95d4b37af625435620aa078b2746e8a < > https://gist.github.com/okram/b95d4b37af625435620aa078b2746e8a> > > Here is what I believe we have left to accomplish on TINKERPOP-1278. I’ve > added people’s names next to the tasks based on who has been working in > these areas. If others are interested in helping out, please feel free to > jump in accordingly. > > * Finalize GraphSON2.0 [Stephen, Robert, Kevin, Dylan] > * New RemoteConnection protocol (GraphSON2.0-based supporting Traversers > (bulking) and SideEffects) [Stephen] > - XXXServer agnostic -- GremlinServer, Neo4jServer, > ArangoDBServer, etc. implementable. > * GremlinScriptEngine infrastructure for testing. [Stephen] > * Write documentation on new RemoteConnection protocol (published > specification). [Stephen] > * Bytecode serialization specification in GraphSON2.0 [Marko] > - Gremlin-XXX agnostic (save lambdas) -- Gremlin-Java, > Gremlin-Groovy, Gremlin-Python. > * Implement new RemoteConnection protocol in Python. [Marko, Dave, > Leifur] > * Refactor Gremlin-Python test infrastructure in Stephen's new > GremlinScriptEngine test framework. [Marko] > * Write documentation on Bytecode format (published specification). > [Marko] > > NOTE: If you are unsure what some of this means, please ask and I can > describe in more detail each of these items. > > As you can see, TINKERPOP-1278 is heavily dependent on GraphSON2.0 being > defined and merged so that should take top priority. We have a nice thread > going on this and we should try and converge on it. > > Finally. I was texting with Stephen and asking him about how long it would > take him to do X,Y,Z and it seems that together, we should shoot for August > 20th to have a PR for this work for review/VOTE and ultimate merge to > master/. > > Thoughts?, > Marko. > > http://markorodriguez.com > > > >
