I see, sounds good. I read up on it more and indeed there is a binary encoding. There is still the mild complexity of declaring a schema.
Personally I wouldn't mind at all if someone replaced every use of Writable (or reimplemented the Writables) with Avro if it gave a clear advantage in speed or clarity or reusability or something, and I am guessing it can be done. If someone wanted to use Avro in one job only, I'd suggest it's better to stick to what the rest of the code does now. The project has had a big problem with half-implemented ideas in the past so I'm allergic to another one. On Sun, May 29, 2011 at 1:43 AM, Ted Dunning <[email protected]> wrote: > Avro is NOT JSON-based. It is one of the most efficient binary encodings > around. > > Avro uses JSON as a concrete syntax for the schema and it supports a JSON > based alternative serialization format, but the primary format is a very > well done binary format. > > The great virtue of Avro over Writables is that Avro is polyglot, Writables > are limited to Java. Moreover, you don't actually need to have the schema > handy, nor generate any code to read Avro files. This means that you can > write basic scripts to munch on files without much information about the > contents. You can even see what fields are available and get information > about their types. > > Avro is roughly equivalent to proto-bufs, but has a few additional > capabilities: > > - no code generation required > > - data knows its own schema and will interoperate with any other compatible > schema > > - data reflection allows you to inspect and reverse engineer data > > - a native RPC mechanism is provided. > > On Sat, May 28, 2011 at 4:13 PM, Sean Owen <[email protected]> wrote: > > > Avro is JSON-based and that just seems far too verbose for these > purposes. > > >
