Respectfully, there’s pretty much already apparent consensus among those with a vote (unless I missed some dissenting opinion while I was on vacation).
Its been expressed multiple times by committers and members of the PMC that it’s Cassandra native protocol, it belongs in the protocol when it’s implemented. I haven’t seen ANY committers or members of the PMC make an argument that we should alter the spec without a matching implementation. Unless a committer wants to make an argument that we should change the spec without changing the implementation, this conversation can end. The spec is what the server implements. Anything we don’t implement can use the arbitrary payload from the zipkin tracing ticket or fork. -- Jeff Jirsa > On Apr 23, 2018, at 6:18 PM, Nate McCall <zznat...@gmail.com> wrote: > > Folks, > Before this goes much further, let's take a step back for a second. > > I am hearing the following: Folks are fine with CASSANDRA-14311 and > CASSANDRA-2848 *BUT* they don't make much sense from the project's > perspective without a reference implementation. I think the shard > concept is too abstract for the project right now, so we should > probably set that one aside. > > Dor and Avi, I appreciate you both engaging directly on this. Where > can we find common ground on this? > > --------------------------------------------------------------------- > 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
