On Jan 17, 2011, at 9:01 PM, Eric Evans wrote: > On Mon, 2011-01-17 at 12:12 -0500, Jake Luciani wrote: >> Some context: We have begun the process of removing Avro from the >> service layer CASSANDRA-926. We currently use Avro for schema >> migrations internally, and we have two open items that are using Avro >> for our internal file storage. CASSANDRA-1472 and CASSANDRA-674. > > FWIW, this should be done (removing the RPC interface). Anything missed > is deserving of a bug report > >> My opinion is we need to control the lowest layers of the code and not >> rely on a third party library. By using a third party library like >> Avro, it becomes a black box that we need to deeply understand and >> work around. Also, since Avro is developed separately we have another >> core dependency that could disrupt releases (say a bug in Avro). > > +1 > > The Avro RPC interface was an experiment, and it was always the case > that if it didn't supplant the Thrift interface as status quo, that it'd > be removed. However, as I remember it, part of the justification for > using it in migrations was that it was already there. In hindsight that > was probably a mistake. > > Anyway, we have too many dependencies as it is, I'd rather move toward > eliminating it entirely unless there is a very compelling reason not to > (I don't think there is).
Just saw Stu's comment on CASSANDRA-1472: "I think that implementing a compressible block based file format is a non-trivial task, and that before we commit to re-implementing Avro's (in a bounded timeframe especially), we should review our requirements. This decision needs to be made for technical reasons and not grounded in NIH." Is that a compelling reason to use avro for some of the internals or is that something that someone is willing to implement/maintain? Just trying to bridge discussion here with comments on the ticket. > > -- > Eric Evans > eev...@rackspace.com >
