calcite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Julian Hyde <>
Subject Re: Should Jackson-annotated POJOs stick around
Date Wed, 12 Aug 2015 20:10:20 GMT
Here’s where I’m coming from. I’m not an expert on RPC, so maybe my enthusiasm for a
clean, open, layered architecture is naivete as much as it is idealism. I probably mis-use
terms “transport” and “wire protocol”.

I am very glad that genuine experts have joined this conversation (and since this is email,
I should say that I mean that sincerely). Please take my words with a grain of salt but heed
my overall message: that we should design this as a stack that can be re-used and evolve,
not as a driver for a particular database and language binding.

It is also becoming clearer to me that at some point we should split Avatica into a project
separate from Calcite. The thread about Calcite’s graduation is probably a better place
for that discussion.


> On Aug 11, 2015, at 2:44 PM, Josh Elser <> wrote:
> Ted Dunning wrote:
>> On Tue, Aug 11, 2015 at 1:14 PM, Josh Elser<>  wrote:
>>> 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
>>> 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.
>> This differentiation between wire protocol and API is something that I have
>> seen repeatedly in ex-Googlers. I was a bit curious since it seemed nice to
>> have one definition for both levels.
>> My opinion has verged to be 100% with the Google philosophy of separation
>> after watching how the MapR internals work.  This kind of separation has
>> really paid off in many instances. Having too tight a lock between wire and
>> API would have been nearly disastrous for either comprehensibility of the
>> API or efficiency of the wire. I can't share specifics, but if second-hand
>> opinions are useful, you now have mine.
> Absolutely, opinions are very useful here, Ted. Much appreciated. I'm trying to feel
my way through the cleanest approach without stepping on architected toes.

View raw message