Hi, As part of GraphBinary implementation, it was decided to use Netty Buffer API for serialization, which has several benefits over nio <https://netty.io/wiki/using-as-a-generic-library.html#wiki-h2-0>.
There's a problem with approach taken though, the API of TypeSerializer<T>, GraphBinaryReader and GraphBinaryWriter exposes Netty's ByteBuf. Exposing third party library types in an API is generally not a good idea as it tightly couples your API to the third party library. When considering dependency versioning and jar shading, this complicates downstream integration greatly. I propose we wrap the ByteBuf and expose our own Buffer interface in the GraphBinary API, that exposes the same readX() and writeX() methods of ByteBuf. Thinking one step further, this will allow us to move GraphBinary serialization to gremlin-core, simplifying dependency management for integrators. Introducing Netty's buffer API in our reader/writer APIs was a call I made... I should have thought of this before doing so. I think there's an opportunity to fix this in the 3.4 line, as there are no graph providers that implemented GraphBinary yet. Graph providers implementing it now could follow the upgrade guide, the good news is that there isn't any user-facing change expected. Thoughts? Jorge
