cassandra-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Edward Capriolo <edlinuxg...@gmail.com>
Subject Re: Proposal: freeze Thrift starting with 2.1.0
Date Tue, 11 Mar 2014 19:24:48 GMT
"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 <tyler@datastax.com> wrote:

> On Tue, Mar 11, 2014 at 1:37 PM, Edward Capriolo <edlinuxguru@gmail.com
> >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 <http://datastax.com/>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message