OSDir


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Evolving the client protocol


> 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 <dor@xxxxxxxxxxxx> wrote:

> On Mon, Apr 23, 2018 at 5:28 PM, Josh McKenzie <jmckenzie@xxxxxxxxxx>
> 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 <dor@xxxxxxxxxxxx> wrote:
> >
> > > On Mon, Apr 23, 2018 at 5:03 PM, Sankalp Kohli <kohlisankalp@xxxxxxxxx
> >
> > > 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 <dor@xxxxxxxxxxxx> wrote:
> > > > >
> > > > >> On Mon, Apr 23, 2018 at 4:13 PM, Jonathan Haddad <
> jon@xxxxxxxxxxxxx
> > >
> > > > 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 <ben@xxxxxxxxxxxxxxx
> >
> > > > 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=qK2RkRAsGtixYf0IgKlRBYLfTrXyOKED9OOTyMVvDf4&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 <avi@xxxxxxxxxxxx>
> > 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 <
> > > ariel@xxxxxxxxxxx
> > > > >>>
> > > > >>>> 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=qK2RkRAsGtixYf0IgKlRBYLfTrXyOKED9OOTyMVvDf4&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=qK2RkRAsGtixYf0IgKlRBYLfTrXyOKED9OOTyMVvDf4&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 <
> > > > >>> ariel@xxxxxxxxxxx>
> > > > >>>>>>>> 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, glommer@xxxxxxxxxxxx
> > > wrote:
> > > > >>>>>>>>>>>> On 2018/04/19 07:19:27, kurt greaves <
> > kurt@xxxxxxxxxxxxxxx>
> > > > >>>> 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-unsubscribe@xxxxxxxxxxxxxxxxxxxx
> > > > >>> For
> > > > >>>>>>>>>>>> additional commands, e-mail:
> > dev-help@xxxxxxxxxxxxxxxxxxxx
> > > > >>>>>>>>>>>>
> > > > >>>>>>>>>>>
> > > > >>>>
> > > ---------------------------------------------------------------------
> > > > >>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.
> > apache.org
> > > > >>>>>>>>>>> For additional commands, e-mail:
> > > dev-help@xxxxxxxxxxxxxxxxxxxx
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>>> --
> > > > >>>>>>>>>> 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_-
> IczFSSyqkEQqOAjnyZBgb4iUeug&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-unsubscribe@cassandra.
> apache.org
> > > > >>>>>>>>> For additional commands, e-mail:
> > dev-help@xxxxxxxxxxxxxxxxxxxx
> > > > >>>>>>>>>
> > > > >>>>>>>>
> > > > >>> ------------------------------------------------------------
> > ---------
> > > > >>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.
> apache.org
> > > > >>>>>>>> For additional commands, e-mail:
> > dev-help@xxxxxxxxxxxxxxxxxxxx
> > > > >>>>>>>>
> > > > >>>>>>>> --
> > > > >>>>>>> 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_-
> IczFSSyqkEQqOAjnyZBgb4iUeug&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-unsubscribe@xxxxxxxxxxxxxxxxxxxx
> > > > >>>>>> For additional commands, e-mail:
> dev-help@xxxxxxxxxxxxxxxxxxxx
> > > > >>>>>>
> > > > >>>>>
> > > > >>>>> ------------------------------------------------------------
> > > > >> ---------
> > > > >>>>> To unsubscribe, e-mail: dev-unsubscribe@xxxxxxxxxxxxxxxxxxxx
> > > > >>>>> For additional commands, e-mail: dev-help@xxxxxxxxxxxxxxxxxxxx
> > > > >>>>>
> > > > >>>>
> > > > >>>> --
> > > > >>> 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_-
> IczFSSyqkEQqOAjnyZBgb4iUeug&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-unsubscribe@xxxxxxxxxxxxxxxxxxxx
> > > > For additional commands, e-mail: dev-help@xxxxxxxxxxxxxxxxxxxx
> > > >
> > > >
> > >
> >
>
>