I meant to say that thrift provides a facade over the StorageProxy. Without thrift the only user of the cassandra engine would be CQL. At that point the storage engine would likely evolve less usable and plugable. Thrift "has it easy" because it has friendly methods like StorageProxy.batch_mutate() to call. Without that project level support many of the things that plugable_application_x would want to call buried inside a set of interfaces that are designed only with the CQL use case in mind. In a simple case imagine something you want inside cool_new_interface_x is marked private in cassandra. You then need to fork the code, or convince upstream to make it accessible.
BTW I think you know, but I already took a stab at what your describing, pluggable, rest, and jvm language (https://github.com/zznate/intravert-ug) On Tue, Mar 11, 2014 at 8: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. > > > > > >
