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