> > > 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. >
That's where I'm confused with what you are truly asking. The native protocol is the protocol of the Apache Cassandra project and was never meant to be a standard protocol. If the ask is to move towards more of handling the protocol as a standard that would evolve independently of whether Cassandra implements it (would the project commit to implement it eventually?), then let's be clear on what the concrete suggestion is and have this discussion (but to be upfront, the short version of my personal opinion is that this would likely be a big distraction with relatively low merits for the project, so I'm very unconvinced). But if that's not the ask, what is it exactly? That we agree to commit changes to the protocol spec before we have actually implemented them? If so, I just don't get it. The downsides are clear (we risk the feature is either never implemeted due to lack of contributions/loss of interest, or that the protocol changes committed are not fully suitable to the final implementation) but what benefit to the project can that ever have? Don't get me wrong, protocol-impacting changes/additions are very much welcome if reasonable for Cassandra, and both CASSANDRA-14311 and CASSANDRA-2848 are certainly worthy. Both the definition of done of those ticket certainly include the server implementation imo, not just changing the protocol spec file. As for the shard notion, it makes no sense for Cassandra at this point in time, so unless an additional contribution makes it so that it start to make sense, I'm not sure why we'd add anything related to it to the protocol. -- Sylvain > > > 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 > >
