Proposal: freeze Thrift starting with 2.1.0

[Jonathan Ellis]

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

-- 
Jonathan Ellis
Project Chair, Apache Cassandra
co-founder, http://www.datastax.com
@spyced

Re: Proposal: freeze Thrift starting with 2.1.0

[Pavel Yaskevich]

Sounds good to me, I was under an impression that we already did freeze
Thrift tho...


On Tue, Mar 11, 2014 at 10:00 AM, 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
>
> --
> Jonathan Ellis
> Project Chair, Apache Cassandra
> co-founder, http://www.datastax.com
> @spyced
>

Re: Proposal: freeze Thrift starting with 2.1.0

[Jason Brown]

+1

fare thee well, thrift...

Re: Proposal: freeze Thrift starting with 2.1.0

[Brandon Williams]

As someone who has written a thrift wrapper, +1


On Tue, Mar 11, 2014 at 12: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
>
> --
> Jonathan Ellis
> Project Chair, Apache Cassandra
> co-founder, http://www.datastax.com
> @spyced
>

Re: Proposal: freeze Thrift starting with 2.1.0

[sankalp kohli]

RIP Thrift :)
+1 with "We will retain it for backwards compatibility". Hopefully most
people will move out of thrift by 2.1


On Tue, Mar 11, 2014 at 10:18 AM, Brandon Williams  wrote:

> As someone who has written a thrift wrapper, +1
>
>
> On Tue, Mar 11, 2014 at 12: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
> >
> > --
> > Jonathan Ellis
> > Project Chair, Apache Cassandra
> > co-founder, http://www.datastax.com
> > @spyced
> >
>

Re: Proposal: freeze Thrift starting with 2.1.0

[Richard Low]

+1 Although lots of people are still using thrift, it's not a good use of
time to maintain two interfaces when one is clearly better. But, yes,
retaining thrift for some time is important.


On 11 March 2014 17:27, sankalp kohli  wrote:

> RIP Thrift :)
> +1 with "We will retain it for backwards compatibility". Hopefully most
> people will move out of thrift by 2.1
>
>
> On Tue, Mar 11, 2014 at 10:18 AM, Brandon Williams 
> wrote:
>
> > As someone who has written a thrift wrapper, +1
> >
> >
> > On Tue, Mar 11, 2014 at 12: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
> > >
> > > --
> > > Jonathan Ellis
> > > Project Chair, Apache Cassandra
> > > co-founder, http://www.datastax.com
> > > @spyced
> > >
> >
>

Re: Proposal: freeze Thrift starting with 2.1.0

[Gary Dusbabek]

+1



On Tue, Mar 11, 2014 at 12: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
>
> --
> Jonathan Ellis
> Project Chair, Apache Cassandra
> co-founder, http://www.datastax.com
> @spyced
>

Re: Proposal: freeze Thrift starting with 2.1.0

[Mikhail Stepura]

+1

But there is still room for improvement :)

https://issues.apache.org/jira/browse/CASSANDRA-6586

-M

On 3/11/14, 10:00, 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

Re: Proposal: freeze Thrift starting with 2.1.0

[Edward Capriolo]

I am -1. For a few reasons:

Cassandra will be the only database ( that I know of ) where the only
official client to the database will live in source control outside of the
project. I would like some clarity on this development will go on in an
open source fashion. Namely:

1) Who does and how do they do regression testing between the database
server and the client? I.E. are the bugs "on the client" or "in the server"
hard to say when there is no official client.
2) How can an open source apache project depend on a non apache managed
resource to accomplish basic development? IE if there is a cassandra
committer that does not have commit on the driver source code get work done?
3) Who has the "final word" on how a feature is implemented in the native
protocol? Imagine there are two implementations of CQL native-cql-ruby and
native-cql-java. Let's say these libraries have both interpreted the
transport spec differently. One of them has to be broken to fix the
problem. Who resolves this issue and how?

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

Do we mean CQL the transport, CQL the storage engine, CQL the procedure
engine (auto timestamps), or CQL the language? :)  Its hard for thrift to
"do things" when specific "read before write list collection operations"
are impossible to do from a "transport".

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

This is such a loaded statement, most committers have not even "committed"
to adding features to thrift. Take for example "
https://issues.apache.org/jira/browse/CASSANDRA-5435"; adding range
tombstones to thrift was actually a very simple effort. One day I just got
off my couch and went through the simple effort of pushing this along. What
is happening is a self fulfilling prophecy, if everyone throws tons of
development effort in one direction unsurprisingly the other direction lags
behind.



On Tue, Mar 11, 2014 at 1:43 PM, Gary Dusbabek  wrote:

> +1
>
>
>
> On Tue, Mar 11, 2014 at 12: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
> >
> > --
> > Jonathan Ellis
> > Project Chair, Apache Cassandra
> > co-founder, http://www.datastax.com
> > @spyced
> >
>

Re: Proposal: freeze Thrift starting with 2.1.0

[Tyler Hobbs]

On Tue, Mar 11, 2014 at 1:37 PM, Edward Capriolo wrote:

>
> 1) Who does and how do they do regression testing between the database
> server and the client? I.E. are the bugs "on the client" or "in the server"
> hard to say when there is no official client.
>

The native protocol spec is the source of truth.  If Cassandra's behavior
doesn't match the spec, it's a bug.  Likewise for any drivers.  I'm not
sure how this makes it unclear whether a bug is server-side or
client-side.  Maybe an example scenario would be useful?


> 2) How can an open source apache project depend on a non apache managed
> resource to accomplish basic development? IE if there is a cassandra
> committer that does not have commit on the driver source code get work
> done?
>

Cassandra itself already depends on external projects for basic development
(ant, libraries, etc).  The drivers are no different (and most are Apache
licensed themselves).


> 3) Who has the "final word" on how a feature is implemented in the native
> protocol? Imagine there are two implementations of CQL native-cql-ruby and
> native-cql-java. Let's say these libraries have both interpreted the
> transport spec differently. One of them has to be broken to fix the
> problem. Who resolves this issue and how?


This means the spec is ambiguous.  In that case, I imagine the proper
solution would be to create a jira ticket and decide how to resolve the
ambiguity in the spec.

Basically, I think you're looking for a reference implementation instead of
a spec.  Perhaps a reference implementation would be useful, but that's a
separate debate.


-- 
Tyler Hobbs
DataStax 

Re: Proposal: freeze Thrift starting with 2.1.0

[Brian O'Neill]

I¹m +1.  

We¹ve had one foot out the door for a while now.

We are throwing resources at CQL. (e.g. storm-cassandra-cql)  And we are
slowing support for the thrift-based implementation (e.g. storm-cassandra).

Alas poor Thrift, I knew him (well).

-brian

---
Brian O'Neill
Chief Technology Officer

Health Market Science
The Science of Better Results
2700 Horizon Drive € King of Prussia, PA € 19406
M: 215.588.6024 € @boneill42   €
healthmarketscience.com

This information transmitted in this email message is for the intended
recipient only and may contain confidential and/or privileged material. If
you received this email in error and are not the intended recipient, or
the person responsible to deliver it to the intended recipient, please
contact the sender at the email above and delete this email and any
attachments and destroy any copies thereof. Any review, retransmission,
dissemination, copying or other use of, or taking any action in reliance
upon, this information by persons or entities other than the intended
recipient is strictly prohibited.
 






On 3/11/14, 12:27 PM, "sankalp kohli"  wrote:

>RIP Thrift :)
>+1 with "We will retain it for backwards compatibility". Hopefully most
>people will move out of thrift by 2.1
>
>
>On Tue, Mar 11, 2014 at 10:18 AM, Brandon Williams 
>wrote:
>
>> As someone who has written a thrift wrapper, +1
>>
>>
>> On Tue, Mar 11, 2014 at 12: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
>> >
>> > --
>> > Jonathan Ellis
>> > Project Chair, Apache Cassandra
>> > co-founder, http://www.datastax.com
>> > @spyced
>> >
>>

