Hi All,

I've noticed that there are some serializers/deserializers that exist for
GraphBinary and GraphSON that may not serve a real purpose and I'm
proposing that we remove them in V4. In general, I think we should move
away from providing serializers for all types in the Java Standard Library,
as there are many types that other GLVs simply won't support. The types in
GraphSONv3/GraphBinaryV3 that I would remove include:

Barrier, Cardinality, Column, DT, Merge, Operator, Order, Pick, Pop, Scope,
T

Because the GLVs will now use GremlinLang (instead of Bytecode), these
values will be translated to Strings so they don't need their own specific
serializers. T and Direction are the two exceptions because they are
returned in the valueMap() and elementMap() steps, although it's likely
they will be replaced in the future as well. For similar reasons, P and
TextP should also be removed since they will also be Strings in GremlinLang.

Period, Timestamp, Instant, ZonedDateTime, OffsetTime, LocalDateTime,
LocalDate, LocalTime, MonthDay, YearMonth, Year, ZoneOffset

These are from the java.time package but are all variants of OffsetDateTime
and Date. I don't think it makes sense to provide serializers for these
Java-specific types that are mostly unsupported by the other GLVs and can
be represented by either an OffsetDateTime and/or Date, so I think we
should only have OffsetDateTime and Date.

BulkSet and Traverser are two optimizations that exist to increase
performance but that the user shouldn't be able to interact with. I'm
suggesting that we remove these serializers, however, to keep the
performance optimizations, I would suggest that we add a flag to the List
type so that it can achieve the same sort of bulking that those types
provided. GraphSON would simply serialize these as arrays without a bulk so
it would be the expanded BulkSet. GraphBinary would have an additional
value_flag for List with the value 0x02 to denote bulking. This would mean
the item_i is a fully qualified item followed by a Long value that is the
bulk.

Class and InetAddress are highly Java-specific and can't be used by the
other GLVs. Binding and Bytecode have both been removed so it doesn't make
sense to keep their serializers around. Metrics, TraversalMetrics can be
represented as a list of Strings so they shouldn't require their own
serializers.

The last type that I think should be removed is Custom. The most common
complaint that I've seen from end-users regarding custom types is that they
lack serializers in their GLV of choice. Custom serializers require extra
effort from providers as it is they that need to maintain and publish them.
Users often don't realize that they can't just use the GLV without adding
the custom serializer from their provider which can lead to a frustrating
initial experience. So, instead, to provide a more seamless user experience
I'm proposing we replace Custom with a Provider Defined Type (PDT).
Actually, two PDTs, one for primitive types and one for composite types.
These PDTs will also serve as a mechanism to allow reading of values whose
serializer has been removed in V4. This would allow a provider that
supports one of those Java-specific types to still return the value as a
PDT.

The PrimitivePdt will contain two fields: a String for the type name and a
String for the actual value. The CompositePdt will contain two fields: a
String for the type name and a Map that contains the fields of the
composite type (most likely a class). PDTs will come with default
serializers and deserializers. On the user-side, the values will be
deserialized into either PrimitivePdt or CompositePdt. In order to write a
PDT to the server, the user would have to look up the required fields for
that specific type name. This information would likely need to exist in the
provider's documentation. On the server, there will be an API (probably
attached to the Graph interface) that will allow the provider to add types
that should be able to be serialized/deserialized from PDT. In order to
achieve this, there will need to be a TinkerPopCustomType interface that
has two methods: serialize() and deserialize(). Then, any type that
implements TinkerPopCustomType could automatically be
serialized/deserialized with the provided PDT serializers for both
GraphSONv4 and GraphBinaryV4.

Does anyone have any comments or concerns about these proposed changes?

Thanks,
Ken

Reply via email to