> > Still, to Clint's point, everyone knows how to make an HTTP request. If you > want a cassandra client running on, let's say, an iPhone for some reason, a > REST API is going to be a lot more straight forward to implement.
There's no reason an HTTP service would have to live inside the Cassandra project though, right... we're just talking about a proxy that translates from one protocol (HTTP) to another (thrift / avro). Shouldn't be too hard to implement. It could even be open sourced, and referenced from the Cassandra website, maybe even endorsed by the Cassandra project. High level though I think it's important to resist the temptation to build things in that could just as easily live separately and develop orthogonally. I feel the same way about access control... I think it's more natural and flexible for that to be handled in an application rather than in the database... If your particular requirements end up pushing access control back to the data store tier than it should be fairly easy to wrap the Cassandra service at either the Java level (by subclassing) or the OS level (by having Cassandra listen only on localhost and have an authenticating / authorizing proxy listen for remote requests & forward). But it looks like that decision has already been made. Mike