Re: Proposal: freeze Thrift starting with 2.1.0

[Edward Capriolo]

"The native protocol spec is the source of truth.  If Cassandra's behavior
doesn't match the spec, it's a bug.  Likewise for any drivers.  I'm not
sure how this makes it unclear whether a bug is server-side or
client-side.  Maybe an example scenario would be useful?"

In the near future. I am a cassadra committer. I find a bug between
cassanda server and java client driver. For example, the server is sending
an unsigned by the other is expecting a signed byte.

As a cassandra committer I can only change half of the equation. I change
the cassandra server, that would break the ruby-client. That won't work
will it?

My only recourse as a cassandra committer is to go ask some other entity to
change their driver.

"This means the spec is ambiguous.  In that case, I imagine the proper
solution would be to create a jira ticket and decide how to resolve the
ambiguity in the spec."

Yes but then after you change the spec, one client is broken and one is
not. Is one client more "official" then another? Do you change the spec to
match the client with "more users".

Think about mysql. Does it ship with a driver? Yes. Who writes the driver?
mysql. Where is the source code for this driver? Inside the same repository
as the server. Cassandra should be the same way.






On Tue, Mar 11, 2014 at 2:58 PM, Tyler Hobbs  wrote:

> On Tue, Mar 11, 2014 at 1:37 PM, Edward Capriolo  >wrote:
>
> >
> > 1) Who does and how do they do regression testing between the database
> > server and the client? I.E. are the bugs "on the client" or "in the
> server"
> > hard to say when there is no official client.
> >
>
> The native protocol spec is the source of truth.  If Cassandra's behavior
> doesn't match the spec, it's a bug.  Likewise for any drivers.  I'm not
> sure how this makes it unclear whether a bug is server-side or
> client-side.  Maybe an example scenario would be useful?
>
>
> > 2) How can an open source apache project depend on a non apache managed
> > resource to accomplish basic development? IE if there is a cassandra
> > committer that does not have commit on the driver source code get work
> > done?
> >
>
> Cassandra itself already depends on external projects for basic development
> (ant, libraries, etc).  The drivers are no different (and most are Apache
> licensed themselves).
>
>
> > 3) Who has the "final word" on how a feature is implemented in the native
> > protocol? Imagine there are two implementations of CQL native-cql-ruby
> and
> > native-cql-java. Let's say these libraries have both interpreted the
> > transport spec differently. One of them has to be broken to fix the
> > problem. Who resolves this issue and how?
>
>
> This means the spec is ambiguous.  In that case, I imagine the proper
> solution would be to create a jira ticket and decide how to resolve the
> ambiguity in the spec.
>
> Basically, I think you're looking for a reference implementation instead of
> a spec.  Perhaps a reference implementation would be useful, but that's a
> separate debate.
>
>
> --
> Tyler Hobbs
> DataStax 
>

Re: Proposal: freeze Thrift starting with 2.1.0

[Tyler Hobbs]

On Tue, Mar 11, 2014 at 2:24 PM, Edward Capriolo wrote:

> "The native protocol spec is the source of truth.  If Cassandra's behavior
> doesn't match the spec, it's a bug.  Likewise for any drivers.  I'm not
> sure how this makes it unclear whether a bug is server-side or
> client-side.  Maybe an example scenario would be useful?"
>
> In the near future. I am a cassadra committer. I find a bug between
> cassanda server and java client driver. For example, the server is sending
> an unsigned by the other is expecting a signed byte.
>
> As a cassandra committer I can only change half of the equation. I change
> the cassandra server, that would break the ruby-client. That won't work
> will it?
>
> My only recourse as a cassandra committer is to go ask some other entity to
> change their driver.
>

The solution would be:
1. Update the spec (for the current protocol version) to specify that it's
an unsigned byte.  (Perhaps add a note that this will change in the next
protocol version.)
2. In the next version of the protocol, specify that the byte is signed and
change Cassandra's behavior to match this.   Note this change in the
"changes" section of the spec.

This doesn't break existing clients and it allows the behavior to be fixed
with the next protocol version.  (Cassandra also supports multiple versions
of the native protocol, fwiw.)


>
> "This means the spec is ambiguous.  In that case, I imagine the proper
> solution would be to create a jira ticket and decide how to resolve the
> ambiguity in the spec."
>
> Yes but then after you change the spec, one client is broken and one is
> not. Is one client more "official" then another? Do you change the spec to
> match the client with "more users".
>

You change the spec to match whatever Cassandra is doing.  It's not a
matter of what driver is more popular.


>
> Think about mysql. Does it ship with a driver? Yes. Who writes the driver?
> mysql. Where is the source code for this driver? Inside the same repository
> as the server. Cassandra should be the same way.


Other databases treat this issue differently, and there are a set of
tradeoffs.  Mysql's decision may not be the best for Cassandra.


-- 
Tyler Hobbs
DataStax 

Re: Proposal: freeze Thrift starting with 2.1.0

[Edward Capriolo]

"Other databases treat this issue differently, and there are a set of
tradeoffs.  Mysql's decision may not be the best for Cassandra."

Do you know of any other database that does not provide it's own driver?


On Tue, Mar 11, 2014 at 3:55 PM, Tyler Hobbs  wrote:

> On Tue, Mar 11, 2014 at 2:24 PM, Edward Capriolo  >wrote:
>
> > "The native protocol spec is the source of truth.  If Cassandra's
> behavior
> > doesn't match the spec, it's a bug.  Likewise for any drivers.  I'm not
> > sure how this makes it unclear whether a bug is server-side or
> > client-side.  Maybe an example scenario would be useful?"
> >
> > In the near future. I am a cassadra committer. I find a bug between
> > cassanda server and java client driver. For example, the server is
> sending
> > an unsigned by the other is expecting a signed byte.
> >
> > As a cassandra committer I can only change half of the equation. I change
> > the cassandra server, that would break the ruby-client. That won't work
> > will it?
> >
> > My only recourse as a cassandra committer is to go ask some other entity
> to
> > change their driver.
> >
>
> The solution would be:
> 1. Update the spec (for the current protocol version) to specify that it's
> an unsigned byte.  (Perhaps add a note that this will change in the next
> protocol version.)
> 2. In the next version of the protocol, specify that the byte is signed and
> change Cassandra's behavior to match this.   Note this change in the
> "changes" section of the spec.
>
> This doesn't break existing clients and it allows the behavior to be fixed
> with the next protocol version.  (Cassandra also supports multiple versions
> of the native protocol, fwiw.)
>
>
> >
> > "This means the spec is ambiguous.  In that case, I imagine the proper
> > solution would be to create a jira ticket and decide how to resolve the
> > ambiguity in the spec."
> >
> > Yes but then after you change the spec, one client is broken and one is
> > not. Is one client more "official" then another? Do you change the spec
> to
> > match the client with "more users".
> >
>
> You change the spec to match whatever Cassandra is doing.  It's not a
> matter of what driver is more popular.
>
>
> >
> > Think about mysql. Does it ship with a driver? Yes. Who writes the
> driver?
> > mysql. Where is the source code for this driver? Inside the same
> repository
> > as the server. Cassandra should be the same way.
>
>
> Other databases treat this issue differently, and there are a set of
> tradeoffs.  Mysql's decision may not be the best for Cassandra.
>
>
> --
> Tyler Hobbs
> DataStax 
>

Re: Proposal: freeze Thrift starting with 2.1.0

[Brandon Williams]

