Hi, I think that updating the protocol spec to Cassandra puts the onus on the party changing the protocol specification to have an implementation of the spec in Cassandra as well as the Java and Python driver (those are both used in the Cassandra repo). Until it's implemented in Cassandra we haven't fully evaluated the specification change. There is no substitute for trying to make it work.
There are also realities to consider as to what the maintainers of the drivers are willing to commit. RE #1, I am +1 on the fact that we shouldn't require an extra hop for range scans. In JIRA Jeremiah made the point that you can still do this from the client by breaking up the token ranges, but it's a leaky abstraction to have a paging interface that isn't a vanilla ResultSet interface. Serial vs. parallel is kind of orthogonal as the driver can do either. I agree it looks like the current specification doesn't make what should be simple as simple as it could be for driver implementers. RE #2, +1 on this change assuming an implementation in Cassandra and the Java and Python drivers. RE #3, It's hard to be +1 on this because we don't benefit by boxing ourselves in by defining a spec we haven't implemented, tested, and decided we are satisfied with. Having it in ScyllaDB de-risks it to a certain extent, but what if Cassandra decides to go a different direction in some way? I don't think there is much discussion to be had without an example of the the changes to the CQL specification to look at, but even then if it looks risky I am not likely to be in favor of it. Regards, Ariel On Thu, Apr 19, 2018, at 9:33 AM, glom...@scylladb.com wrote: > > > On 2018/04/19 07:19:27, kurt greaves <k...@instaclustr.com> wrote: > > > > > > 1. The protocol change is developed using the Cassandra process in > > > a JIRA ticket, culminating in a patch to > > > doc/native_protocol*.spec when consensus is achieved. > > > > I don't think forking would be desirable (for anyone) so this seems > > the most reasonable to me. For 1 and 2 it certainly makes sense but > > can't say I know enough about sharding to comment on 3 - seems to me > > like it could be locking in a design before anyone truly knows what > > sharding in C* looks like. But hopefully I'm wrong and there are > > devs out there that have already thought that through. > > Thanks. That is our view and is great to hear. > > About our proposal number 3: In my view, good protocol designs are > future proof and flexible. We certainly don't want to propose a design > that works just for Scylla, but would support reasonable > implementations regardless of how they may look like. > > > > > Do we have driver authors who wish to support both projects? > > > > Surely, but I imagine it would be a minority. > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For > additional commands, e-mail: dev-h...@cassandra.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
