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. >