How about the myriad of thrift wrappers that aren't in-tree either?


On Tue, Mar 11, 2014 at 3:03 PM, Edward Capriolo wrote:

> "Other databases treat this issue differently, and there are a set of
> tradeoffs.  Mysql's decision may not be the best for Cassandra."
>
> Do you know of any other database that does not provide it's own driver?
>
>
> On Tue, Mar 11, 2014 at 3:55 PM, Tyler Hobbs  wrote:
>
> > On Tue, Mar 11, 2014 at 2:24 PM, Edward Capriolo  > >wrote:
> >
> > > "The native protocol spec is the source of truth.  If Cassandra's
> > behavior
> > > doesn't match the spec, it's a bug.  Likewise for any drivers.  I'm not
> > > sure how this makes it unclear whether a bug is server-side or
> > > client-side.  Maybe an example scenario would be useful?"
> > >
> > > In the near future. I am a cassadra committer. I find a bug between
> > > cassanda server and java client driver. For example, the server is
> > sending
> > > an unsigned by the other is expecting a signed byte.
> > >
> > > As a cassandra committer I can only change half of the equation. I
> change
> > > the cassandra server, that would break the ruby-client. That won't work
> > > will it?
> > >
> > > My only recourse as a cassandra committer is to go ask some other
> entity
> > to
> > > change their driver.
> > >
> >
> > The solution would be:
> > 1. Update the spec (for the current protocol version) to specify that
> it's
> > an unsigned byte.  (Perhaps add a note that this will change in the next
> > protocol version.)
> > 2. In the next version of the protocol, specify that the byte is signed
> and
> > change Cassandra's behavior to match this.   Note this change in the
> > "changes" section of the spec.
> >
> > This doesn't break existing clients and it allows the behavior to be
> fixed
> > with the next protocol version.  (Cassandra also supports multiple
> versions
> > of the native protocol, fwiw.)
> >
> >
> > >
> > > "This means the spec is ambiguous.  In that case, I imagine the proper
> > > solution would be to create a jira ticket and decide how to resolve the
> > > ambiguity in the spec."
> > >
> > > Yes but then after you change the spec, one client is broken and one is
> > > not. Is one client more "official" then another? Do you change the spec
> > to
> > > match the client with "more users".
> > >
> >
> > You change the spec to match whatever Cassandra is doing.  It's not a
> > matter of what driver is more popular.
> >
> >
> > >
> > > Think about mysql. Does it ship with a driver? Yes. Who writes the
> > driver?
> > > mysql. Where is the source code for this driver? Inside the same
> > repository
> > > as the server. Cassandra should be the same way.
> >
> >
> > Other databases treat this issue differently, and there are a set of
> > tradeoffs.  Mysql's decision may not be the best for Cassandra.
> >
> >
> > --
> > Tyler Hobbs
> > DataStax 
> >
>

Re: Proposal: freeze Thrift starting with 2.1.0

[Jonathan Ellis]

I hope you're not arguing that Thrift IDL qualifies as a driver,
because that's ridiculous.

On Tue, Mar 11, 2014 at 3:03 PM, Edward Capriolo  wrote:
> "Other databases treat this issue differently, and there are a set of
> tradeoffs.  Mysql's decision may not be the best for Cassandra."
>
> Do you know of any other database that does not provide it's own driver?
>
>
> On Tue, Mar 11, 2014 at 3:55 PM, Tyler Hobbs  wrote:
>
>> On Tue, Mar 11, 2014 at 2:24 PM, Edward Capriolo > >wrote:
>>
>> > "The native protocol spec is the source of truth.  If Cassandra's
>> behavior
>> > doesn't match the spec, it's a bug.  Likewise for any drivers.  I'm not
>> > sure how this makes it unclear whether a bug is server-side or
>> > client-side.  Maybe an example scenario would be useful?"
>> >
>> > In the near future. I am a cassadra committer. I find a bug between
>> > cassanda server and java client driver. For example, the server is
>> sending
>> > an unsigned by the other is expecting a signed byte.
>> >
>> > As a cassandra committer I can only change half of the equation. I change
>> > the cassandra server, that would break the ruby-client. That won't work
>> > will it?
>> >
>> > My only recourse as a cassandra committer is to go ask some other entity
>> to
>> > change their driver.
>> >
>>
>> The solution would be:
>> 1. Update the spec (for the current protocol version) to specify that it's
>> an unsigned byte.  (Perhaps add a note that this will change in the next
>> protocol version.)
>> 2. In the next version of the protocol, specify that the byte is signed and
>> change Cassandra's behavior to match this.   Note this change in the
>> "changes" section of the spec.
>>
>> This doesn't break existing clients and it allows the behavior to be fixed
>> with the next protocol version.  (Cassandra also supports multiple versions
>> of the native protocol, fwiw.)
>>
>>
>> >
>> > "This means the spec is ambiguous.  In that case, I imagine the proper
>> > solution would be to create a jira ticket and decide how to resolve the
>> > ambiguity in the spec."
>> >
>> > Yes but then after you change the spec, one client is broken and one is
>> > not. Is one client more "official" then another? Do you change the spec
>> to
>> > match the client with "more users".
>> >
>>
>> You change the spec to match whatever Cassandra is doing.  It's not a
>> matter of what driver is more popular.
>>
>>
>> >
>> > Think about mysql. Does it ship with a driver? Yes. Who writes the
>> driver?
>> > mysql. Where is the source code for this driver? Inside the same
>> repository
>> > as the server. Cassandra should be the same way.
>>
>>
>> Other databases treat this issue differently, and there are a set of
>> tradeoffs.  Mysql's decision may not be the best for Cassandra.
>>
>>
>> --
>> Tyler Hobbs
>> DataStax 
>>



-- 
Jonathan Ellis
Project Chair, Apache Cassandra
co-founder, http://www.datastax.com
@spyced

Re: Proposal: freeze Thrift starting with 2.1.0

[Edward Capriolo]

"How about the myriad of thrift wrappers that aren't in-tree either?"

How about all the times we trashed hbase saying "hbase treats non java
people like second class citizens"

http://mail-archives.apache.org/mod_mbox/hbase-user/201108.mbox/%3ccafk14gsrnysj_oev2_utwc-+u4ssdmdsmp2dgrst90hoypw...@mail.gmail.com%3E

Nice to see us pulling a total 180.


On Tue, Mar 11, 2014 at 4:09 PM, Brandon Williams  wrote:

