Avatica serialization concerns

[Nick Dimiduk <nd...@gmail.com>]

While working through changes for CALCITE-640, I've noticed what appears to
be a failure to isolate RPC concerns from the interfaces they expose. The
code smell I noticed is that we need to have Jackson annotations for
serialization of objects in both Meta and Service interfaces. IMHO, this
should be isolated to just one place or the other. It's not a terrible
concern today, but I think it will become so once we want to support
alternative encoding formats (i.e., protobuf, thrift, avro). These systems
force a clear distinction of what is serializable through their use of an
IDL.

Thoughts?
-n

Re: Avatica serialization concerns

[Julian Hyde <ju...@hydromatic.net>]

+1

Classes such as Signature are "value objects" and it is appropriate that they should be part of the RPC interface. The easiest way to make them serializable is to use Jackson annotations. It doesn't preclude other serialization mechanisms, transports, or RPC mechanisms, but it makes it look as if Jackson is somehow preferred, and that is bad.

I think there is a way to declare Jackson mappings that does not use annotations, and is therefore external to the classes being serialized.

As for an IDL. We can move to that when we are ready to call the RPC interface stable and/or when we start thinking about moving to a different format. Not for a while yet.

Julian

> On Mar 24, 2015, at 5:07 PM, Nick Dimiduk <nd...@gmail.com> wrote:
> 
> While working through changes for CALCITE-640, I've noticed what appears to
> be a failure to isolate RPC concerns from the interfaces they expose. The
> code smell I noticed is that we need to have Jackson annotations for
> serialization of objects in both Meta and Service interfaces. IMHO, this
> should be isolated to just one place or the other. It's not a terrible
> concern today, but I think it will become so once we want to support
> alternative encoding formats (i.e., protobuf, thrift, avro). These systems
> force a clear distinction of what is serializable through their use of an
> IDL.
> 
> Thoughts?
> -n