I can agree with not liking the "construction kit approach". Redis http://redis.io/commands 40 plus commands over telnet.
elastic search: json over http: http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/search-search.html couch db: json over http and javascript: http://docs.couchdb.org/en/latest/intro/tour.html mongo db: json over binary api, with javascript and in database map reduce. At this point it is just different strokes for different folks, some people want a query api because they dont get nosql and some dont. On Tue, Mar 11, 2014 at 8:35 PM, Jonathan Ellis <jbel...@gmail.com> wrote: > 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. > > On Tue, Mar 11, 2014 at 7:16 PM, Russell Bradberry <rbradbe...@gmail.com> > wrote: > > I didn't mean a someone should maintain a fork of Cassandra. More like > > something that could be dropped in. Just like clients have to keep up > with > > the server, a project like this would also. I think if the interface was > > pluggable it would also allow others to expand and come up with new > > interfaces that can possibly expand the user base. One example would be > a > > built in REST interface that doesn't rely on an external web server that > > translates requests to CQL, just drop in a JAR and the interface comes > > available. > > > > This would also lend itself to allow anyone to write an interface in any > > (JVM) language they want, if they want to add external stored procedures > > via this interface then they would be able to. I'm for the removal of > > Thrift in the trunk, but I think there is a use-case for an extensible > > interface. > > > > I still seem to remember there was a few angry users when Avro was > removed. > > > > > > On Tue, Mar 11, 2014 at 8:04 PM, Edward Capriolo <edlinuxg...@gmail.com > >wrote: > > > >> With support officially deprecated that will be the only way to go. If a > >> user wants to add a function to thrift they will have to fork off > >> cassandra, code the function themselves write the internals, manage the > >> internals. I see this as being a very hard task because the server could > >> change rapidly with no regards to them. Also this could cause a > >> proliferation of functions. Could you imagine a thrift server with 300 > >> methods :). This is why I think keeping the support in trunk and > carefully > >> adding things would be sane, but seemingly no one wants to support it at > >> all so a fork is probably in order. > >> > >> > >> On Tue, Mar 11, 2014 at 7:46 PM, Russ Bradberry <rbradbe...@gmail.com > >> >wrote: > >> > >> > I would like to suggest the possibility of having the interface > somewhat > >> > pluggable so another project can provide the Thrift interface as a > drop > >> in > >> > JAR. Thoughts? > >> > > >> > Sent from my iPhone > >> > > >> > > On Mar 11, 2014, at 7:26 PM, Edward Capriolo <edlinuxg...@gmail.com > > > >> > wrote: > >> > > > >> > > If you are using thrift there probably isn't a reason to upgrade to > 2.1 > >> > > > >> > > What? Upgrading gets you performance regardless of your api. > >> > > > >> > > We have already gone from "no new feature" talk to "less enphisis on > >> > > testing". > >> > > > >> > > How comforting. > >> > >> On Tuesday, March 11, 2014, Dave Brosius <dbros...@mebigfatguy.com > > > >> > wrote: > >> > >> > >> > >> +1, > >> > >> > >> > >> altho supporting thrift in 2.1 seems overly conservative. > >> > >> > >> > >> If you are using thrift there probably isn't a reason to upgrade to > >> 2.1, > >> > > in fact doing so will become an increasingly dumb idea as lesser and > >> > lesser > >> > > emphasis will be placed on testing with 2.1+. This would allow us to > >> > > greatly simplify the code footprint in 2.1 > >> > >> > >> > >> > >> > >> > >> > >> > >> > >>> On 03/11/2014 01:00 PM, Jonathan Ellis wrote: > >> > >>> > >> > >>> CQL3 is almost two years old now and has proved to be the better > API > >> > >>> that Cassandra needed. CQL drivers have caught up with and passed > >> the > >> > >>> Thrift ones in terms of features, performance, and usability. > CQL is > >> > >>> easier to learn and more productive than Thrift. > >> > >>> > >> > >>> With static columns and LWT batch support [1] landing in 2.0.6, > and > >> > >>> UDT in 2.1 [2], I don't know of any use cases for Thrift that > can't > >> be > >> > >>> done in CQL. Contrawise, CQL makes many things easy that are > >> > >>> difficult to impossible in Thrift. New development is > overwhelmingly > >> > >>> done using CQL. > >> > >>> > >> > >>> To date we have had an unofficial and poorly defined policy of > "add > >> > >>> support for new features to Thrift when that is 'easy.'" However, > >> > >>> even relatively simple Thrift changes can create subtle > complications > >> > >>> for the rest of the server; for instance, allowing Thrift range > >> > >>> tombtones would make filter conversion for CASSANDRA-6506 more > >> > >>> difficult. > >> > >>> > >> > >>> Thus, I think it's time to officially close the book on Thrift. > We > >> > >>> will retain it for backwards compatibility, but we will commit to > >> > >>> adding no new features or changes to the Thrift API after 2.1.0. > >> This > >> > >>> will help send an unambiguous message to users and eliminate any > >> > >>> remaining confusion from supporting two APIs. If any new use > cases > >> > >>> come to light that can be done with Thrift but not CQL, we will > >> commit > >> > >>> to supporting those in CQL. > >> > >>> > >> > >>> (To a large degree, this merely formalizes what is already de > facto > >> > >>> reality. Most thrift clients have not even added support for > >> > >>> atomic_batch_mutate and cas from 2.0, and popular clients like > >> > >>> Astyanax are migrating to the native protocol.) > >> > >>> > >> > >>> Reasonable? > >> > >>> > >> > >>> [1] https://issues.apache.org/jira/browse/CASSANDRA-6561 > >> > >>> [2] https://issues.apache.org/jira/browse/CASSANDRA-5590 > >> > > > >> > > -- > >> > > Sorry this was sent from mobile. Will do less grammar and spell > check > >> > than > >> > > usual. > >> > > >> > > > > -- > Jonathan Ellis > Project Chair, Apache Cassandra > co-founder, http://www.datastax.com > @spyced >
