[Avatica] Separating wire message from service implementation

[Josh Elser]

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