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
> On Jun 16, 2016, at 10:37 AM, Marko Rodriguez <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
>
>
>
>> 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
>>>
>
