JSON is comfortable and easy, but something like this makes sense to
me. This idea could be easily extended to to request/response messages
as well. For example, the desired op ('eval', 'bytecode', 'close'
etc.) could be represented with a 4 bit group, etc. etc. This would
allow driver authors to do a lot of optimizations for better
performance. Python for instance, can use C extensions or Cython to
get huge performance gains working with binary data...On Tue, Oct 24, 2017 at 6:27 AM, Jorge Bay Gondra <jorgebaygon...@gmail.com> wrote: > Hi, > I wanted to bring up the possibility to include a specific (as in > non-generic) serialization formal for Graph data. I didn't want to > bump the last > dev discussion on serialization formats > <https://lists.apache.org/thread.html/f27d5cad1382a57c91a4e6486329d9d2d0146a571dc66f973c9ee9c5@%3Cdev.tinkerpop.apache.org%3E> > (I'm > late to the party :) ) as I wanted to dedicate a separate thread. > > GraphSON2 and GraphSON3 have some nice features (readable, extensibility, > ...) but it has some disadvantages, mainly around verbosity and > performance. About Gryo, I think the interoperability issues with Kryo > outside the JVM have already been discussed. > > I'm proposing a binary serialization format that is specifically designed > for the types we handle (+ room for extensibility), with a compact payload > and fast serialization. > > For example: > a) GraphSON3: {"@type": "g:Int32","@value":1} > byte length = 31 > b) GraphBinary: <type_id><value> (a byte representing the type and 4 bytes > representing the value), in bytes: 0x01 0 0 0 0x2 > byte length = 5 > > The serialization logic for each format is: > a) GraphSON3: perform generic json serialization; navigate through object > tree to read the type name; convert the string value to int32 > representation. > b) GraphBinary: read first byte to get the type; move offset + 1; convert 4 > bytes into a int32 representation. > > Any thoughts? > Thanks, > Jorge -- David M. Brown R.A. CulturePlex Lab, Western University
