Hi, > i was thinking that an extensible bytecode model would be the solution for > these kinds of things. without the scriptengine anymore (stoked to see that > go away) graph providers with schema languages and other admin functions > will need something to replace that. what's neat about that option is that > such features would no longer need to be bound to just the JVM. Python > users could use the JanusGraph clean utility to drop a database or use > javscript to create a graph in DSE Graph. pretty cool.
Exactly! However, lets say some provider decides they want to support ScriptEngine. [[submit, [ex:script, gremlin-groovy, g.V.out.name]]] As you note, extensible bytecode will make it so that seemingly disparate operations all use the same “bytecode protocol” pattern. And you just made me realize the benefit of that for all the language drivers. Not only is our serialization protocol going to be dead simple (always primitives), but also our communication protocol (always bytecode->traversers) as well. Gremlin-Brainfuck might just be a reality! [https://en.wikipedia.org/wiki/Brainfuck <https://en.wikipedia.org/wiki/Brainfuck>] - processor execution - database operations - server status inquiry - HDFS file system management - ... For the last one: [[submit, [hadoop:hdfs, head -10 /data.txt]]] That returns Iterator<Traverser<String>>. Its as if Strategies are like “server plugins.” If you make namespaced instructions with a corresponding Strategy that can handle those instructions, then you are basically communicating with a “plugin” server-side RPC-style. Skys the limit, Marko. http://rredux.com
