On 2018-04-19 19:10, Ariel Weisberg wrote:
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.
That basically means a fork in the protocol (perhaps a temporary fork if
we go for mode 2 where Cassandra retroactively adopts our protocol
changes, if they fit will).
Implementing a protocol change may be easy for some simple changes, but
in the general case, it is not realistic to expect it.
There are also realities to consider as to what the maintainers of the drivers
are willing to commit.
Can you elaborate? No one is forcing driver maintainers to update their
drivers to support new features, either for Cassandra or Scylla, but
there should be no reason for them to reject a contribution adding that
support.
If you refer to a potential politically-motivated rejection by the
DataStax-maintained drivers, then those drivers should and will be
forked. That's not true open source. However, I'm not assuming that will
happen.
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.
Those were just given as examples. Each would be discussed on its own,
assuming we are able to find a way to cooperate.
These are relatively simple and it wouldn't be hard for use to patch
Cassandra. But I want to find a way to make more complicated protocol
changes where it wouldn't be realistic for us to modify Cassandra.
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?
Such a proposal would include negotiation about the sharding algorithm
used to prevent Cassandra being boxed in. Of course it's impossible to
guarantee that a new idea won't come up that requires more changes.
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org