> How about the myriad of thrift wrappers that aren't in-tree either?
>
>
> On Tue, Mar 11, 2014 at 3:03 PM, Edward Capriolo  >wrote:
>
> > "Other databases treat this issue differently, and there are a set of
> > tradeoffs.  Mysql's decision may not be the best for Cassandra."
> >
> > Do you know of any other database that does not provide it's own driver?
> >
> >
> > On Tue, Mar 11, 2014 at 3:55 PM, Tyler Hobbs  wrote:
> >
> > > On Tue, Mar 11, 2014 at 2:24 PM, Edward Capriolo <
> edlinuxg...@gmail.com
> > > >wrote:
> > >
> > > > "The native protocol spec is the source of truth.  If Cassandra's
> > > behavior
> > > > doesn't match the spec, it's a bug.  Likewise for any drivers.  I'm
> not
> > > > sure how this makes it unclear whether a bug is server-side or
> > > > client-side.  Maybe an example scenario would be useful?"
> > > >
> > > > In the near future. I am a cassadra committer. I find a bug between
> > > > cassanda server and java client driver. For example, the server is
> > > sending
> > > > an unsigned by the other is expecting a signed byte.
> > > >
> > > > As a cassandra committer I can only change half of the equation. I
> > change
> > > > the cassandra server, that would break the ruby-client. That won't
> work
> > > > will it?
> > > >
> > > > My only recourse as a cassandra committer is to go ask some other
> > entity
> > > to
> > > > change their driver.
> > > >
> > >
> > > The solution would be:
> > > 1. Update the spec (for the current protocol version) to specify that
> > it's
> > > an unsigned byte.  (Perhaps add a note that this will change in the
> next
> > > protocol version.)
> > > 2. In the next version of the protocol, specify that the byte is signed
> > and
> > > change Cassandra's behavior to match this.   Note this change in the
> > > "changes" section of the spec.
> > >
> > > This doesn't break existing clients and it allows the behavior to be
> > fixed
> > > with the next protocol version.  (Cassandra also supports multiple
> > versions
> > > of the native protocol, fwiw.)
> > >
> > >
> > > >
> > > > "This means the spec is ambiguous.  In that case, I imagine the
> proper
> > > > solution would be to create a jira ticket and decide how to resolve
> the
> > > > ambiguity in the spec."
> > > >
> > > > Yes but then after you change the spec, one client is broken and one
> is
> > > > not. Is one client more "official" then another? Do you change the
> spec
> > > to
> > > > match the client with "more users".
> > > >
> > >
> > > You change the spec to match whatever Cassandra is doing.  It's not a
> > > matter of what driver is more popular.
> > >
> > >
> > > >
> > > > Think about mysql. Does it ship with a driver? Yes. Who writes the
> > > driver?
> > > > mysql. Where is the source code for this driver? Inside the same
> > > repository
> > > > as the server. Cassandra should be the same way.
> > >
> > >
> > > Other databases treat this issue differently, and there are a set of
> > > tradeoffs.  Mysql's decision may not be the best for Cassandra.
> > >
> > >
> > > --
> > > Tyler Hobbs
> > > DataStax 
> > >
> >
>

Re: Proposal: freeze Thrift starting with 2.1.0

[Jonathan Ellis]

What part of the native protocol makes any language a second class citizen?

On Tue, Mar 11, 2014 at 3:13 PM, Edward Capriolo  wrote:
> "How about the myriad of thrift wrappers that aren't in-tree either?"
>
> How about all the times we trashed hbase saying "hbase treats non java
> people like second class citizens"
>
> http://mail-archives.apache.org/mod_mbox/hbase-user/201108.mbox/%3ccafk14gsrnysj_oev2_utwc-+u4ssdmdsmp2dgrst90hoypw...@mail.gmail.com%3E
>
> Nice to see us pulling a total 180.
>
>
> On Tue, Mar 11, 2014 at 4:09 PM, Brandon Williams  wrote:
>
>> How about the myriad of thrift wrappers that aren't in-tree either?
>>
>>
>> On Tue, Mar 11, 2014 at 3:03 PM, Edward Capriolo > >wrote:
>>
>> > "Other databases treat this issue differently, and there are a set of
>> > tradeoffs.  Mysql's decision may not be the best for Cassandra."
>> >
>> > Do you know of any other database that does not provide it's own driver?
>> >
>> >
>> > On Tue, Mar 11, 2014 at 3:55 PM, Tyler Hobbs  wrote:
>> >
>> > > On Tue, Mar 11, 2014 at 2:24 PM, Edward Capriolo <
>> edlinuxg...@gmail.com
>> > > >wrote:
>> > >
>> > > > "The native protocol spec is the source of truth.  If Cassandra's
>> > > behavior
>> > > > doesn't match the spec, it's a bug.  Likewise for any drivers.  I'm
>> not
>> > > > sure how this makes it unclear whether a bug is server-side or
>> > > > client-side.  Maybe an example scenario would be useful?"
>> > > >
>> > > > In the near future. I am a cassadra committer. I find a bug between
>> > > > cassanda server and java client driver. For example, the server is
>> > > sending
>> > > > an unsigned by the other is expecting a signed byte.
>> > > >
>> > > > As a cassandra committer I can only change half of the equation. I
>> > change
>> > > > the cassandra server, that would break the ruby-client. That won't
>> work
>> > > > will it?
>> > > >
>> > > > My only recourse as a cassandra committer is to go ask some other
>> > entity
>> > > to
>> > > > change their driver.
>> > > >
>> > >
>> > > The solution would be:
>> > > 1. Update the spec (for the current protocol version) to specify that
>> > it's
>> > > an unsigned byte.  (Perhaps add a note that this will change in the
>> next
>> > > protocol version.)
>> > > 2. In the next version of the protocol, specify that the byte is signed
>> > and
>> > > change Cassandra's behavior to match this.   Note this change in the
>> > > "changes" section of the spec.
>> > >
>> > > This doesn't break existing clients and it allows the behavior to be
>> > fixed
>> > > with the next protocol version.  (Cassandra also supports multiple
>> > versions
>> > > of the native protocol, fwiw.)
>> > >
>> > >
>> > > >
>> > > > "This means the spec is ambiguous.  In that case, I imagine the
>> proper
>> > > > solution would be to create a jira ticket and decide how to resolve
>> the
>> > > > ambiguity in the spec."
>> > > >
>> > > > Yes but then after you change the spec, one client is broken and one
>> is
>> > > > not. Is one client more "official" then another? Do you change the
>> spec
>> > > to
>> > > > match the client with "more users".
>> > > >
>> > >
>> > > You change the spec to match whatever Cassandra is doing.  It's not a
>> > > matter of what driver is more popular.
>> > >
>> > >
>> > > >
>> > > > Think about mysql. Does it ship with a driver? Yes. Who writes the
>> > > driver?
>> > > > mysql. Where is the source code for this driver? Inside the same
>> > > repository
>> > > > as the server. Cassandra should be the same way.
>> > >
>> > >
>> > > Other databases treat this issue differently, and there are a set of
>> > > tradeoffs.  Mysql's decision may not be the best for Cassandra.
>> > >
>> > >
>> > > --
>> > > Tyler Hobbs
>> > > DataStax 
>> > >
>> >
>>



-- 
Jonathan Ellis
Project Chair, Apache Cassandra
co-founder, http://www.datastax.com
@spyced

Re: Proposal: freeze Thrift starting with 2.1.0

[Brandon Williams]

I am confused how any of this is relevant to Jonathan's original email.


On Tue, Mar 11, 2014 at 3:13 PM, Edward Capriolo wrote:

