Hello,
I think TinkerPop has too many ways of doing things. For instance:
1. Users can use graph traversal or interact with vertex/edge/etc. Java
objects directly.
2. Users can interact with the graph system embedded (via the Graph
object) or remotely (via RemoteConnection).
3. Users can submit Gremlin string scripts or submit Gremlin bytecode
to GremlinServer (along with other REST/etc. type capabilities possible).
4. Users can use GraphML, GraphSON, or Gryo for serialization.
5. Users can use Gremlin-Groovy, Gremlin-Java, Gremlin-Python,
Gremlin-Scala, etc.
6. Users can use Titan, Neo4j, OrientDB, etc.
I think we should create a module called gremlin-x/ which is the most
simplified, concise, recommended way to use TinkerPop. In correspondence to the
itemization above:
1. Users can only use graph traversal. All returned elements are
ReferenceElements.
2. Users can only interact with the graph remotely (where remote may
just be a localhost connection — in-memory proxy (e.g. for TinkerGraph)).
3. Users can only submit Gremlin bytecode to GremlinServer (thus, only
RemoteConnection can be used). No more security issues, no more uninterruptible
scripts, etc.
4. Users can only use GraphSON as its language agnostic.
5. Users can use any Gremlin language variant as long is generates
Gremlin bytecode.
6. Users can use any graph system provider as long as it has a
RemoteConnection exposed (where the provider can simply leverage GremlinServer).
Finally, we should create a separate documentation called gremlin-x.asciidoc
which is small and discusses the rationale for the constrained specification
and references the core reference docs accordingly. For instance, no need to
have all the step examples re-written.
I believe that this will make it easier for users to say the following:
“Okay, I get it. Open a RemoteConnection from a GraphTraversalSource
(g.withRemote(...)) and spawn traversals and get back results. Thats it?! Easy
peasy lemon squeezy.”
I believe that this will make it easier for system developers to say the
following:
“We can cover 95% of use cases by simply exposing a RemoteConnection.
Thats it?! Easy peasy lemon squeezy."
In general, this model looks at TinkerPop as a “remote database system” where
users submit “queries” and get back “results.” That is it. Nothing
Java-specific, nothing with executing arbitrary scripts remotely, nothing with
REST, nothing with embedded (at least from a look-and-feel perspective), etc.
Thoughts?,
Marko.
http://markorodriguez.com
