tinkerpop-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (TINKERPOP-1274) GraphSON Version 2.0
Date Sat, 02 Jul 2016 15:24:10 GMT

    [ https://issues.apache.org/jira/browse/TINKERPOP-1274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15360211#comment-15360211
] 

ASF GitHub Bot commented on TINKERPOP-1274:
-------------------------------------------

Github user spmallette commented on the issue:

    https://github.com/apache/tinkerpop/pull/351
  
    > 1. A type is not a class. Call types 'type' or '@type' (not clear the @ is necessary
since it's in the metadata payload anyway); Not @class. (Otherwise be consistent and rename
all the Type* classes to be Class*. e.g. ClassDeserializer)
    
    Changing "@class" to "@type" is ok by me if others like it. I'm not tied to one or the
other - "@type" does seem a little better to me the more i think on it, but I'll let @newkek
(or others) weigh in on it.
    
    > 2. Don't use Java types. Use BSON as a reference. It has a nice type system and solved
most if not all of the type concerns. http://bsonspec.org/spec.html
    
    Not sure about BSON typing as a solution. Ultimately we want to know if something is a
`Vertex`, `Edge`, `Duration`, `GeoPoint`, etc. In fact we don't always know the types ahead
of time (like Titan's `GeoPoint`), so using the java class name is pretty convenient.
    
    3. If space and processing efficiency is a priority, then consider actually using BSON.
    
    imo, we're pretty deep into this approach having discussed it over multiple weeks in the
community. making a big switch like that is probably something to reserve for the future especially
since @newkek put a fair bit of effort into this work at this point and it delivers what took
a while to get agreement on. 
    
    If however BSON (or some other format) could be proven a more efficient network serialization
format that is truly programming language agnostic, with wide support and consistently performant
parsers in the major languages we support (which is what had doomed MsgPack some time back),
then I think we could consider that as an additional IO format.  @robertdale if you have ideas
there, it would be nice to hear them. Please consider sending a message on the dev mailing
list if you do.
    
    4. Alternatively, use an external schema to define types. It could even be appended to
and a part of the output.
    
    That would be an interesting option, however would mostly be good for network serialization
and not so much for file storage. So far we haven't written a network only IO package, though
we have written a file storage only one with GraphML. I think that we could consider a network
serialization one only since dependence on Gremlin Server for non-JVM languages is going to
be something we need to support in the face of GLVs.
    
    Thanks for your thoughts @robertdale 



> GraphSON Version 2.0
> --------------------
>
>                 Key: TINKERPOP-1274
>                 URL: https://issues.apache.org/jira/browse/TINKERPOP-1274
>             Project: TinkerPop
>          Issue Type: Improvement
>          Components: io
>    Affects Versions: 3.1.2-incubating
>            Reporter: stephen mallette
>            Priority: Minor
>             Fix For: 3.2.1
>
>
> Develop a revised version of GraphSON that provides better support for non-JVM languages
that consume it. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message