> "How about the myriad of thrift wrappers that aren't in-tree either?"
>
> How about all the times we trashed hbase saying "hbase treats non java
> people like second class citizens"
>
>
> http://mail-archives.apache.org/mod_mbox/hbase-user/201108.mbox/%3ccafk14gsrnysj_oev2_utwc-+u4ssdmdsmp2dgrst90hoypw...@mail.gmail.com%3E
>
> Nice to see us pulling a total 180.
>
>
> On Tue, Mar 11, 2014 at 4:09 PM, Brandon Williams 
> wrote:
>
> > How about the myriad of thrift wrappers that aren't in-tree either?
> >
> >
> > On Tue, Mar 11, 2014 at 3:03 PM, Edward Capriolo  > >wrote:
> >
> > > "Other databases treat this issue differently, and there are a set of
> > > tradeoffs.  Mysql's decision may not be the best for Cassandra."
> > >
> > > Do you know of any other database that does not provide it's own
> driver?
> > >
> > >
> > > On Tue, Mar 11, 2014 at 3:55 PM, Tyler Hobbs 
> wrote:
> > >
> > > > On Tue, Mar 11, 2014 at 2:24 PM, Edward Capriolo <
> > edlinuxg...@gmail.com
> > > > >wrote:
> > > >
> > > > > "The native protocol spec is the source of truth.  If Cassandra's
> > > > behavior
> > > > > doesn't match the spec, it's a bug.  Likewise for any drivers.  I'm
> > not
> > > > > sure how this makes it unclear whether a bug is server-side or
> > > > > client-side.  Maybe an example scenario would be useful?"
> > > > >
> > > > > In the near future. I am a cassadra committer. I find a bug between
> > > > > cassanda server and java client driver. For example, the server is
> > > > sending
> > > > > an unsigned by the other is expecting a signed byte.
> > > > >
> > > > > As a cassandra committer I can only change half of the equation. I
> > > change
> > > > > the cassandra server, that would break the ruby-client. That won't
> > work
> > > > > will it?
> > > > >
> > > > > My only recourse as a cassandra committer is to go ask some other
> > > entity
> > > > to
> > > > > change their driver.
> > > > >
> > > >
> > > > The solution would be:
> > > > 1. Update the spec (for the current protocol version) to specify that
> > > it's
> > > > an unsigned byte.  (Perhaps add a note that this will change in the
> > next
> > > > protocol version.)
> > > > 2. In the next version of the protocol, specify that the byte is
> signed
> > > and
> > > > change Cassandra's behavior to match this.   Note this change in the
> > > > "changes" section of the spec.
> > > >
> > > > This doesn't break existing clients and it allows the behavior to be
> > > fixed
> > > > with the next protocol version.  (Cassandra also supports multiple
> > > versions
> > > > of the native protocol, fwiw.)
> > > >
> > > >
> > > > >
> > > > > "This means the spec is ambiguous.  In that case, I imagine the
> > proper
> > > > > solution would be to create a jira ticket and decide how to resolve
> > the
> > > > > ambiguity in the spec."
> > > > >
> > > > > Yes but then after you change the spec, one client is broken and
> one
> > is
> > > > > not. Is one client more "official" then another? Do you change the
> > spec
> > > > to
> > > > > match the client with "more users".
> > > > >
> > > >
> > > > You change the spec to match whatever Cassandra is doing.  It's not a
> > > > matter of what driver is more popular.
> > > >
> > > >
> > > > >
> > > > > Think about mysql. Does it ship with a driver? Yes. Who writes the
> > > > driver?
> > > > > mysql. Where is the source code for this driver? Inside the same
> > > > repository
> > > > > as the server. Cassandra should be the same way.
> > > >
> > > >
> > > > Other databases treat this issue differently, and there are a set of
> > > > tradeoffs.  Mysql's decision may not be the best for Cassandra.
> > > >
> > > >
> > > > --
> > > > Tyler Hobbs
> > > > DataStax 
> > > >
> > >
> >
>

Re: Proposal: freeze Thrift starting with 2.1.0

[Edward Capriolo]

If only some languages have support via a third party entity everyone who
does not have support is a second class citizen.

On Tue, Mar 11, 2014 at 4:16 PM, Jonathan Ellis  wrote:

> What part of the native protocol makes any language a second class citizen?
>
> On Tue, Mar 11, 2014 at 3:13 PM, Edward Capriolo 
> wrote:
> > "How about the myriad of thrift wrappers that aren't in-tree either?"
> >
> > How about all the times we trashed hbase saying "hbase treats non java
> > people like second class citizens"
> >
> >
> http://mail-archives.apache.org/mod_mbox/hbase-user/201108.mbox/%3ccafk14gsrnysj_oev2_utwc-+u4ssdmdsmp2dgrst90hoypw...@mail.gmail.com%3E
> >
> > Nice to see us pulling a total 180.
> >
> >
> > On Tue, Mar 11, 2014 at 4:09 PM, Brandon Williams 
> wrote:
> >
> >> How about the myriad of thrift wrappers that aren't in-tree either?
> >>
> >>
> >> On Tue, Mar 11, 2014 at 3:03 PM, Edward Capriolo  >> >wrote:
> >>
> >> > "Other databases treat this issue differently, and there are a set of
> >> > tradeoffs.  Mysql's decision may not be the best for Cassandra."
> >> >
> >> > Do you know of any other database that does not provide it's own
> driver?
> >> >
> >> >
> >> > On Tue, Mar 11, 2014 at 3:55 PM, Tyler Hobbs 
> wrote:
> >> >
> >> > > On Tue, Mar 11, 2014 at 2:24 PM, Edward Capriolo <
> >> edlinuxg...@gmail.com
> >> > > >wrote:
> >> > >
> >> > > > "The native protocol spec is the source of truth.  If Cassandra's
> >> > > behavior
> >> > > > doesn't match the spec, it's a bug.  Likewise for any drivers.
>  I'm
> >> not
> >> > > > sure how this makes it unclear whether a bug is server-side or
> >> > > > client-side.  Maybe an example scenario would be useful?"
> >> > > >
> >> > > > In the near future. I am a cassadra committer. I find a bug
> between
> >> > > > cassanda server and java client driver. For example, the server is
> >> > > sending
> >> > > > an unsigned by the other is expecting a signed byte.
> >> > > >
> >> > > > As a cassandra committer I can only change half of the equation. I
> >> > change
> >> > > > the cassandra server, that would break the ruby-client. That won't
> >> work
> >> > > > will it?
> >> > > >
> >> > > > My only recourse as a cassandra committer is to go ask some other
> >> > entity
> >> > > to
> >> > > > change their driver.
> >> > > >
> >> > >
> >> > > The solution would be:
> >> > > 1. Update the spec (for the current protocol version) to specify
> that
> >> > it's
> >> > > an unsigned byte.  (Perhaps add a note that this will change in the
> >> next
> >> > > protocol version.)
> >> > > 2. In the next version of the protocol, specify that the byte is
> signed
> >> > and
> >> > > change Cassandra's behavior to match this.   Note this change in the
> >> > > "changes" section of the spec.
> >> > >
> >> > > This doesn't break existing clients and it allows the behavior to be
> >> > fixed
> >> > > with the next protocol version.  (Cassandra also supports multiple
> >> > versions
> >> > > of the native protocol, fwiw.)
> >> > >
> >> > >
> >> > > >
> >> > > > "This means the spec is ambiguous.  In that case, I imagine the
> >> proper
> >> > > > solution would be to create a jira ticket and decide how to
> resolve
> >> the
> >> > > > ambiguity in the spec."
> >> > > >
> >> > > > Yes but then after you change the spec, one client is broken and
> one
> >> is
> >> > > > not. Is one client more "official" then another? Do you change the
> >> spec
> >> > > to
> >> > > > match the client with "more users".
> >> > > >
> >> > >
> >> > > You change the spec to match whatever Cassandra is doing.  It's not
> a
> >> > > matter of what driver is more popular.
> >> > >
> >> > >
> >> > > >
> >> > > > Think about mysql. Does it ship with a driver? Yes. Who writes the
> >> > > driver?
> >> > > > mysql. Where is the source code for this driver? Inside the same
> >> > > repository
> >> > > > as the server. Cassandra should be the same way.
> >> > >
> >> > >
> >> > > Other databases treat this issue differently, and there are a set of
> >> > > tradeoffs.  Mysql's decision may not be the best for Cassandra.
> >> > >
> >> > >
> >> > > --
> >> > > Tyler Hobbs
> >> > > DataStax 
> >> > >
> >> >
> >>
>
>
>
> --
> Jonathan Ellis
> Project Chair, Apache Cassandra
> co-founder, http://www.datastax.com
> @spyced
>

Re: Proposal: freeze Thrift starting with 2.1.0

[Edward Capriolo]

"I am confused how any of this is relevant to Jonathan's original email."

Here is how:

I believe if native is the new official transport, Cassandra should include
the Java driver source code with the project.

Without the driver code inside the project how can someone use/develop the
software.


On Tue, Mar 11, 2014 at 4:24 PM, Brandon Williams  wrote:

