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/>