> How can difference in client and server JVM compiler versions affect
bytecode evaluation by a server?
JVM versions won't matter. Gremlin bytecode is evaluated by Gremlin so, if
there were versioning issues they would be specific to TinkerPop
versioning. A client on TinkerPop 3.2.5 sending byteco
I love the idea, but here are my concerns:
How can difference in client and server JVM compiler versions affect
bytecode evaluation by a server? What if client was compiled with newer
compiler, and the server does not recognize the version of bytecode sent by
the client? I would assume it will f
Your assumptions are correct but i'll add some slight modifications and
there is one other possibility to consider:
REST: ScriptEngine
Client.submit(String): ScriptEngine
Client.submit(Traversal): Java
Client.submit(Bytecode): Java
traversal().withRemote(DriverRemoteConnection): Java
Client.submi
It would be good to understand when each is used. My assumptions:
REST: Groovy
Client.submit(String): Groovy
Client.submit(Traversal): Java
Client.submit(Bytecode): Java
traversal().withRemote(DriverRemoteConnection): Java
??
On Wed, Sep 28, 2016 at 10:55 AM, Marko Rodriguez wrote:
> Hello,
>
Hello,
Gremlin bytecode provides a language agnostic way of sending Gremlin traversals
between machines — whether physical or virtual. For instance, it is possible to
send bytecode from one JVM to another or from CPython to the JVM across the
network. Once bytecode is received, it needs to be t
