+1 for proto3. mostly for the later move to using grpc, which lets us leverage a battle tested framework for doing real protobuf services with fast streaming (how nice!).
proto3 can be backwards compat in some ways (eg. map implementation done manually in proto2). I don't think its a huge issue since there are currently no backwards compat guarantees anyways AFAIK. On Thu, Aug 6, 2015 at 3:11 PM Josh Elser <[email protected]> wrote: > Hi, > > I have some ideas which I'd like to try to working on to improve > Avatica. My direct interest is in support of the Phoenix Query Server > which builds on top of Avatica. > > One of the big areas of improvement that stands out to me is the > Jackson-annotated Response/Request classes. First, we'd want to make > sure these classes are stable (in terms of fields/attributes) so that, > as each object evolves, we prevent existing clients from breaking. > Second, it's desirable that we have some representation of these objects > in a manner that's accessible to non-Java clients. > > Ideally, preserving JSON as the serialized representation of these > classes is also desirable as it's always pleasant to actually be able to > read the data going over the wire when necessary. > > Given these goals, two tools stood out to me as candidates that would > solve this problem well without extra effort in the transport: Thrift > and Protobuf v3. > > Using Thrift only for object generation is a bit overkill, but this is > an area of Thrift that has been rock-solid in the years that I've used > it. Classpath issues with Thrift are always a concern as multiple > versions of Thrift tend to break terribly (at least when performing > Thrift RPCs -- I wouldn't necessarily trust it to be safe for only > object serialization). It's easy to serialize Thrift objects to JSON and > we can generate these classes for other languages. > > I would call Protobuf v3 very young, although it does appear to fit the > bill. Protobuf v2 has had a track record of being a pain when different > versions of the library exist. For example, the Java classes generated > by protobuf 2.x would fail to work with protobuf 2.y. I assume there's > not enough evidence on protobuf v3 to say whether this will continue to > be a problem. JSON-representation of objects and cross-language support > are both natively supported (best as I can tell). Hypothetically, > adopting protobufv3 could also have some extra benefits down the road > such as leveraging grpc to replace Jetty, but that is an entirely > different discussion for later :) > > If you've gotten this far, I'd humbly ask for any opinions on the > technology choices. Any opinions for or against one or the other? Any > similar experiences? > > Thanks! > > - Josh >