> I am confused how any of this is relevant to Jonathan's original email.
>
>
> On Tue, Mar 11, 2014 at 3:13 PM, Edward Capriolo  >wrote:
>
> > "How about the myriad of thrift wrappers that aren't in-tree either?"
> >
> > How about all the times we trashed hbase saying "hbase treats non java
> > people like second class citizens"
> >
> >
> >
> http://mail-archives.apache.org/mod_mbox/hbase-user/201108.mbox/%3ccafk14gsrnysj_oev2_utwc-+u4ssdmdsmp2dgrst90hoypw...@mail.gmail.com%3E
> >
> > Nice to see us pulling a total 180.
> >
> >
> > On Tue, Mar 11, 2014 at 4:09 PM, Brandon Williams 
> > wrote:
> >
> > > How about the myriad of thrift wrappers that aren't in-tree either?
> > >
> > >
> > > On Tue, Mar 11, 2014 at 3:03 PM, Edward Capriolo <
> edlinuxg...@gmail.com
> > > >wrote:
> > >
> > > > "Other databases treat this issue differently, and there are a set of
> > > > tradeoffs.  Mysql's decision may not be the best for Cassandra."
> > > >
> > > > Do you know of any other database that does not provide it's own
> > driver?
> > > >
> > > >
> > > > On Tue, Mar 11, 2014 at 3:55 PM, Tyler Hobbs 
> > wrote:
> > > >
> > > > > On Tue, Mar 11, 2014 at 2:24 PM, Edward Capriolo <
> > > edlinuxg...@gmail.com
> > > > > >wrote:
> > > > >
> > > > > > "The native protocol spec is the source of truth.  If Cassandra's
> > > > > behavior
> > > > > > doesn't match the spec, it's a bug.  Likewise for any drivers.
>  I'm
> > > not
> > > > > > sure how this makes it unclear whether a bug is server-side or
> > > > > > client-side.  Maybe an example scenario would be useful?"
> > > > > >
> > > > > > In the near future. I am a cassadra committer. I find a bug
> between
> > > > > > cassanda server and java client driver. For example, the server
> is
> > > > > sending
> > > > > > an unsigned by the other is expecting a signed byte.
> > > > > >
> > > > > > As a cassandra committer I can only change half of the equation.
> I
> > > > change
> > > > > > the cassandra server, that would break the ruby-client. That
> won't
> > > work
> > > > > > will it?
> > > > > >
> > > > > > My only recourse as a cassandra committer is to go ask some other
> > > > entity
> > > > > to
> > > > > > change their driver.
> > > > > >
> > > > >
> > > > > The solution would be:
> > > > > 1. Update the spec (for the current protocol version) to specify
> that
> > > > it's
> > > > > an unsigned byte.  (Perhaps add a note that this will change in the
> > > next
> > > > > protocol version.)
> > > > > 2. In the next version of the protocol, specify that the byte is
> > signed
> > > > and
> > > > > change Cassandra's behavior to match this.   Note this change in
> the
> > > > > "changes" section of the spec.
> > > > >
> > > > > This doesn't break existing clients and it allows the behavior to
> be
> > > > fixed
> > > > > with the next protocol version.  (Cassandra also supports multiple
> > > > versions
> > > > > of the native protocol, fwiw.)
> > > > >
> > > > >
> > > > > >
> > > > > > "This means the spec is ambiguous.  In that case, I imagine the
> > > proper
> > > > > > solution would be to create a jira ticket and decide how to
> resolve
> > > the
> > > > > > ambiguity in the spec."
> > > > > >
> > > > > > Yes but then after you change the spec, one client is broken and
> > one
> > > is
> > > > > > not. Is one client more "official" then another? Do you change
> the
> > > spec
> > > > > to
> > > > > > match the client with "more users".
> > > > > >
> > > > >
> > > > > You change the spec to match whatever Cassandra is doing.  It's
> not a
> > > > > matter of what driver is more popular.
> > > > >
> > > > >
> > > > > >
> > > > > > Think about mysql. Does it ship with a driver? Yes. Who writes
> the
> > > > > driver?
> > > > > > mysql. Where is the source code for this driver? Inside the same
> > > > > repository
> > > > > > as the server. Cassandra should be the same way.
> > > > >
> > > > >
> > > > > Other databases treat this issue differently, and there are a set
> of
> > > > > tradeoffs.  Mysql's decision may not be the best for Cassandra.
> > > > >
> > > > >
> > > > > --
> > > > > Tyler Hobbs
> > > > > DataStax 
> > > > >
> > > >
> > >
> >
>

Re: Proposal: freeze Thrift starting with 2.1.0

[Jonathan Ellis]

Nobody can seriously use or develop against Cassandra with only the
raw Thrift generated code either, so I agree that this is really a
different discussion.

On Tue, Mar 11, 2014 at 3:38 PM, Edward Capriolo  wrote:
> "I am confused how any of this is relevant to Jonathan's original email."
>
> Here is how:
>
> I believe if native is the new official transport, Cassandra should include
> the Java driver source code with the project.
>
> Without the driver code inside the project how can someone use/develop the
> software.
>
>
> On Tue, Mar 11, 2014 at 4:24 PM, Brandon Williams  wrote:
>
>> I am confused how any of this is relevant to Jonathan's original email.
>>
>>
>> On Tue, Mar 11, 2014 at 3:13 PM, Edward Capriolo > >wrote:
>>
>> > "How about the myriad of thrift wrappers that aren't in-tree either?"
>> >
>> > How about all the times we trashed hbase saying "hbase treats non java
>> > people like second class citizens"
>> >
>> >
>> >
>> http://mail-archives.apache.org/mod_mbox/hbase-user/201108.mbox/%3ccafk14gsrnysj_oev2_utwc-+u4ssdmdsmp2dgrst90hoypw...@mail.gmail.com%3E
>> >
>> > Nice to see us pulling a total 180.
>> >
>> >
>> > On Tue, Mar 11, 2014 at 4:09 PM, Brandon Williams 
>> > wrote:
>> >
>> > > How about the myriad of thrift wrappers that aren't in-tree either?
>> > >
>> > >
>> > > On Tue, Mar 11, 2014 at 3:03 PM, Edward Capriolo <
>> edlinuxg...@gmail.com
>> > > >wrote:
>> > >
>> > > > "Other databases treat this issue differently, and there are a set of
>> > > > tradeoffs.  Mysql's decision may not be the best for Cassandra."
>> > > >
>> > > > Do you know of any other database that does not provide it's own
>> > driver?
>> > > >
>> > > >
>> > > > On Tue, Mar 11, 2014 at 3:55 PM, Tyler Hobbs 
>> > wrote:
>> > > >
>> > > > > On Tue, Mar 11, 2014 at 2:24 PM, Edward Capriolo <
>> > > edlinuxg...@gmail.com
>> > > > > >wrote:
>> > > > >
>> > > > > > "The native protocol spec is the source of truth.  If Cassandra's
>> > > > > behavior
>> > > > > > doesn't match the spec, it's a bug.  Likewise for any drivers.
>>  I'm
>> > > not
>> > > > > > sure how this makes it unclear whether a bug is server-side or
>> > > > > > client-side.  Maybe an example scenario would be useful?"
>> > > > > >
>> > > > > > In the near future. I am a cassadra committer. I find a bug
>> between
>> > > > > > cassanda server and java client driver. For example, the server
>> is
>> > > > > sending
>> > > > > > an unsigned by the other is expecting a signed byte.
>> > > > > >
>> > > > > > As a cassandra committer I can only change half of the equation.
>> I
>> > > > change
>> > > > > > the cassandra server, that would break the ruby-client. That
>> won't
>> > > work
>> > > > > > will it?
>> > > > > >
>> > > > > > My only recourse as a cassandra committer is to go ask some other
>> > > > entity
>> > > > > to
>> > > > > > change their driver.
>> > > > > >
>> > > > >
>> > > > > The solution would be:
>> > > > > 1. Update the spec (for the current protocol version) to specify
>> that
>> > > > it's
>> > > > > an unsigned byte.  (Perhaps add a note that this will change in the
>> > > next
>> > > > > protocol version.)
>> > > > > 2. In the next version of the protocol, specify that the byte is
>> > signed
>> > > > and
>> > > > > change Cassandra's behavior to match this.   Note this change in
>> the
>> > > > > "changes" section of the spec.
>> > > > >
>> > > > > This doesn't break existing clients and it allows the behavior to
>> be
>> > > > fixed
>> > > > > with the next protocol version.  (Cassandra also supports multiple
>> > > > versions
>> > > > > of the native protocol, fwiw.)
>> > > > >
>> > > > >
>> > > > > >
>> > > > > > "This means the spec is ambiguous.  In that case, I imagine the
>> > > proper
>> > > > > > solution would be to create a jira ticket and decide how to
>> resolve
>> > > the
>> > > > > > ambiguity in the spec."
>> > > > > >
>> > > > > > Yes but then after you change the spec, one client is broken and
>> > one
>> > > is
>> > > > > > not. Is one client more "official" then another? Do you change
>> the
>> > > spec
>> > > > > to
>> > > > > > match the client with "more users".
>> > > > > >
>> > > > >
>> > > > > You change the spec to match whatever Cassandra is doing.  It's
>> not a
>> > > > > matter of what driver is more popular.
>> > > > >
>> > > > >
>> > > > > >
>> > > > > > Think about mysql. Does it ship with a driver? Yes. Who writes
>> the
>> > > > > driver?
>> > > > > > mysql. Where is the source code for this driver? Inside the same
>> > > > > repository
>> > > > > > as the server. Cassandra should be the same way.
>> > > > >
>> > > > >
>> > > > > Other databases treat this issue differently, and there are a set
>> of
>> > > > > tradeoffs.  Mysql's decision may not be the best for Cassandra.
>> > > > >
>> > > > >
>> > > > > --
>> > > > > Tyler Hobbs
>> > > > > DataStax 
>> > > > >
>> > > >
>> > >
>> >
>>



