Andrew Purtell wrote:
That might be because protobuf documentation, and I'd assume accumulated
practice based upon it, warns against using generated pbuf objects directly
as model classes. (See the "Protocol Buffers and O-O Design" callout on
https://developers.google.com/protocol-buffers/docs/javatutorial.)
Assuming that's the case, that makes sense. It was just not clear to me
if Julian and I were just talking past each other or if there was some
fallacy I was suggesting.
Maybe it's possible to wire up Jackson for emitting protobuf output as
another transport option?
https://github.com/FasterXML/jackson-dataformat-protobuf
Thanks for the link. After Paul's offer of help, I meant to look around
to see what this interaction would actually look like. I have more
reading to do.
On Tue, Aug 11, 2015 at 11:47 AM, Josh Elser<[email protected]> wrote:
> I'll admit that I don't understand why protocol buffers is being equated
> with the transport only.
>
> The biggest reason I think Avatica can benefit from using software like
> protobuf is that it makes handling a shift in the API substantially easier.
> For example, what happens when a new field is added to a Request? What if
> you receive a Request that doesn't have a field that you expected it to
> (old client)? This is the problem that I'm trying to solve. Regardless of
> whether this is coming in over the Java API or an HTTP connection, the
> version of the Request or Response (and the actual attributes that it
> contains) are near guaranteed to change.
>
> I don't really care what the bytes look like going over the wire. That's
> just a side-effect to which my only concern is to meet any desires for
> readability that may exist.
>
>
> Does that make sense?
