Hello,
I believe there will only be two protocols in TP4.
1. The VM communication protocol. (Rexster)
2. The data serialization protocol. (Frames)
[VM COMMUNICATION PROTOCOL]
1. Register bytecode —returns—> bytecode.
2. Submit bytecode —returns—> iterator of traversers.
3. Unregister bytecode source —returns—> void
Here is a trippy idea. These operations are simply bytecode.
1. [[register,[bytecode]]] —returns—> single traverser referencing
bytecode.
2. [[submit, [bytecode]]] —returns—> many traversers referencing
primitives.
3. [[unregister, [bytecode]]] —returns —> no traversers.
Thus, THE ONLY THING YOU SEND TO THE TP4 VM IS BYTECODE and THE ONLY THING
RETURNED IS ZERO OR MORE TRAVERSERS!
Now, think about JanusGraph. It has database operations such as create index,
create schema, drop graph, etc. These are just custom instructions in the
bytecode of submit.
[[submit, [[jg:createIndex,people-idx,person]]]
A JaunusGraph strategy will know what to do with that instruction and a
traverser can be returned. Traverser.of(“SUCCESS”). And there you have, just
like processing instructions are extended via namespaced instructions and
strategies, so are server instructions. Providers have an extensible framework
to support all their custom operations because, in the end, its just bytecode,
strategies, and resultant traversers! (everything is the same).
Next, in order to send bytecode and get back traversers ‘over the wire', there
needs to be a serialization specification.
[DATA SERIALIZATION PROTOCOL]
1. I don’t know much about GraphBinary, but I believe its this without
complex types.
- Why?
- bytecode is primitive.
- traversers are primitive (as they can’t reference
complex types — see other [DISCUSS] from today).
Thoughts?,
Marko.
http://rredux.com <http://rredux.com/>
