You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@avro.apache.org by Connor Doyle <co...@gmail.com> on 2013/03/18 05:16:10 UTC
Parsing canonical form of protocol definitions
I've started working on a reflective Avro library for the Scala programming language.
The description of Parsing Canonical Form is clear enough for schemas, but I can't seem to find any mention of prescribed ordering of the "types" field for protocol definitions in the current specification. I've based my first pass on forward declarations elimination, but this gives only a partial order.
In the absence of spec I can base behavior on the reference (Java) implementation, but am curious about this aspect of the handshake.
--
Connor
Re: Parsing canonical form of protocol definitions
Posted by Connor Doyle <co...@gmail.com>.
Yep, that is helpful.
For reference, the project (in its early stages) is here: https://github.com/GenslerAppsPod/scalavro
Thanks,
--
Connor
On 19 Mar 2013, at 11:05, Doug Cutting <cu...@apache.org> wrote:
> The RPC handshake was designed to be tolerant of differences in the
> protocol hashing method. The java implementation uses MD5 of the
> protocol's un-normalized text. This could result in the needless
> transmission over the wire of protocols that only differ in trivial
> ways, but since clients and servers cache these, they should't be
> transmitted often.
>
> A server should cache a client's protocol using the client-computed
> hash as key. So if two clients hash schemas differently then the
> server will end up with two entries in its cache. This permits
> variation in implementation (intentional or not).
>
> Does that help?
>
> Doug
>
> On Sun, Mar 17, 2013 at 9:16 PM, Connor Doyle <co...@gmail.com> wrote:
>> I've started working on a reflective Avro library for the Scala programming
>> language.
>>
>> The description of Parsing Canonical Form is clear enough for schemas, but I
>> can't seem to find any mention of prescribed ordering of the "types" field
>> for protocol definitions in the current specification. I've based my first
>> pass on forward declarations elimination, but this gives only a partial
>> order.
>>
>> In the absence of spec I can base behavior on the reference (Java)
>> implementation, but am curious about this aspect of the handshake.
>> --
>> Connor
>>
Re: Parsing canonical form of protocol definitions
Posted by Doug Cutting <cu...@apache.org>.
The RPC handshake was designed to be tolerant of differences in the
protocol hashing method. The java implementation uses MD5 of the
protocol's un-normalized text. This could result in the needless
transmission over the wire of protocols that only differ in trivial
ways, but since clients and servers cache these, they should't be
transmitted often.
A server should cache a client's protocol using the client-computed
hash as key. So if two clients hash schemas differently then the
server will end up with two entries in its cache. This permits
variation in implementation (intentional or not).
Does that help?
Doug
On Sun, Mar 17, 2013 at 9:16 PM, Connor Doyle <co...@gmail.com> wrote:
> I've started working on a reflective Avro library for the Scala programming
> language.
>
> The description of Parsing Canonical Form is clear enough for schemas, but I
> can't seem to find any mention of prescribed ordering of the "types" field
> for protocol definitions in the current specification. I've based my first
> pass on forward declarations elimination, but this gives only a partial
> order.
>
> In the absence of spec I can base behavior on the reference (Java)
> implementation, but am curious about this aspect of the handshake.
> --
> Connor
>