[
https://issues.apache.org/jira/browse/TINKERPOP-1942?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16509342#comment-16509342
]
Jorge Bay commented on TINKERPOP-1942:
--------------------------------------
There seems to be a misunderstanding about extensibility: As you can read in
[the
proposal|https://github.com/apache/tinkerpop/blob/TINKERPOP-1942/docs/src/dev/io/graphbinary.asciidoc],
custom types are supported. We would be offering the same capacity for vendors
to provide their own data types. The same amount of effort is expected for a
vendor to implement it.
There are several serialization formats and some of those have been proposed
here in the comments (protobuf, smile) but instead of discussing each pros/cons
I would like for us to focus on the merits of a custom binary serialization
format vs reusing an existing one.
Most of the benefits are exposed in the ticket description but I can summarize
the key benefits with the proposal:
- Error handling: Relying on a third party library (like we do for json)
causes exceptions to be unclear when there is a serialization issue. With our
format, we can throw exceptions like "Expected label for Vertex".
- Performance: Reducing the serialization overhead and minimizing the size of
the payload, making serialization and deserialization processing time
negligible on both the server and the client.
- Reduce the amount of dependencies on both the server and the client.
- Flexibility to optimize for our specific use-cases: we don't have to adapt
our types to "fit" into the serialization format or to provide metadata of the
type. The format is based on an specification instead of metadata (like it
occurs with formats such as protobuf). We can also introduce our own mechanisms
for versioning / making it future proof, without the need of special decoration.
The idea is not to reinvent the wheel, any database/rdbms technology has their
own binary serialization format, we can use the lessons learned from their
journey to provide the best one possible for our use case.
> Binary serialization format
> ---------------------------
>
> Key: TINKERPOP-1942
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1942
> Project: TinkerPop
> Issue Type: Improvement
> Components: io
> Reporter: Jorge Bay
> Priority: Major
>
> We should provide a binary serialization format designed to reduce
> serialization overhead and minimizing the size of the payload that is
> transmitted over the wire.
> It could be implemented in a very similar way as Kryo support but with
> interoperability in mind and ultimately we could fade Gryo out, as now with
> the GLVs it doesn't have a role to play.
> The main benefit would be the performance improvement, making serialization
> and deserialization processing time negligible on both the server and the
> client.
> Background:
> https://lists.apache.org/thread.html/13e70235591853801bab16ed457ee4f56f3dfe2d1c5817c34a036408@%3Cdev.tinkerpop.apache.org%3E
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
