[ 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)