Github user newkek commented on the issue:
https://github.com/apache/tinkerpop/pull/386
Hey @okram ,
> 1. The term is "namespace" not "domain." In case that terminology is used
in the documentation and not just in the PR notes.
Ok, it's some places here and there in the code, I'll correct it.
> 2. Why do we have `@class` and `@type`.
`@class` shouldn't be anywhere near GraphSON 2.0 anymore, everything is
`@type`, if you've seen it somewhere, that should be corrected. While writing
that I realise I might have forgotten to update the "the-graph.asciidoc" doc...
so I'll correct it. But in the actual code it shouldn't be there anymore.
> 3. I read your notes, but its still not clear to me. Why do we have
`@value`? I think we [...]
So, taking a step back and I'm going to use the exampleof ByteCode. As you
can see in the `GraphSONSerializersV2d0`, serializers don't have to care
anymore about types, serializer are put into the context of "You're in a place
where you can write whatever you want, type is handled somewhere else for you".
For the ByteCode serializer it means it would open a Map, put a field
"language" and its value, put a field "argument" and its value, put a field
"value" (or call it "bytecode") and its value, close the map. When
deserializing, read the map, get the fields values, create the ByteCode object.
Let's admit for whatever reason the ByteCode serializer in the future needs
to change and instead of writing a Map, it needs to start by an Array where the
first element of the array is 'something', the rest is the Map described
before, and close the array. Doing this is currently possible with the current
format `{"@type":"typename", "@value":value}`, because the serializer is in a
place where it can write whatever it wants to.
Now let's consider another format: `{"@type":"typename", value}`. There,
the serializer is put in the context "You are currently in a **Map**, whatever
you write, it must be in the form of a key/value pair". The "potential future"
evolution of the ByteCode serializer (writing an array) *wouldn't* be possible.
For the sake of consistency, I think it is important to keep the format as is
> 4. I think we can save some bytes and still be readable if we make our
namespace g
Totally fine with `g`, again for the sake of consistency, I think it'd be
valuable to have a 'name space' all the time.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