-- 
Jonathan Ellis
Project Chair, Apache Cassandra
co-founder, http://www.data

Re: Proposal: freeze Thrift starting with 2.1.0

[Edward Capriolo]

I will move on. I --coincidentally-- happen to have just added a thrift
feature
http://www.edwardcapriolo.com/roller/edwardcapriolo/entry/thrift_isn_t_going_anywhere.
I also have 2-3 jira's open to add thrift features.

Seems like an interesting time to call a vote that effectively adds
language that stops me from doing what I want to do.


On Tue, Mar 11, 2014 at 4:43 PM, Jonathan Ellis  wrote:

> Nobody can seriously use or develop against Cassandra with only the
> raw Thrift generated code either, so I agree that this is really a
> different discussion.
>
> On Tue, Mar 11, 2014 at 3:38 PM, Edward Capriolo 
> wrote:
> > "I am confused how any of this is relevant to Jonathan's original email."
> >
> > Here is how:
> >
> > I believe if native is the new official transport, Cassandra should
> include
> > the Java driver source code with the project.
> >
> > Without the driver code inside the project how can someone use/develop
> the
> > software.
> >
> >
> > On Tue, Mar 11, 2014 at 4:24 PM, Brandon Williams 
> wrote:
> >
> >> I am confused how any of this is relevant to Jonathan's original email.
> >>
> >>
> >> On Tue, Mar 11, 2014 at 3:13 PM, Edward Capriolo  >> >wrote:
> >>
> >> > "How about the myriad of thrift wrappers that aren't in-tree either?"
> >> >
> >> > How about all the times we trashed hbase saying "hbase treats non java
> >> > people like second class citizens"
> >> >
> >> >
> >> >
> >>
> http://mail-archives.apache.org/mod_mbox/hbase-user/201108.mbox/%3ccafk14gsrnysj_oev2_utwc-+u4ssdmdsmp2dgrst90hoypw...@mail.gmail.com%3E
> >> >
> >> > Nice to see us pulling a total 180.
> >> >
> >> >
> >> > On Tue, Mar 11, 2014 at 4:09 PM, Brandon Williams 
> >> > wrote:
> >> >
> >> > > How about the myriad of thrift wrappers that aren't in-tree either?
> >> > >
> >> > >
> >> > > On Tue, Mar 11, 2014 at 3:03 PM, Edward Capriolo <
> >> edlinuxg...@gmail.com
> >> > > >wrote:
> >> > >
> >> > > > "Other databases treat this issue differently, and there are a
> set of
> >> > > > tradeoffs.  Mysql's decision may not be the best for Cassandra."
> >> > > >
> >> > > > Do you know of any other database that does not provide it's own
> >> > driver?
> >> > > >
> >> > > >
> >> > > > On Tue, Mar 11, 2014 at 3:55 PM, Tyler Hobbs 
> >> > wrote:
> >> > > >
> >> > > > > On Tue, Mar 11, 2014 at 2:24 PM, Edward Capriolo <
> >> > > edlinuxg...@gmail.com
> >> > > > > >wrote:
> >> > > > >
> >> > > > > > "The native protocol spec is the source of truth.  If
> Cassandra's
> >> > > > > behavior
> >> > > > > > doesn't match the spec, it's a bug.  Likewise for any drivers.
> >>  I'm
> >> > > not
> >> > > > > > sure how this makes it unclear whether a bug is server-side or
> >> > > > > > client-side.  Maybe an example scenario would be useful?"
> >> > > > > >
> >> > > > > > In the near future. I am a cassadra committer. I find a bug
> >> between
> >> > > > > > cassanda server and java client driver. For example, the
> server
> >> is
> >> > > > > sending
> >> > > > > > an unsigned by the other is expecting a signed byte.
> >> > > > > >
> >> > > > > > As a cassandra committer I can only change half of the
> equation.
> >> I
> >> > > > change
> >> > > > > > the cassandra server, that would break the ruby-client. That
> >> won't
> >> > > work
> >> > > > > > will it?
> >> > > > > >
> >> > > > > > My only recourse as a cassandra committer is to go ask some
> other
> >> > > > entity
> >> > > > > to
> >> > > > > > change their driver.
> >> > > > > >
> >> > > > >
> >> > > > > The solution would be:
> >> > > > > 1. Update the spec (for the current protocol version) to specify
> >> that
> >> > > > it's
> >> > > > > an unsigned byte.  (Perhaps add a note that this will change in
> the
> >> > > next
> >> > > > > protocol version.)
> >> > > > > 2. In the next version of the protocol, specify that the byte is
> >> > signed
> >> > > > and
> >> > > > > change Cassandra's behavior to match this.   Note this change in
> >> the
> >> > > > > "changes" section of the spec.
> >> > > > >
> >> > > > > This doesn't break existing clients and it allows the behavior
> to
> >> be
> >> > > > fixed
> >> > > > > with the next protocol version.  (Cassandra also supports
> multiple
> >> > > > versions
> >> > > > > of the native protocol, fwiw.)
> >> > > > >
> >> > > > >
> >> > > > > >
> >> > > > > > "This means the spec is ambiguous.  In that case, I imagine
> the
> >> > > proper
> >> > > > > > solution would be to create a jira ticket and decide how to
> >> resolve
> >> > > the
> >> > > > > > ambiguity in the spec."
> >> > > > > >
> >> > > > > > Yes but then after you change the spec, one client is broken
> and
> >> > one
> >> > > is
> >> > > > > > not. Is one client more "official" then another? Do you change
> >> the
> >> > > spec
> >> > > > > to
> >> > > > > > match the client with "more users".
> >> > > > > >
> >> > > > >
> >> > > > > You change the spec to match whatever Cassandra is doing.  It's
> >> not a
> >> > > > > matter of what driver is more popular.
> >>

