It's impossible to argue against this kind of consensus, so I won't. Can we please turn this discussion to something productive? Namely: now that we've eliminated the top (IMO) choice for a standard serialization framework within Cassandra, which option _will_ we choose? Continuing down our current path of custom serialization is completely untenable without a massive overhaul:
1. It is not backwards compatible 2. It does not use compact encodings of integer data 3. It is verbose: serialization code and the java.io package are present in every object I would have preferred Avro, but I'd rather use Thrift than no framework at all. On Tue, Jan 18, 2011 at 7:49 AM, Jeremy Hanna <jeremy.hanna1...@gmail.com>wrote: > > 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 > > > >
