Hi All,
Today, GremlinLang builds a Gremlin string with parameter placeholders
(e.g., g.V(_0)) and a separate parameter map. The Java GLV puts both into a
RequestMessage, where the Gremlin travels as text but the parameters are
Map<String, Object> so they are binary-serialized via GraphBinary. This
couples Gremlin language evolution to GraphBinary versioning. Every new
request-side type requires a GraphBinary change, which is technically
breaking and forces a major version bump across the entire ecosystem. I'm
proposing that we represent the parameter map as a gremlin-lang map literal
string rather than binary-serializing it. The request becomes entirely
text-based. GraphBinary is only used for response serialization.
The gremlin string keeps its parameter placeholders (g.V(x)) for
cache-friendliness and code/data separation. The parameter values are
expressed as gremlin-lang literals in a string like ["x":1,"name":"abc"].
The server parses this string through the existing grammar to resolve
parameter values. A consequence of this is that all parameter strings must
be gremlin-lang parseable. There are some gremlin-groovy specific bindings
that won't work anymore since they start with invalid strings like
"#jsr223...".
The bindings field (soon to be renamed to parameters) in the HTTP request
body changes from a binary-serialized map (or JSON object) to a
gremlin-lang map literal string. For example, what was "bindings": {"x": 1}
becomes "bindings": "[\"x\":1]". This is a breaking wire format change that
will be done in TinkerPop 4.0 (where the format has already been changed).
I was initially worried this might cause some performance regressions but
after some testing I don't think there is any issue. String encoding is
larger than binary for some types, but deflate/compression on the text
payload is competitive with raw GraphBinary size (it's actually even better
in many cases). There is a parse overhead on the server to convert
parameter strings back to Map but even with larger maps that have thousands
of entries, the ANTLR parser can still parse a minimum of 50000/sec which
means it probably won't be a performance bottleneck.
Any thoughts or concerns?
Thanks,
Ken
