Hi,
The parallel Josh/Marko/Pieter thread got me thinking… So, given
ComplexType
Iterator<T> siblings(String label)
Iterator<T> children(String label)
…lets see how both structure and processor providers can influence each other
within the TP4 VM.
Lets take JanusGraph as the example structure.
JanusVertex implements ComplexType
Lets take Akka as the example processor. AkkaProcessor can document:
“If you want query routing functionality for your ComplexTypes, provide
an akka:location child reference.”
The JanusGraph team plans to provide AkkaProcessor support so they do as asked.
janusVertex.children(“akka:location”) => 127.0.2.2
This is the physical location of the vertex in JanusGraph’s underlying
Cassandra/HBase/etc. cluster. Now, an AkkaProviderStrategy can do the following:
g.V().has(’name’,’marko’).out(‘knows’).asMap()
==strategizesTo==>
g.V().has(’name’,’marko’).out(‘knows’).akka:route().asMap()
akka:route() is a provider-specific instruction that will look at the incoming
object, check to see if it has an akka:location child reference, if it does, it
will teleport the traverser to that machine for the final asMap() execution.
(i.e. data local query routing). Why pull a bunch of map data over the wire
when you can send the traverser to the hosting machine and populate the map
there.
——
We have always talked about providers being able to have custom instructions
(inserted via provider-specific strategies). What we haven’t discussed and what
I bring up here is the idea that providers can require/recommend/etc. that data
providers use certain reference types that they can capitalize on.
Thus, providers interact with other providers within the TP4 VM via:
1. Custom bytecode instructions (process interaction).
2. Custom type references (structure interaction).
Bye,
Marko.
http://rredux.com <http://rredux.com/>
