> 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.
+1 You address the issue of not breaking APIs really nicely with the following: > Thinking one step further, this will allow us to move GraphBinary > serialization to gremlin-core, simplifying dependency management for > integrators. I think that we need to leave gremlin-driver code alone in tp34 and deprecate it in favor of the revised approach to the API you've proposed in gremlin-core. This also nicely sets up the possibility of using GraphBinary beyond the drivers (e.g. OLAP perhaps as a full replacement for Gryo). On Fri, Oct 4, 2019 at 7:49 AM Jorge Bay Gondra <[email protected]> wrote: > 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 >
