The diagram is excellent. Nice to see that we have the separate modules approach in place for each GLV - very nice direction.
I like this idea: > 1. bin/gremlin.sh —language gremlin-python it would be nice to have a universal gremlin console though it may mean a departure from the dependence on groovysh to do so. I'd have to think about that one - it might not be as easy as just "swapping out the scriptengine". On Wed, Jun 22, 2016 at 4:56 PM, Marko Rodriguez <okramma...@gmail.com> wrote: > Hello, > > I created gremlin-python/ package and killed gremlin-variant/ package. > Thus, the links I provided in the email earlier this morning are busted. > You can move around from here to re-find the references. > > https://github.com/apache/tinkerpop/tree/TINKERPOP-1278/gremlin-python/src/main > < > https://github.com/apache/tinkerpop/tree/TINKERPOP-1278/gremlin-python/src/main > > > > Thanks, > Marko. > > http://markorodriguez.com > > > > > On Jun 22, 2016, at 7:36 AM, Marko Rodriguez <okramma...@gmail.com> > wrote: > > > > Hello, > > > > I have been working on TINKERPOP-1278 for a couple of weeks now and here > is where my thoughts are going. > > > > First, a review of the concepts. > > > > 1. Apache TinkerPop is a JVM-based graph computing framework. > > 2. Gremlin can be embedded/represented in any programming language > that supports function composition and function nesting. > > - Every programming language supports these two constructs. > > 3. There are two ways in which XXX language can work with Apache > TinkerPop. > > a.) XXXScriptEngine can directly use TinkerPop classes. > > b.) XXX “mocks” of TinkerPop’s Traversal and > RemoteConnection in the respective language. > > 4. The language that is representing/hosting Gremlin is called the > “source language.” > > 5. The language that the Gremlin traversal will ultimately be > executed on in the JVM is called the “target language.” > > 6. It is the responsibility of a Translator to translate the > source language into the target language. > > > https://github.com/apache/tinkerpop/blob/TINKERPOP-1278/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/process/traversal/util/Translator.java > < > https://github.com/apache/tinkerpop/blob/TINKERPOP-1278/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/process/traversal/util/Translator.java > > > > - getAlias() is function naming. > > - addStep(), addSpawnStep(), addSource() is > function composition. > > - getAnonymousTraversalTranslator() is function > nesting. > > - getSourceLanguage() and getTargetLanguage() is > translator metadata. > > 7. It is possible/reasonable for both source and target languages > to be on the JVM. > > - For example, Gremlin-Java translating to Gremlin-Groovy > so it can avoid the complications of serialization and support remote > lambda execution. > > > https://github.com/apache/tinkerpop/blob/TINKERPOP-1278/gremlin-groovy/src/main/java/org/apache/tinkerpop/gremlin/groovy/GroovyTranslator.java#L58-L66 > < > https://github.com/apache/tinkerpop/blob/TINKERPOP-1278/gremlin-groovy/src/main/java/org/apache/tinkerpop/gremlin/groovy/GroovyTranslator.java#L58-L66 > > > > > > From this foundation, we should work towards the following: > > > > 1. bin/gremlin.sh —language gremlin-python > > - this will load up a GremlinConsole where a > GremlinJythonScriptEngine is used to read and return results. > > - same gremlin> and ==> look-and-feel, but now its Python, > not Groovy that is the scripting language. > > - In this way, Python people can work with TinkerPop and > NEVER leave Python. > > 2. Moving forward, we then have gremlin-jruby and respective > GremlinJRubyScriptEngine. > > - In this way, Ruby people can work with TinkerPop and > NEVER leave Ruby. > > 3. Unlike Groovy, Python and Ruby have representations outside of > the JVM and thus, need VM agnostic code (i.e. they can’t just “new > GraphTraversal”). > > - PythonGraphTraversal (which is NOT just GraphTraversal > used by Gremlin-Jython on the JVM). > > > https://github.com/apache/tinkerpop/blob/TINKERPOP-1278/gremlin-variant/src/main/jython/gremlin_python/gremlin_python.py > < > https://github.com/apache/tinkerpop/blob/TINKERPOP-1278/gremlin-variant/src/main/jython/gremlin_python/gremlin_python.py > > > > - It is simple to auto generate XXX > language “mocks” using reflection. > > > https://github.com/apache/tinkerpop/blob/TINKERPOP-1278/gremlin-variant/src/main/groovy/org/apache/tinkerpop/gremlin/python/GremlinPythonGenerator.groovy > < > https://github.com/apache/tinkerpop/blob/TINKERPOP-1278/gremlin-variant/src/main/groovy/org/apache/tinkerpop/gremlin/python/GremlinPythonGenerator.groovy > > > > - Translators allow for the translation of XXX language > traversals to YYY language traversals on the JVM for execution by TinkerPop. > > > https://github.com/apache/tinkerpop/blob/TINKERPOP-1278/gremlin-variant/src/main/jython/gremlin_python/groovy_translator.py > < > https://github.com/apache/tinkerpop/blob/TINKERPOP-1278/gremlin-variant/src/main/jython/gremlin_python/groovy_translator.py > > > > When GremlinJythonScriptEngine exists, we should > have a JythonTranslator as it will natively support lambdas. > > - gremlin_driver, gremlin_rest_driver, etc. which are the > Python specific replications of the same classes used in JVM TinkerPop. > > > https://github.com/apache/tinkerpop/blob/TINKERPOP-1278/gremlin-variant/src/main/jython/gremlin_driver/gremlin_driver.py > < > https://github.com/apache/tinkerpop/blob/TINKERPOP-1278/gremlin-variant/src/main/jython/gremlin_driver/gremlin_driver.py > > > > > https://github.com/apache/tinkerpop/blob/TINKERPOP-1278/gremlin-variant/src/main/jython/gremlin_rest_driver/gremlin_rest_driver.py > < > https://github.com/apache/tinkerpop/blob/TINKERPOP-1278/gremlin-variant/src/main/jython/gremlin_rest_driver/gremlin_rest_driver.py > > > > 4. All Gremlin language variants distributed by Apache TinkerPop > should have their own package. > > - gremlin-groovy > > - gremlin-jython (with gremlin-python representation in it) > > - gremlin-jruby (with gremlin-ruby representation in it) > > - gremlin-rhino (with gremlin-js representation in it) > > - gremlin-renjin (with gremlin-r representation in it) [ > http://www.renjin.org/ <http://www.renjin.org/> cool!] > > - etc. > > > > Thoughts?, > > Marko. > > > > http://markorodriguez.com <http://markorodriguez.com/> > > > > > > > >> On Jun 16, 2016, at 10:37 AM, Marko Rodriguez <okramma...@gmail.com > <mailto:okramma...@gmail.com>> wrote: > >> > >> Yea — submodules is a good idea. > >> > >> Also, I think we should create gremlin-jython, gremlin-ruby, etc. > ScriptEngines that have all the imports loaded and ready to go much like we > have with gremlin-groovy. > >> > >> Marko. > >> > >> http://markorodriguez.com <http://markorodriguez.com/> > >> > >> > >> > >>> On Jun 16, 2016, at 10:19 AM, Stephen Mallette <spmalle...@gmail.com> > wrote: > >>> > >>> I would think that we want individual plugins for each variant. > >>> > >>> This does lead me back to an earlier discussion about gremlin-variant > >>> packaging. We didn't want to do > >>> > >>> gremlin-variant > >>> +-- gremlin-variant-python > >>> +-- gremlin-variant-js, > >>> +-- .... > >>> +-- gremlin-variant-XXXXX > >>> > >>> so with gremlin-variant users are going to just get everything when > they > >>> depend on it. To my knowledge, we are only kinda viewing this from a > python > >>> perspective atm and haven't really researched all the languages we > support, > >>> but I sense that ultimately as we add more GLVs we're going to end up > with > >>> a really messy pom.xml for gremlin-variant with the potential for > conflict > >>> as we try to make maven deal with packaging issues for all those > disparate > >>> languages. Again, hard to say how much trouble this will eventually > be, but > >>> might be worth noodling on again in case anyone has any new thoughts > on the > >>> matter. > >>> > >>> > >>> > >>> On Thu, Jun 16, 2016 at 12:10 PM, Daniel Kuppitz <m...@gremlin.guru> > wrote: > >>> > >>>> The last few days I've been working on a Gremlin Python code executor > for > >>>> the TinkerPop docs. What I noticed was that we can't simply execute > Gremlin > >>>> Python code in our Gremlin Groovy console, simply because the console > has > >>>> no dependency to the gremlin-variants projects. > >>>> > >>>> That was unfortunate for the docs pre-processor, but what about the > normal > >>>> user? Do we need to have those language variants always available or > would > >>>> it be sufficient to have a Gremlin-Xyz plugin (where Xyz could be > Python, > >>>> Ruby, etc.)? > >>>> > >>>> I've added the "missing" dependency for now to get the docs > pre-processor > >>>> extension done, but I think we should remove that dependency again and > >>>> create a plugin instead, before the branch gets merged into master. > >>>> > >>>> Cheers, > >>>> Daniel > >>>> > >> > > > >
