> Here clients HAVE to choose between 'reflect' and 'specific' Avro engine, but that should be ok for now.
That would work if you only transition protocols to Specific and never wish to rely on Reflect. Since some parameter types are used by multiple protocols, this requires you to transition more (all?) protocols at once, whereas, if some parameters could use Reflect, you could transition things from Writable to Avro protocol-by-protocol, which might be easier to debug. But AvroSpecificRpcEngine should be easy to write, and, long-term, when all protocols use Specific, we'll want this, so it'd be a good addition. +1
Avro 1.4, which should be released next week, better integrates 'specific' and 'reflect'. With a little more effort this could be make to 'just work', i.e., ReflectRequestor and ReflectResponder would be able to handle Specific data. Glancing at the code, it looks like mostly what remains is fixing a few isX() methods in ReflectData so that unions would be dispatched correctly. Making GenericArray to implement Collection would also simplify this. Anyway, it's close. If this sounds of interest, please file an Avro Jira requesting this.
Alternately, we could simply configure things, protocol-by-protocol to use either specific or reflect. But intermixing might then cause problems, and it might be nice to be able to move more incrementally.