Apologies Nate - didn't realize I'd overlapped with you stepping in and trying to bring us all back to reason.
I'll take my leave of the conversation at this point. :) On Mon, Apr 23, 2018 at 9:30 PM, Josh McKenzie <jmcken...@apache.org> wrote: > > Datastax, Apple, Instaclstr, > > thelastpickle and everyone else > > receive different benefits > You have mentioned a variety of vendors who received benefits while making > major contributions back to the project. Comparing Scylla's relationship to > the Cassandra ecosystem to this list is a false equivalency, and honestly > one of the sillier things I've seen on this mailing list. > > > The C* ecosystem can either shrink or expand. We offer to expand it. > Your company has not established a precedent for this, whatsoever, since > its inception. Forgive those of us that don't take you at face value with > this claim. > > On Mon, Apr 23, 2018, 8:54 PM Dor Laor <d...@scylladb.com> wrote: > >> On Mon, Apr 23, 2018 at 5:28 PM, Josh McKenzie <jmcken...@apache.org> >> wrote: >> >> > > it's not >> > > reasonable to expect Scylla to contribute >> > > such a huge effort to the C* server >> > >> > But it's reasonable that a major portion of Scylla's business model is >> > profiting off those huge efforts other companies have made? >> > >> > Seems a little hypocritical to me. >> > >> >> We're an open source based vendor, it's not a secret. >> Last I checked, all participates on the thread should get business >> benefits >> and we all >> got benefits from following the Dynamo/BigTable path. >> We never zig-zaged and have very consistent open source approach. >> >> We're all here to make some type of profit. >> Datastax, Apple, Instaclstr, thelastpickle and everyone else receive >> different benefits, >> from PR benefits, commercial benefits, service credibility, expertise >> benefits, personal >> carrier benefits and fun too. >> >> The C* ecosystem can either shrink or expand. We offer to expand it. >> >> >> >> >> > >> > On Mon, Apr 23, 2018, 8:18 PM Dor Laor <d...@scylladb.com> wrote: >> > >> > > On Mon, Apr 23, 2018 at 5:03 PM, Sankalp Kohli < >> kohlisank...@gmail.com> >> > > wrote: >> > > >> > > > Is one of the “abuse” of Apache license is ScyllaDB which is using >> > > > Cassandra but not contributing back? >> > > > >> > > >> > > It's not that we have a private version of Cassandra and we don't >> release >> > > all of it or some of it back.. >> > > >> > > We didn't contribute because we have a different server base. We >> always >> > > contribute where it makes sense. >> > > I'll be happy to have several beers or emails about the cons and pros >> of >> > > open source licensing but I don't think >> > > this is the case. The discussion is about whether the community wish >> to >> > > accept our contributions, we initiated it, >> > > didn't we? >> > > >> > > Let's be practical, I think it's not reasonable to commit C* protocol >> > > changes that the community doesn't intend >> > > to implement in C* in the short term (thread-per-core like), it's not >> > > reasonable to expect Scylla to contribute >> > > such a huge effort to the C* server. It is reasonable to collaborate >> > around >> > > protocol enhancements that are acceptable, >> > > even without coding and make sure the protocol is enhanceable in a way >> > that >> > > forward compatible. >> > > >> > > >> > > Happy to be proved wrong as I am not a lawyer and don’t understand >> > various >> > > > licenses .. >> > > > >> > > > > On Apr 23, 2018, at 16:55, Dor Laor <d...@scylladb.com> wrote: >> > > > > >> > > > >> On Mon, Apr 23, 2018 at 4:13 PM, Jonathan Haddad < >> j...@jonhaddad.com >> > > >> > > > wrote: >> > > > >> >> > > > >> From where I stand it looks like you've got only two options for >> any >> > > > >> feature that involves updating the protocol: >> > > > >> >> > > > >> 1. Don't built the feature >> > > > >> 2. Built it in Cassanda & scylladb, update the drivers >> accordingly >> > > > >> >> > > > >> I don't think you have a third option, which is built it only in >> > > > ScyllaDB, >> > > > >> because that means you have to fork *all* the drivers and make it >> > > work, >> > > > >> then maintain them. Your business model appears to be built on >> not >> > > > doing >> > > > >> any of the driver work yourself, and you certainly aren't giving >> > back >> > > to >> > > > >> the open source community via a permissive license on ScyllaDB >> > itself, >> > > > so >> > > > >> I'm a bit lost here. >> > > > >> >> > > > > >> > > > > It's totally not about business model. >> > > > > Scylla itself is 99% open source with AGPL license that prevents >> > abuse >> > > > and >> > > > > forces to be committed back to the project. We also have our core >> > > engine >> > > > > (seastar) licensed >> > > > > as Apache since it needs to be integrated with the core >> application. >> > > > > Recently one of our community members even created a new Seastar >> > based, >> > > > C++ >> > > > > driver. >> > > > > >> > > > > Scylla chose to be compatible with the drivers in order to >> leverage >> > the >> > > > > existing infrastructure >> > > > > and (let's be frank) in order to allow smooth migration. >> > > > > We would have loved to contribute more to the drivers but up to >> > > recently >> > > > we: >> > > > > 1. Were busy on top of our heads with the server >> > > > > 2. Happy w/ the existing drivers >> > > > > 3. Developed extensions - GoCQLX - our own contribution >> > > > > >> > > > > Finally we can contribute back to the same driver project, we >> want to >> > > do >> > > > it >> > > > > the right way, >> > > > > without forking and without duplicated efforts. >> > > > > >> > > > > Many times, having a private fork is way easier than proper open >> > source >> > > > > work so from >> > > > > a pure business perspective, we don't select the shortest path. >> > > > > >> > > > > >> > > > >> >> > > > >> To me it looks like you're asking a bunch of volunteers that >> work on >> > > > >> Cassandra to accommodate you. What exactly do we get out of this >> > > > >> relationship? What incentive do I or anyone else have to spend >> time >> > > > >> helping you instead of working on something that interests me? >> > > > >> >> > > > > >> > > > > Jon, this is certainty not the case. >> > > > > We genuinely wish to make true *open source* work on: >> > > > > a. Cassandra drivers >> > > > > b. Client protocol >> > > > > c. Scylla server side. >> > > > > d. Cassandra community related work: mailing list, Jira, design >> > > > > >> > > > > But not >> > > > > e. Cassandra server side >> > > > > >> > > > > While I wouldn't mind doing the Cassandra server work, we don't >> have >> > > the >> > > > > resources or >> > > > > the expertise. The Cassandra _developer_ community is welcome to >> > decide >> > > > > whether >> > > > > we get to contribute a/b/c/d. Avi has enumerated the options of >> > > > > cooperation, passive cooperation >> > > > > and zero cooperation (below). >> > > > > >> > > > > 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. >> > > > > 2. The protocol change is developed outside the Cassandra process. >> > > > > 3. No cooperation. >> > > > > >> > > > > Look, I can understand the hostility and suspicious, however, from >> > the >> > > C* >> > > > > project POV, it makes no >> > > > > sense to ignore, otherwise we'll fork the drivers and you won't >> get >> > > > > anything back. There is another >> > > > > at least one vendor today with their server fork and driver fork >> and >> > it >> > > > > makes sense to keep the protocol >> > > > > unified in an extensible way and to discuss new features >> _together_. >> > > > > >> > > > > >> > > > > >> > > > >> >> > > > >> Jon >> > > > >> >> > > > >> >> > > > >> On Mon, Apr 23, 2018 at 7:59 AM Ben Bromhead < >> b...@instaclustr.com> >> > > > wrote: >> > > > >> >> > > > >>>>>> This doesn't work without additional changes, for RF>1. The >> > token >> > > > >> ring >> > > > >>>> could place two replicas of the same token range on the same >> > > physical >> > > > >>>> server, even though those are two separate cores of the same >> > server. >> > > > >> You >> > > > >>>> could add another element to the hierarchy (cluster -> >> datacenter >> > -> >> > > > >> rack >> > > > >>>> -> node -> core/shard), but that generates unneeded range >> > movements >> > > > >> when >> > > > >>> a >> > > > >>>> node is added. >> > > > >>>>> I have seen rack awareness used/abused to solve this. >> > > > >>>>> >> > > > >>>> >> > > > >>>> But then you lose real rack awareness. It's fine for a quick >> hack, >> > > but >> > > > >>>> not a long-term solution. >> > > > >>>> >> > > > >>>> (it also creates a lot more tokens, something nobody needs) >> > > > >>>> >> > > > >>> >> > > > >>> I'm having trouble understanding how you loose "real" rack >> > awareness, >> > > > as >> > > > >>> these shards are in the same rack anyway, because the address >> and >> > > port >> > > > >> are >> > > > >>> on the same server in the same rack. So it behaves as expected. >> > Could >> > > > you >> > > > >>> explain a situation where the shards on a single server would >> be in >> > > > >>> different racks (or fault domains)? >> > > > >>> >> > > > >>> If you wanted to support a situation where you have a single >> rack >> > per >> > > > DC >> > > > >>> for simple deployments, extending NetworkTopologyStrategy to >> behave >> > > the >> > > > >> way >> > > > >>> it did before >> > > https://urldefense.proofpoint.com/v2/url?u=https-3A__issues. >> > apache.org_jira_browse_CASSANDRA-2D7544&d=DwIFaQ&c= >> > adz96Xi0w1RHqtPMowiL2g&r=qK2RkRAsGtixYf0IgKlRBYLfTrXyOKED9OO >> TyMVvDf4&m=- >> > KTfwBfQviFYMIYG-0-uLvTOWvudhHfm3Nlwkd1iLck&s=01FsBvCihZndkHTmett65RHyy- >> > gs8IQENF-wXOTdbD0&e= >> > > > with >> > > > >>> respect to treating InetAddresses as servers rather than the >> > address >> > > > and >> > > > >>> port would be simple. Both this implementation in Apache >> Cassandra >> > > and >> > > > >> the >> > > > >>> respective load balancing classes in the drivers are explicitly >> > > > designed >> > > > >> to >> > > > >>> be pluggable so that would be an easier integration point for >> you. >> > > > >>> >> > > > >>> I'm not sure how it creates more tokens? If a server normally >> owns >> > > 256 >> > > > >>> tokens, each shard on a different port would just advertise >> > ownership >> > > > of >> > > > >>> 256/# of cores (e.g. 4 tokens if you had 64 cores). >> > > > >>> >> > > > >>> >> > > > >>>> >> > > > >>>>> Regards, >> > > > >>>>> Ariel >> > > > >>>>> >> > > > >>>>>> On Apr 22, 2018, at 8:26 AM, Avi Kivity <a...@scylladb.com> >> > wrote: >> > > > >>>>>> >> > > > >>>>>> >> > > > >>>>>> >> > > > >>>>>>> On 2018-04-19 21:15, Ben Bromhead wrote: >> > > > >>>>>>> Re #3: >> > > > >>>>>>> >> > > > >>>>>>> Yup I was thinking each shard/port would appear as a >> discrete >> > > > >> server >> > > > >>>> to the >> > > > >>>>>>> client. >> > > > >>>>>> This doesn't work without additional changes, for RF>1. The >> > token >> > > > >> ring >> > > > >>>> could place two replicas of the same token range on the same >> > > physical >> > > > >>>> server, even though those are two separate cores of the same >> > server. >> > > > >> You >> > > > >>>> could add another element to the hierarchy (cluster -> >> datacenter >> > -> >> > > > >> rack >> > > > >>>> -> node -> core/shard), but that generates unneeded range >> > movements >> > > > >> when >> > > > >>> a >> > > > >>>> node is added. >> > > > >>>>>> >> > > > >>>>>>> If the per port suggestion is unacceptable due to hardware >> > > > >>>> requirements, >> > > > >>>>>>> remembering that Cassandra is built with the concept scaling >> > > > >>>> *commodity* >> > > > >>>>>>> hardware horizontally, you'll have to spend your time and >> > energy >> > > > >>>> convincing >> > > > >>>>>>> the community to support a protocol feature it has no >> (current) >> > > use >> > > > >>>> for or >> > > > >>>>>>> find another interim solution. >> > > > >>>>>> Those servers are commodity servers (not x86, but still >> > > commodity). >> > > > >> In >> > > > >>>> any case 60+ logical cores are common now (hello AWS >> i3.16xlarge >> > or >> > > > >> even >> > > > >>>> i3.metal), and we can only expect logical core count to >> continue >> > to >> > > > >>>> increase (there are 48-core ARM processors now). >> > > > >>>>>> >> > > > >>>>>>> Another way, would be to build support and consensus around >> a >> > > clear >> > > > >>>>>>> technical need in the Apache Cassandra project as it stands >> > > today. >> > > > >>>>>>> >> > > > >>>>>>> One way to build community support might be to contribute an >> > > Apache >> > > > >>>>>>> licensed thread per core implementation in Java that matches >> > the >> > > > >>>> protocol >> > > > >>>>>>> change and shard concept you are looking for ;P >> > > > >>>>>> I doubt I'll survive the egregious top-posting that is going >> on >> > in >> > > > >>> this >> > > > >>>> list. >> > > > >>>>>> >> > > > >>>>>>> >> > > > >>>>>>>> On Thu, Apr 19, 2018 at 1:43 PM Ariel Weisberg < >> > > ar...@weisberg.ws >> > > > >>> >> > > > >>>> wrote: >> > > > >>>>>>>> >> > > > >>>>>>>> Hi, >> > > > >>>>>>>> >> > > > >>>>>>>> So at technical level I don't understand this yet. >> > > > >>>>>>>> >> > > > >>>>>>>> So you have a database consisting of single threaded shards >> > and >> > > a >> > > > >>>> socket >> > > > >>>>>>>> for accept that is generating TCP connections and in >> advance >> > you >> > > > >>>> don't know >> > > > >>>>>>>> which connection is going to send messages to which shard. >> > > > >>>>>>>> >> > > > >>>>>>>> What is the mechanism by which you get the packets for a >> given >> > > TCP >> > > > >>>>>>>> connection delivered to a specific core? I know that a >> given >> > TCP >> > > > >>>> connection >> > > > >>>>>>>> will normally have all of its packets delivered to the same >> > > queue >> > > > >>>> from the >> > > > >>>>>>>> NIC because the tuple of source address + port and >> destination >> > > > >>>> address + >> > > > >>>>>>>> port is typically hashed to pick one of the queues the NIC >> > > > >>> presents. I >> > > > >>>>>>>> might have the contents of the tuple slightly wrong, but it >> > > always >> > > > >>>> includes >> > > > >>>>>>>> a component you don't get to control. >> > > > >>>>>>>> >> > > > >>>>>>>> Since it's hashing how do you manipulate which queue >> packets >> > > for a >> > > > >>> TCP >> > > > >>>>>>>> connection go to and how is it made worse by having an >> accept >> > > > >> socket >> > > > >>>> per >> > > > >>>>>>>> shard? >> > > > >>>>>>>> >> > > > >>>>>>>> You also mention 160 ports as bad, but it doesn't sound >> like a >> > > big >> > > > >>>> number >> > > > >>>>>>>> resource wise. Is it an operational headache? >> > > > >>>>>>>> >> > > > >>>>>>>> RE tokens distributed amongst shards. The way that would >> work >> > > > >> right >> > > > >>>> now is >> > > > >>>>>>>> that each port number appears to be a discrete instance of >> the >> > > > >>>> server. So >> > > > >>>>>>>> you could have shards be actual shards that are simply >> > colocated >> > > > >> on >> > > > >>>> the >> > > > >>>>>>>> same box, run in the same process, and share resources. I >> know >> > > > >> this >> > > > >>>> pushes >> > > > >>>>>>>> more of the complexity into the server vs the driver as the >> > > server >> > > > >>>> expects >> > > > >>>>>>>> all shards to share some client visible like system tables >> and >> > > > >>> certain >> > > > >>>>>>>> identifiers. >> > > > >>>>>>>> >> > > > >>>>>>>> Ariel >> > > > >>>>>>>>> On Thu, Apr 19, 2018, at 12:59 PM, Avi Kivity wrote: >> > > > >>>>>>>>> Port-per-shard is likely the easiest option but it's too >> ugly >> > > to >> > > > >>>>>>>>> contemplate. We run on machines with 160 shards (IBM POWER >> > > > >>> 2s20c160t >> > > > >>>>>>>>> IIRC), it will be just horrible to have 160 open ports. >> > > > >>>>>>>>> >> > > > >>>>>>>>> >> > > > >>>>>>>>> It also doesn't fit will with the NICs ability to >> > automatically >> > > > >>>>>>>>> distribute packets among cores using multiple queues, so >> the >> > > > >> kernel >> > > > >>>>>>>>> would have to shuffle those packets around. Much better to >> > have >> > > > >>> those >> > > > >>>>>>>>> packets delivered directly to the core that will service >> > them. >> > > > >>>>>>>>> >> > > > >>>>>>>>> >> > > > >>>>>>>>> (also, some protocol changes are needed so the driver >> knows >> > how >> > > > >>>> tokens >> > > > >>>>>>>>> are distributed among shards) >> > > > >>>>>>>>> >> > > > >>>>>>>>>> On 2018-04-19 19:46, Ben Bromhead wrote: >> > > > >>>>>>>>>> WRT to #3 >> > > > >>>>>>>>>> To fit in the existing protocol, could you have each >> shard >> > > > >> listen >> > > > >>>> on a >> > > > >>>>>>>>>> different port? Drivers are likely going to support this >> due >> > > to >> > > > >>>>>>>>>> >> > > https://urldefense.proofpoint.com/v2/url?u=https-3A__issues. >> > apache.org_jira_browse_CASSANDRA-2D7544&d=DwIFaQ&c= >> > adz96Xi0w1RHqtPMowiL2g&r=qK2RkRAsGtixYf0IgKlRBYLfTrXyOKED9OO >> TyMVvDf4&m=- >> > KTfwBfQviFYMIYG-0-uLvTOWvudhHfm3Nlwkd1iLck&s=01FsBvCihZndkHTmett65RHyy- >> > gs8IQENF-wXOTdbD0&e= >> > > ( >> > > > >>>>>>>>>> >> > > https://urldefense.proofpoint.com/v2/url?u=https-3A__issues. >> > apache.org_jira_browse_CASSANDRA-2D11596&d=DwIFaQ&c= >> > adz96Xi0w1RHqtPMowiL2g&r=qK2RkRAsGtixYf0IgKlRBYLfTrXyOKED9OO >> TyMVvDf4&m=- >> > KTfwBfQviFYMIYG-0-uLvTOWvudhHfm3Nlwkd1iLck&s=RggcL9lWBe5uDAPbMWW4S_7- >> > ZzYVctqUA5W6GYSwBm4&e=). >> > > I'm >> > > > >> not >> > > > >>>> super >> > > > >>>>>>>>>> familiar with the ticket so their might be something I'm >> > > missing >> > > > >>>> but it >> > > > >>>>>>>>>> sounds like a potential approach. >> > > > >>>>>>>>>> >> > > > >>>>>>>>>> This would give you a path forward at least for the short >> > > term. >> > > > >>>>>>>>>> >> > > > >>>>>>>>>> >> > > > >>>>>>>>>> On Thu, Apr 19, 2018 at 12:10 PM Ariel Weisberg < >> > > > >>> ar...@weisberg.ws> >> > > > >>>>>>>> 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. >> > > > >>>>>>>>>>> >> > > > >>>>>>>>>>> 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-unsubscribe@cassandra. >> > apache.org >> > > > >>>>>>>>>>> For additional commands, e-mail: >> > > dev-h...@cassandra.apache.org >> > > > >>>>>>>>>>> >> > > > >>>>>>>>>>> -- >> > > > >>>>>>>>>> Ben Bromhead >> > > > >>>>>>>>>> CTO | Instaclustr < >> > > https://urldefense.proofpoint.com/v2/url?u=https-3A__www. >> > instaclustr.com_&d=DwIFaQ&c=adz96Xi0w1RHqtPMowiL2g&r= >> > qK2RkRAsGtixYf0IgKlRBYLfTrXyOKED9OOTyMVvDf4&m=-KTfwBfQviFYMIYG-0- >> > uLvTOWvudhHfm3Nlwkd1iLck&s=fmbcKjLNXdZWdw_-IczFSSyqkEQqOAjny >> ZBgb4iUeug&e= >> > > > >> > > > >>>>>>>>>> +1 650 284 9692 <(650)%20284-9692> <(650)%20284-9692> >> > > > >>> <(650)%20284-9692> >> > > > >>>>>>>>>> Reliability at Scale >> > > > >>>>>>>>>> Cassandra, Spark, Elasticsearch on AWS, Azure, GCP and >> > > Softlayer >> > > > >>>>>>>>>> >> > > > >>>>>>>>> >> > > > >>> ------------------------------------------------------------ >> > --------- >> > > > >>>>>>>>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apac >> he.org >> > > > >>>>>>>>> For additional commands, e-mail: >> > dev-h...@cassandra.apache.org >> > > > >>>>>>>>> >> > > > >>>>>>>> >> > > > >>> ------------------------------------------------------------ >> > --------- >> > > > >>>>>>>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apac >> he.org >> > > > >>>>>>>> For additional commands, e-mail: >> > dev-h...@cassandra.apache.org >> > > > >>>>>>>> >> > > > >>>>>>>> -- >> > > > >>>>>>> Ben Bromhead >> > > > >>>>>>> CTO | Instaclustr < >> > > https://urldefense.proofpoint.com/v2/url?u=https-3A__www. >> > instaclustr.com_&d=DwIFaQ&c=adz96Xi0w1RHqtPMowiL2g&r= >> > qK2RkRAsGtixYf0IgKlRBYLfTrXyOKED9OOTyMVvDf4&m=-KTfwBfQviFYMIYG-0- >> > uLvTOWvudhHfm3Nlwkd1iLck&s=fmbcKjLNXdZWdw_-IczFSSyqkEQqOAjny >> ZBgb4iUeug&e= >> > > > >> > > > >>>>>>> +1 650 284 9692 <(650)%20284-9692> <(650)%20284-9692> >> > > > >>>>>>> Reliability at Scale >> > > > >>>>>>> Cassandra, Spark, Elasticsearch on AWS, Azure, GCP and >> > Softlayer >> > > > >>>>>>> >> > > > >>>>>> >> > > > >>>>>> ------------------------------------------------------------ >> > > > >> --------- >> > > > >>>>>> 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 >> > > > >>>>> >> > > > >>>> >> > > > >>>> -- >> > > > >>> Ben Bromhead >> > > > >>> CTO | Instaclustr < >> > > https://urldefense.proofpoint.com/v2/url?u=https-3A__www. >> > instaclustr.com_&d=DwIFaQ&c=adz96Xi0w1RHqtPMowiL2g&r= >> > qK2RkRAsGtixYf0IgKlRBYLfTrXyOKED9OOTyMVvDf4&m=-KTfwBfQviFYMIYG-0- >> > uLvTOWvudhHfm3Nlwkd1iLck&s=fmbcKjLNXdZWdw_-IczFSSyqkEQqOAjny >> ZBgb4iUeug&e= >> > > > >> > > > >>> +1 650 284 9692 <(650)%20284-9692> >> > > > >>> Reliability at Scale >> > > > >>> Cassandra, Spark, Elasticsearch on AWS, Azure, GCP and Softlayer >> > > > >>> >> > > > >> >> > > > >> > > > ------------------------------------------------------------ >> --------- >> > > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org >> > > > For additional commands, e-mail: dev-h...@cassandra.apache.org >> > > > >> > > > >> > > >> > >> >>
