Added TINKERPOP-1417 to the future dev doc CTR


Branch: refs/heads/TINKERPOP-1777
Commit: fb8facfd35adf5cb18fd761d7610e455a9bbfea3
Parents: e56823b
Author: Stephen Mallette <>
Authored: Thu Mar 1 18:24:30 2018 -0500
Committer: Stephen Mallette <>
Committed: Thu Mar 1 18:24:30 2018 -0500

 docs/src/dev/future/index.asciidoc | 27 ++++++++++++++++++++++++++-
 1 file changed, 26 insertions(+), 1 deletion(-)
diff --git a/docs/src/dev/future/index.asciidoc 
index 63900e8..5e86ecf 100644
--- a/docs/src/dev/future/index.asciidoc
+++ b/docs/src/dev/future/index.asciidoc
@@ -49,7 +49,6 @@ These items include:
 ** The role of Blueprints should be significantly reduced.
 ** The role of Gremlin should be significantly increased.
 == Hiding Blueprints
 Originally from the 
@@ -118,3 +117,29 @@ now is rooted in the Neo4j approach to transactions and is 
often more trouble th
 Distributed transactions are a challenge and don't apply to every provider. 
Transactions are further complicated by
 GLVs. The idea of local subgraphs for mutations and transaction management 
might be good but that goes against having
 just `ReferenceGraph`.
+== Gremlin Language Subset
+On link:[TINKERPOP-1417], 
it was suggested that we "Create a
+Gremlin language subset that is easy to implement on any VM". Implementing the 
Gremlin VM in another language is
+pretty straightforward. However, its a lot of code.. all these steps 
implementations. One thing we could do to make
+it easy for database providers not on the JVM (e.g. ArangoDB and C) is to 
create "Gremlito" (Gremlin--). This language
+subset wouldn't support side-effects, sacks, match, etc. Basically, just 
simple traversal steps and reducing barrier
+* out, in, both, values, outE, inV, id, label, etc.
+* repeat
+* select, project
+* where, has, limit, range, is, dedup
+* path, simplePath, cyclicPath
+* groupCount, sum, group, count, max, min, etc. (reducing barriers)
+=== Comments
+This has an interesting potential impact on GLVs because "Little Gremlin" 
could be implemented within them for
+client-side traversals over remote subgraphs, where the subgraph is like a 
remote transaction. All graph mutations
+essentially build a subgraph which is merged into the primary graph. That 
subgraph is effectively the "transaction".
+Build it locally then submit it remotely and have the server sort out the 
merging. It's perhaps the most natural way
+to load data. With "Gremlinito" you then get the added power of being able to 
traverse a local subgraph.
\ No newline at end of file

Reply via email to