tinkerpop-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen Mallette <spmalle...@gmail.com>
Subject Re: [DISCUSS] The Two Protocols of TP4
Date Tue, 16 Apr 2019 16:09:43 GMT
sorry - i don't follow the nature of the vm communication protocol:

        1. Register bytecode —returns—> bytecode.
        2. Submit bytecode —returns—> iterator of traversers.
        3. Unregister bytecode source —returns—> void

i get the "submit" part but could you explain the "register" and
"unregister" parts (referenced in another post somewhere perhaps)?

regarding this:

>  just like processing instructions are extended via namespaced
instructions and strategies, so are server instructions

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.


On Mon, Apr 15, 2019 at 2:44 PM Marko Rodriguez <okrammarko@gmail.com>
wrote:

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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message