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
