Hello,
> I think this does satisfy your requirements, though I don't think I
> understand all aspects the approach, especially the need for
> TinkerPop-specific types *for basic scalar values* like booleans, strings,
> and numbers. Since we are committed to the native data types supported by
> the
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 trav
Hello Stephen,
> I'd also wonder about how we treat subgraph() and tree()? could those be a
> List somehow??
Yes, Tree is List. Subgraph….h….shooting from the hip: you don’t get
back a graph, its stored in:
g.withProcessor(TinkerGraphStructure.class, config1)
That is, the subgraph is writt
Hi Marko,
I think this does satisfy your requirements, though I don't think I
understand all aspects the approach, especially the need for
TinkerPop-specific types *for basic scalar values* like booleans, strings,
and numbers. Since we are committed to the native data types supported by
the JVM, I
I think that TinkerPop specific types are good and the extension model
sounds reasonable. It sounds like it will blend right into the GraphBinary
serialization model that we have though I wonder what happens when you
start blending together different graphs and serialization extensions and
what typ
Hello,
I have a consolidated approach to handling data structures in TP4. I would
appreciate any feedback you many have.
1. Every object processed by TinkerPop has a TinkerPop-specific type.
- TLong, TInteger, TString, TMap, TVertex, TEdge, TPath, TList,
…
