Just wanted to note that Gryo 3.0 work is happening here in case anyone wants to follow along:
https://issues.apache.org/jira/browse/TINKERPOP-1698 I have a branch setup. I think I'm going to clean up Gremlin Server configuration files for 3.3.0 and remove a bunch of the old serializers. The config is starting to look really confusing. I think it would be best to just have Gryo and GraphSON 3.0 configured in the packaged sample files. On Tue, Jun 20, 2017 at 8:25 AM, Stephen Mallette <spmalle...@gmail.com> wrote: > I'd really like to get our IO situation really solid in 3.3.0 and while we > talk about GraphSON a lot I think Gryo still has an important place in our > serialization story. Gryo covers an extended set of classes that goes > beyond what we cover in GraphSON. I don't know if all those registered > classes matter though - one would think that we just need parity with > GraphSON defined classes. > > https://github.com/apache/tinkerpop/blob/9f13e69853c03a2fde77efd40c6526 > b91a4b346a/gremlin-core/src/main/java/org/apache/ > tinkerpop/gremlin/structure/io/gryo/GryoVersion.java#L192 > > I think that the reason this area of code has grown so much is from the > basis of another issue with gryo which is that we don't always have a nice > separation between implementations and serialized classes. In other words, > if we have some complex class like DefaultTraversalMetrics, we just > register all the classes that DefaultTraversalMetrics has as fields (and > all the classes those classes use) until the serialization works. While > this is really easy and, in a sense, convenient, it creates some problems: > > 1. We get this big long registration list which includes types we don't > support in GraphSON (which typically aren't tested) > 2. We have now bound the serialization of the complex class to its > structure. If there is a problem with DefaultTraversalMetrics in the future > and we have to change a field we essentially break all compatibility within > gryo. (i'm facing this issue now actually). > > I would really like Gryo 3.0 to do a better job in this area, allowing for > better forward and backward compatibility with a more limited class > registration list that is more in line with the types defined for GraphSON > support. I think we can get better forward/backward compatibility if (1) > there is better separation between the object being serialized and the > object used in application logic (think of the "detached" classes) and (2) > gryo serializers for 3.0 have greater intelligence around internal > compatibility handling. > > Anyway, I was mostly writing this as notes to myself in preparation for > 3.3.0, but I'd be happy to hear any thoughts anyone might have on this. >
