Thanks Florian for starting the discussion on this topic! I think its a good exercise to evaluate which types are necessary for a GLV to support.
I went through a similar exercise when designing the binary serialization format. I'll go ahead and propose: All types that are considered "Core", "Graph Structure" and "Graph Process" in GraphSON3 <http://tinkerpop.apache.org/docs/current/dev/io/#_core_2> plus the following from the "Extended" list: - Short - Byte - ByteBuffer - BigInteger - BigDecimal The rationale is to select types that *can't be represented and stored* using other types. For example: - Short can be stored using an int backing field, but it would take twice the space. - BigDecimal can be stored using a ByteBuffer but ordering on a buffer doesn't align with decimal ordering. Regarding serialization and deserialization asymmetry on GLVs (for Core and Extended types), I think we should avoid it as it could lead to obscure error messages on the user side. I think we should provide a comprehensive type representation but it doesn't have to be contain any type imaginable. The Gremlin Server and the GLVs provide extension mechanisms that vendors and users can use to support other types. 2018-05-24 14:31 GMT+02:00 Florian Hockmann <f...@florian-hockmann.de>: > As part of the discussion for the pull request by Daniel C. Weber that adds > support for more extended GraphSON types to Gremlin.Net [1] we identified > several of those types to be problematic for non-Java languages (or at > least > for .NET in this case) as they don't really have counterparts in other > languages and for some it was even difficult to say where they differ from > each other. > > > > Now the question is basically what we want to do with those problematic > types. > > > > My suggestion would be an approach like this: > > 1. Identify types that are problematic and that we therefore don't > want > to support across all GLVs. > 2. Communicate to users somehow which types are problematic (something > like a deprecation) as we won't support them in all GLVs and maybe even > stop > supporting them at all at some point in the future. > 3. Support the remaining types in all GLVs. > > > > Does that sound like a good plan? Are there any good ideas for the > deprecation of those problematic types? My first idea would be to put them > in a different section in the I/O docs [2] that explains at the beginning > that and why they are deprecated, but maybe someone here has a better idea. > > > > Another question that was brought up during the review of the mentioned PR > by Jorge was whether types should only be supported symmetrically or > whether > GLVs should try to support types as good as they can. If someone has good > arguments or a strong opinion for either side then it would of course also > be good to hear them. > > To give a concrete example of what is meant by symmetric support: > > In its current form the PR deserializes both GraphSON types gx:Duration and > gx:Period to the .NET type TimeSpan and it serializes TimeSpan back to > gx:Duration. This means that gx:Duration is supported symmetrically, but > gx:Period is not as there exists no .NET serializer that create a > gx:Period. > > > > [1] https://github.com/apache/tinkerpop/pull/842 > > [2] http://tinkerpop.apache.org/docs/current/dev/io/#_extended_2 > > > >
