Hi all I think this is a great idea. If you take out Thrift, which is where the bulk of the n00b installation pain lies, and add a query language and a PHP extension then I think Cassandra will go mainstream.
I still need to write a proper blog post for the team but just so you all know, we're happily using Cassie for all sorts of stuff on Motribe at the moment. The work you are doing is changing lives, bit by bit, and many more people appreciate it than you realise. Kind regards, _________________________________ Vincent Maher Founder, Motribe http://motribe.com && http://motribe.mobi "Accidents don't happen to people who take accidents as a personal insult" - Don Corleone Blogs: http://www.vincentmaher.com Facebook: http://www.facebook.com/vincentmaher Twitter: http://www.twitter.com/vincent_maher Mobile: +27 82 998 5412 Google Talk: flob...@gmail.com Skype Name: vincentmaher On Thu, Oct 28, 2010 at 10:40 PM, Eric Evans <eev...@rackspace.com> wrote: > > I don't know about everyone else, but I've been pretty dissatisfied with > our API situation for some time. > > I used to be of the opinion that The Problem was Thrift and The Answer > was Avro. I do still prefer Avro over Thrift as dependencies go, but > I've come to the conclusion that the real problem has more to do with > the object-oriented RPC pattern that both share in common. > > I used to think this was a necessary burden in order to expose the full > power of our query API in a client agnostic manner, and that it was the > job of third-party libraries to wrap this layer to create stable > idiomatic interfaces. > > And, I used to think a vibrant ecosystem of these idiomatic libraries > would emerge, but it hasn't. Truth is we've seen quite a bit of > proliferation, and very little critical mass. > > This shouldn't be construed as criticism levied against library > maintainers, on the contrary, I think they've done an amazing job all > things considered. But in my opinion, our RPC interfaces push way too > many implementation details client-side, making them brittle and > unstable. This results in unnecessarily complex libraries that are > forced to move in lock-step with Cassandra releases, that are never > backward compatible, and which are consistently broken during our > development cycle. I think we can provide client maintainers and users > with a better experience than this. > > One solution to this is to implement a server-side query language, with > simple language drivers that manage all of the common functionality in a > consistent way (statement preparation, connection pooling, etc). > Library maintainers would then build their idiomatic interfaces on top > of these, (and I imagine, remove a metric crap-ton of code in the > process). > > To this end I've been playing with exactly that. I have enough to do > simple reads and writes, and I have stubbed out drivers for Java and > Python. I'm seeking community feedback to gauge interest, and to > satisfy the much needed desire to bike-shed. :) > > http://github.com/eevans/cassandra/tree/CQL > > You need to be sure you're checking out the "CQL" branch. > > This is implemented in the Avro interface so you'll need to pass the -a > flag when launching the daemon. > > It is far from complete, and is surely quite buggy at this stage, take > it as a preview or demonstration; it's meant to be a starting point for > discussion. > > There is a bit of documentation on the syntax, you can see that here: > http://github.com/eevans/cassandra/blob/CQL/doc/cql/CQL.textile > > There are some system tests in test/system/test_cql.py that should give > you the basic idea, but assuming you have the Avro Python module > installed you should be able to just... > > $ cd drivers/py > $ python >>>> import cql >>>> conn = cql.Connection('Keyspace1', 'localhost', 9160) >>>> conn.execute('UPDATE Standard1 WITH ROW("k", COL("c", "hello!"));') >>>> print conn.execute('SELECT FROM Standard1 WHERE KEY = "k"') > [{u'columns': [{u'timestamp': 1288297508761L, u'name': 'c', u'value': > 'hello!', u'ttl': None}], u'key': 'k'}] >>>> > > > I've been chewing on all of this for a while so I'm brimming with ideas, > but I'll let the dust settle on this email before going any further. :) > > Thoughts? > > > > P.S. Dear Cliff Moon, I apologize. You were right. > > -- > Eric Evans > eev...@rackspace.com > > > > >
