[
https://issues.apache.org/jira/browse/TINKERPOP-1277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stephen mallette closed TINKERPOP-1277.
---------------------------------------
Resolution: Won't Do
Closing all the tutorial ideas - if we want to come back to these at some point
then we can re-open them.
> Write a Gremlin traversal machine variant tutorial
> --------------------------------------------------
>
> Key: TINKERPOP-1277
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1277
> Project: TinkerPop
> Issue Type: Improvement
> Components: documentation
> Affects Versions: 3.2.0-incubating, 3.1.2-incubating
> Reporter: Marko A. Rodriguez
> Priority: Major
>
> We have discussed "Gremlin language variants" which teach people how to embed
> Gremlin in non-JVM languages (e.g. Python, Ruby, PHP, etc.). Developers in
> these non-JVM languages can then communicate with JVM-based Gremlin via
> GremlinServer. This all assumes that the ultimate graph system (OLTP or OLAP)
> is JVM-based. How about when a graph system isn't on the JVM and the graph
> system designers want to use Gremlin as their query language?
> Like building a Gremlin language variant, building a Gremlin machine variant
> is not too difficult. The Gremlin traversal machine is relatively simple with
> only a few constructs needed -- traversals, traversers, steps, bulking. Its
> all pretty straightforward.
> I think it would be smart to demonstrate how to build the Gremlin machine in
> another language. Perhaps in a "high performance" language like C or C# or
> ...?. (Or perhaps just do it in like Ruby as its easy for people to build and
> run the code without having to do {{gcc make}}-crap) The tutorial does not
> need to go into all step implementations, but perhaps a few that demonstrate
> a filter, flatmap, map, sideEffect, branch -- as well as ones that take
> {{by()}}-modulators and {{TraversalParents}}. We would need to create a
> "TinkerGraph" in that language as well so that the implemented machine would
> work for it. Finally, to complete the picture, Apache TinkerPop's
> Gremlin-Java should be used to communicate with the non-JVM machine via a
> {{RemoteConnection}}! Classy.
> This would complete the "Gremlin as a standard"-push. Not only can it be
> embedded in a host language (non JVM), but its machine can be implemented in
> another language as well. Thus, Gremlin is not just a JVM construct. Though
> Apache TinkerPop would stick to only supporting a JVM implementation of the
> Gremlin traversal machine.
> NOTES:
> * Unlike creating a Gremlin language variant, its hard to programmatically
> create a Gremlin machine variant. However, if the Gremlin machine variant
> supported {{RemoteConnection}}, then we could use Gremlin-Java's
> {{ProcessXXXTest}} as a way to verify that the machine variant is compliant.
> * Supporting OLAP is not that difficult either. A naïve implementation of
> {{TraversalVertexProgram}} is only, maybe 100 lines of code. The more
> complicated part is the "TinkerGraphComputer"-implementation in the other
> language.
> * The specification articulated in http://arxiv.org/abs/1508.03843 is what we
> should go by as its mathematically clean. We should not just try and map over
> the concepts 1-to-1 from Apache TinkerPop's Gremlin traversal machine.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
