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<josh.elser@gmail.com> 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?
|