We need:
Graph
Element
Vertex
Edge
VertexProperty
Property
Path
TraversalExplanation
TraversalMetrics
Traversal (i.e. Bytecode)
Traverser (object + bulk at minimum)
Marko.
http://markorodriguez.com
> On Jul 19, 2016, at 12:45 PM, Robert Dale <robd...@gmail.com> wrote:
>
> There's also Path that can be returned from a query. It looks like
> GraphSON 1.0 handles this today in the REST API but it's not typed as
> a path.
>
> On Tue, Jul 19, 2016 at 2:14 PM, gallardo.kev...@gmail.com
> <gallardo.kev...@gmail.com> wrote:
>>
>>
>> On 2016-07-19 18:02 (+0100), Robert Dale <robd...@gmail.com> wrote:
>>> - It seems redundant to nest a vertex or edge inside a type-value
>>> object and is inconsistent with a VertexProperty.
>>> - VertexProperty and (edge) Property are implicit types. I don't know
>>> if this is ok. Could they ever be used outside of their parents where
>>> they would need to be typed?
>>
>> I agree with the VertexProperty remark. That's one last question I wanted to
>> solve, if we go for typing Vertex and edges, do we include others? The full
>> list I see then is : vertex/edge/vertexproperty/property/graph.
>>
>> However I am not sure how useful it is to have more than Vertex and Edge.
>> As, when deserializing a Vertex for example, there's no question as to what
>> is in the "properties" field of the Vertex, there are necessarily only
>> VertexProperties. However looking at the API, it seems like it is supported
>> to write only a VertexProperty if one wants to (see
>> GraphWriter.writeVertexProperty()), so in that case, to me it makes sense to
>> add the types for the elements of the list I described above. @stephen any
>> thoughts about that ?
>>
>>> - Edges:
>>> - is in/outVLabel new? Couldn't find it in the API or any examples of this.
>>> - why not make inV/outV have proper vertices with labels (to satisfy
>>> the case previous case) instead of just IDs? This would also be more
>>> consistent with the API.
>>
>> I haven't touched that part, it was in the format before. I believe this is
>> a question for Stephen.
>>
>>>
>>> Otherwise looks good!
>>
>> Thanks for the feedback.
>>>
>>> On Tue, Jul 19, 2016 at 12:05 PM, gallardo.kev...@gmail.com
>>> <gallardo.kev...@gmail.com> wrote:
>>>>
>>>>
>>>> On 2016-07-15 16:25 (+0100),
>>>> "gallardo.kev...@gmail.com"<gallardo.kev...@gmail.com> wrote:
>>>>>
>>>>>
>>>>> On 2016-07-09 16:48 (+0100), Stephen Mallette <spmalle...@gmail.com>
>>>>> wrote:
>>>>>> With all the work on GLVs and the recent work on GraphSON 2.0, I think
>>>>>> it's
>>>>>> important that we have a solid, efficient, programming language neutral,
>>>>>> lossless serialization format. Right now that format is GraphSON and it
>>>>>> works for that purpose (ever more so with 2.0). Given some discussion on
>>>>>> the GraphSON 2.0 PR driven a bit by Robert Dale:
>>>>>>
>>>>>> https://github.com/apache/tinkerpop/pull/351#issuecomment-231157389
>>>>>>
>>>>>> I wonder if we shouldn't consider another IO format that has Gremlin
>>>>>> Server/GLVs in mind. At this point I'm not suggesting anything specific -
>>>>>> I'm just hanging the idea out for further discussion and brain storming.
>>>>>> Thoughts?
>>>>>>
>>>>>
>>>>> Hey, so I'm trying to gather all infos we have here in order to prepare
>>>>> to move forward with the implem of GraphSON 2.0, here's what I come up
>>>>> with :
>>>>>
>>>>> Things we have :
>>>>> - Type format.
>>>>> - The structure in Jackson to implement our own type format.
>>>>> - All non native Graph types are typed (except the domain specific types).
>>>>>
>>>>> New things we need :
>>>>> - Types for domain specific objects.
>>>>> - Types for all numeric values.
>>>>> - Don't serialize empty fields (outV and stuff).
>>>>>
>>>>> Things we consider changing :
>>>>> - Type IDs convention. Before : Java simple class names. Now : starts
>>>>> with a "domain" like "gremlin" followed by the "type name", which is a
>>>>> lowercased type name (like "uuid", or "float", or "vertex"). Example :
>>>>> "gremlin:uuid".
>>>>> - Type format ?
>>>>>
>>>>> Am I missing something ?
>>>>>
>>>> Hey,
>>>>
>>>> So I've made a few changes in the code from the original GraphSON 2.0,
>>>> with the objectives described above, the code is still messy but I just
>>>> thought I'd share some samples to start getting into the work and gather
>>>> some feedback.
>>>>
>>>> In the example I've created a TinkerGraph with 2 vertices connected by an
>>>> edge. The graph is serialized as a TinkerGraph.
>>>> The samples are there :
>>>> https://gist.github.com/newkek/97da94342bc32e571cf4a0ba1018df60
>>>>
>>>> Any feedback appreciated.
>>>
>>>
>>>
>>> --
>>> Robert Dale
>>>
>
>
>
> --
> Robert Dale
