In the case of RPC, I think, not just Python and Java, but all supported
languages, should be compatible with each other.
Tibor
On 12/02/2013 10:56 PM, Philip Zeyliger wrote:
It sounds like you're proposing to break language API compatibility.
Are you also proposing to break wire compatibilit
I am mistaken in the previous email-- specific record does implement the
generic record API. However, generated specific record builders are not
generic, so building a specific record with fields not known at compile
time requires reflection.
- Dan
On Tue, Dec 3, 2013 at 5:28 PM, Dan Burkert w
It would be nice if specific records implemented the generic record API.
This is useful when you don't know field names of a specific record at
compile time. Reflection is the only way around this currently. Also, it
would be useful if there was built in support for determining if a given
schema
On Mon, Dec 2, 2013 at 1:56 PM, Philip Zeyliger wrote:
> It sounds like you're proposing to break language API compatibility. Are
> you also proposing to break wire compatibility for Avro HTTP RPC, Avro Netty
> RPC, and/or Avro datafiles?
We should be able to provide back-compatibility. When cu
It sounds like you're proposing to break language API compatibility. Are
you also proposing to break wire compatibility for Avro HTTP RPC, Avro
Netty RPC, and/or Avro datafiles?
I'd be appreciative of a mechanism by which systems that happen to use Avro
currently need not be forced to choose one
Hi all,
Avro, in its current form, exhibits a number of limitations that are hard
to work with or around, and hard to fix within the scope of Avro 1.x :
fixing these issues would introduce incompatible changes that warrant a
major version bump, ie. Avro 2.0. An Avro 2.0 branch would be an
opportun
