@Nate I don't want to change the separation of components in cassandra. My ultimate goal is "make writing complex queries less painful and more efficient." How that becomes reality is anyone's guess. There's different ways to get there. I also like having a plugging transport layer, which is why I feel sad every time I hear people say "thrift is dead" or "thrift is frozen beyond 2.1" or "don't use thrift". When people ask me what to learn with Cassandra, I say both thrift and CQL. Not everyone has time to read the native protocol spec or dive into cassandra code, but clearly "some" people do and enjoy it. I understand some people don't want the burden of maintaining Thrift, and it's totally valid. It's up to those that want to keep thrift to make sure patches and enhancements are well tested and solid.
On Wed, Mar 12, 2014 at 11:52 AM, Nate McCall <n...@thelastpickle.com>wrote: > IME/O one of the best things about Cassandra was the separation of (and > I'm over-simplifying a bit, but still): > > - The transport/API layer > - The Datacenter layer > - The Storage layer > > > > I don't think we're well-served by the "construction kit" approach. > > It's difficult enough to evaluate NoSQL without deciding if you should > > run CQLSandra or Hectorsandra or Intravertandra etc. > > In tree, or even documented, I agree completely. I've never argued CQL3 is > not the best approach for new users. > > But I've been around long enough that I know precisely what I want to do > sometimes and any general purpose API will get in the way of that. > > I would like the transport/API layer to at least remain pluggable > ("hackable" if you will) in it's current form. I really just want to be > able to create my own *Daemon - as I can now - and go on my merry way > without having to modify any internals. Much like with compaction > strategies and SSTable components. > > Do you intend to change this current behavior of allowing a custom > transport without code modification? (as opposed to changing the daemon > class in a script?). > >