[
https://issues.apache.org/jira/browse/TINKERPOP-1942?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16506291#comment-16506291
]
Kevin Gallardo edited comment on TINKERPOP-1942 at 6/11/18 2:57 PM:
--------------------------------------------------------------------
Hi all, will throw this out there: TIL about a binary format developed by the
team from Jackson: [https://github.com/FasterXML/smile-format-specification]
supposedly this format has the same characteristics as JSON in terms of
composability, so maybe something that could be for use here.
If this fits the use case it would allow not having to re-create a new format
from scratch, it would also mean that this comes with already some libraries
supposedly optimized for example in Java and others like the current Jackson
libraries are.
Disclaimer: Unfortunately I haven't had a chance to follow the full
conversation here yet but wanted to mention that if anybody wants to have a
look.
was (Author: newkek):
Hi all, will throw this out there: TIL about a binary format developed by the
team from Jackson: [https://github.com/FasterXML/smile-format-specification]
supposedly this format has the same characteristics as JSON in terms of
composability, so maybe something that could be for use here.
If this fits the use case it would allow to having to re-create a new format
from scratch, it would also mean that this comes with already some libraries
supposedly optimized for example in Java and others like the current Jackson
libraries are.
Disclaimer: Unfortunately I haven't had a chance to follow the full
conversation here yet but wanted to mention that if anybody wants to have a
look.
> 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)
