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
