Is there a wiki page for the protocol spec? I googled a little but my google fu is off today :(
One nice thing about Thrift is that the interface is human explanative and serializes into a format the computer likes too. With Apache Kafka it is a wire protocol and a lot of developers have developed against it. I think that is because of the documentation that was contributed to the community those developers were able to succeed https://cwiki.apache.org/confluence/display/KAFKA/A+Guide+To+The+Kafka+Protocoland didn't feel left out. I have heard folks having built their platforms to support Cassandra on the thrift interface because they felt it as a tighter integration. I think it was as recently as last week at the Titan Graph DB talk at the NYC C* meetup. I have been recommending CQL3 for a 9 months now so if people have enough heads up time it should be alright but I don't know if the expectation is < when 2.1 is coming out. Lastly, would 2.2 be released as 3.0? I ask because everything new would not be backwards compatible to anyone using the old interface? /******************************************* Joe Stein Founder, Principal Consultant Big Data Open Source Security LLC http://www.stealth.ly Twitter: @allthingshadoop <http://www.twitter.com/allthingshadoop> ********************************************/ On Tue, 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. >
