On Apr 20, 2018, at 5:03 AM, Sylvain Lebresne <lebre...@gmail.com> wrote:
>>
>>
>> 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?
Agree with everything here
>
> 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,
Also agree here - any changes to protocol on the Apache Cassandra side have to
come with the implementation, otherwise you should consider using the optional
arbitrary k/v map that zipkin tracing leverages for arbitrary payloads.
> 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
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org