Re: Proposal: freeze Thrift starting with 2.1.0

[Zhong Li]

Sorry, I am not your team. But I do care native api.

A native api has much more impacts than anybody expected. Few reasons list here,
1. Using native api can help understand Cassandra DB much deeper.
2. Native api can support unusual customer with special needs. In some cases, 
basic and high performance requires few api calls and less code, native code 
provide this possible. I have a embed system with Oracle native C api code 
still use today.
3. Earlier Cassandra adaptors will hate to move to CQL even it "looks" better 
and "seems" beauty, but it requires major code changes.
4. Without native api will lost potential support other drivers, who knows, 
somebody may implement other QL, or may be JDBC extends feature to support 
Cassandra. 
5. Without native api, Cassandra has pressure to develop a standard driver for 
each language as Edward Capriolo perceived  

I believe Cassandra should have low level native api regardless CQL or anything 
new QLs in the future. This will save earlier customer's investments and give 
Cassandra a much broad future. CQL looks nice today, doesn't means good for 
tomorrow.


Regards,

Zhong Li


On Mar 11, 2014, at 4:43 PM, Jonathan Ellis wrote:

> Nobody can seriously use or develop against Cassandra with only the
> raw Thrift generated code either, so I agree that this is really a
> different discussion.
> 
> On Tue, Mar 11, 2014 at 3:38 PM, Edward Capriolo  
> wrote:
>> "I am confused how any of this is relevant to Jonathan's original email."
>> 
>> Here is how:
>> 
>> I believe if native is the new official transport, Cassandra should include
>> the Java driver source code with the project.
>> 
>> Without the driver code inside the project how can someone use/develop the
>> software.
>> 
>> 
>> On Tue, Mar 11, 2014 at 4:24 PM, Brandon Williams  wrote:
>> 
>>> I am confused how any of this is relevant to Jonathan's original email.
>>> 
>>> 
>>> On Tue, Mar 11, 2014 at 3:13 PM, Edward Capriolo >>> wrote:
>>> 
 "How about the myriad of thrift wrappers that aren't in-tree either?"
 
 How about all the times we trashed hbase saying "hbase treats non java
 people like second class citizens"
 
 
 
>>> http://mail-archives.apache.org/mod_mbox/hbase-user/201108.mbox/%3ccafk14gsrnysj_oev2_utwc-+u4ssdmdsmp2dgrst90hoypw...@mail.gmail.com%3E
 
 Nice to see us pulling a total 180.
 
 
 On Tue, Mar 11, 2014 at 4:09 PM, Brandon Williams 
 wrote:
 
> How about the myriad of thrift wrappers that aren't in-tree either?
> 
> 
> On Tue, Mar 11, 2014 at 3:03 PM, Edward Capriolo <
>>> edlinuxg...@gmail.com
>> wrote:
> 
>> "Other databases treat this issue differently, and there are a set of
>> tradeoffs.  Mysql's decision may not be the best for Cassandra."
>> 
>> Do you know of any other database that does not provide it's own
 driver?
>> 
>> 
>> On Tue, Mar 11, 2014 at 3:55 PM, Tyler Hobbs 
 wrote:
>> 
>>> On Tue, Mar 11, 2014 at 2:24 PM, Edward Capriolo <
> edlinuxg...@gmail.com
 wrote:
>>> 
 "The native protocol spec is the source of truth.  If Cassandra's
>>> behavior
 doesn't match the spec, it's a bug.  Likewise for any drivers.
>>> I'm
> not
 sure how this makes it unclear whether a bug is server-side or
 client-side.  Maybe an example scenario would be useful?"
 
 In the near future. I am a cassadra committer. I find a bug
>>> between
 cassanda server and java client driver. For example, the server
>>> is
>>> sending
 an unsigned by the other is expecting a signed byte.
 
 As a cassandra committer I can only change half of the equation.
>>> I
>> change
 the cassandra server, that would break the ruby-client. That
>>> won't
> work
 will it?
 
 My only recourse as a cassandra committer is to go ask some other
>> entity
>>> to
 change their driver.
 
>>> 
>>> The solution would be:
>>> 1. Update the spec (for the current protocol version) to specify
>>> that
>> it's
>>> an unsigned byte.  (Perhaps add a note that this will change in the
> next
>>> protocol version.)
>>> 2. In the next version of the protocol, specify that the byte is
 signed
>> and
>>> change Cassandra's behavior to match this.   Note this change in
>>> the
>>> "changes" section of the spec.
>>> 
>>> This doesn't break existing clients and it allows the behavior to
>>> be
>> fixed
>>> with the next protocol version.  (Cassandra also supports multiple
>> versions
>>> of the native protocol, fwiw.)
>>> 
>>> 
 
 "This means the spec is ambiguous.  In that case, I imagine the
> proper
 solution would be to create a jira ticket and decide how to
>>> resolve
> the
 ambiguity in the spec."
 
 Yes but t

Re: Proposal: freeze Thrift starting with 2.1.0

[Dave Brosius]

+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

Re: Proposal: freeze Thrift starting with 2.1.0

[Brandon Williams]

On Tue, Mar 11, 2014 at 6:53 PM, Joe Stein  wrote:

> Is there a wiki page for the protocol spec? I googled a little but my
> google fu is off today :(
>
>
We keep that in-tree:
https://github.com/apache/cassandra/blob/trunk/doc/native_protocol_v2.spec

Re: Proposal: freeze Thrift starting with 2.1.0

[Edward Capriolo]

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

Re: Proposal: freeze Thrift starting with 2.1.0

[Edward Capriolo]

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

Re: Proposal: freeze Thrift starting with 2.1.0

[Russell Bradberry]

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

Re: Proposal: freeze Thrift starting with 2.1.0

[Joe Stein]

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 
/


On Tue, Mar 11, 2014 at 7:26 PM, Edward Capriolo 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  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.
>

Re: Proposal: freeze Thrift starting with 2.1.0

[Edward Capriolo]

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

Re: Proposal: freeze Thrift starting with 2.1.0

[Jacob Rhoden]

If there is someone with the time and resources to fork and keep thrift up to 
date, they could assumedly just push thrift updates back into master. i.e. If 
the goal is to reduce maintenance overhead for the core secs that's fine, but 
the it doesn't need to be frozen right? Perhaps it must be marked frozen for 
anyone with time and resources to continue enhancements to step out of the 
woodworks? If no one does, it stays frozen.

__
Sent from iPhone

> On 12 Mar 2014, at 8:04 am, Edward Capriolo  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 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 
>>> 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 
>> 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.
>> 

Re: Proposal: freeze Thrift starting with 2.1.0

[Joe Stein]

ah! cool, thanks!

On Tue, Mar 11, 2014 at 7:55 PM, Brandon Williams  wrote:

> On Tue, Mar 11, 2014 at 6:53 PM, Joe Stein  wrote:
>
> > Is there a wiki page for the protocol spec? I googled a little but my
> > google fu is off today :(
> >
> >
> We keep that in-tree:
> https://github.com/apache/cassandra/blob/trunk/doc/native_protocol_v2.spec
>

Re: Proposal: freeze Thrift starting with 2.1.0

[Edward Capriolo]

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

Re: Proposal: freeze Thrift starting with 2.1.0

[Jonathan Ellis]

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

Re: Proposal: freeze Thrift starting with 2.1.0

[Russ Bradberry]

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