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 >
