Re: Cassandra Java Driver and DataStax

[Edward Capriolo]

What a fun topic. I re-joined the list just for this.

As I understand, it the nature of the Apache Software Licence any corporate
entity is allows to produce open and closed source software based on Apache
Cassandra, however the Cassandra name is a trademark of the ASF foundation.

As I under it, any corporation or person is free to maintain any
documentation about the software in a public or private form.

IMHO the Apache Cassandra wiki is in a sad state, and Corporate site X has
better material, but that is not an indictment of  Corporation X.

I will leave planetcassandra.org to be its own issue.

If someone were to propose a Java/Python driver to be included in the
source code of Cassandra, and said driver were rejected that would be a
clear red flag.

There are several awkward things about the driver being found at somewhere
else. These are all hypothetical but have practical implications.
Following the 'itch to scratch' philosophy perhaps I want to write the
driver in UDP for max performance. Right now even if it were implemented in
the database you have a situation where the driver living over there
ultimately is a VETO, you really can not accomplish one without there other
and they have to move lock step to do reasonable development.

There is a saying in apache something like "if it did not happen on the
list/in jira it did not happen." We have to ask ourselves honestly:

Q: Is it possible that technical writers "over there" are able to come up
with better documentation than the project itself?

A: Yes I wrote the Apache Hive book, and I believe it was more up to date
and complete than the documentation at the time

Q: Is that happening here? Who is to say?

Q: Is the CQL spec "written" in code or in documentation good enough for
someone to reasonable re-create the protocol?

Paraphrased things said on this thread that make me laugh, cry, nod:

"There are plenty of drivers like Kundera, hector"

These projects have been killed off by people as they are unable to keep up
with ever changing cassandra client specs. Thrift 0.6 -> 07 breaking
changes, CQL and the entire deprecation of thrift and the original data
model the database was built around.

"Web server X does not come with a web browser"
This is an established protocol for 20+ years and reasonable clients
already exist. That is not building a new protocol and implementation that
is conforming to an exist one apply the Apache logic to google Spdy.

"Postres does it like X"
Someone else pointed it out, but this ain't postgres, and this ain't
mongohq. The Apache licence and the Apache way are different things.

"No one at company X commits my patches because I dont work there"
As the minority (non facebook) hive committer for years I can tell you,
"wink wink"

Re: Cassandra Java Driver and DataStax

[Eric Evans]

On Sat, Jun 4, 2016 at 2:38 PM, Jonathan Ellis  wrote:
> FWIW, in very very ancient history we actually had the drivers in tree.  It
> sucked, because the people who wanted to contribute to the drivers were for
> the most part not Committers, and the committers for the most part weren't
> interested in reviewing drivers patches, and you have different,
> non-overlapping sets of contributors for each driver.  (A C++ driver author
> generally isn't very interested in clojure and vice versa.)
>
> Two things really convinced us they didn't belong in tree, even if we
> wanted to live with the above drawbacks:
>
> - If it's in tree, then the Apache committers are viewed as responsible for
> maintaining it.  Never mind if the Perl driver was (hypothetically)
> contributed by some guy who disappeared after a month and none of the
> committers know Perl, we have by committing it implicitly promised to fix
> bugs and keep it up to date with new features.
> - The obvious solution to this problem is to just not commit any driver
> that we don't have enough expertise to maintain ourselves or are not
> sufficiently confident in the author's commitment.  But then you have a
> very clear distinction between "first class," in tree drivers (probably
> just Java, maybe Python too) and everyone else, which didn't sit right with
> us either.

FWIW, at the time, I was probably one of the more vocal proponents of
this model (out-of-tree driver code), but I'm less certain these days.

First off, I think it's probably a false dichotomy to say that if we
were to admit one language that we'd be obligated to admit them all,
or that we'd be compelled to offer some arbitrary level of support for
any or all drivers simply because they are there.  We could, for
example, release a Java driver and only a Java driver because a) there
is room to share some common code with Cassandra, b) because Cassandra
is Java and the expertise is there, and c) because having one driver
is enough to serve as a reference implementation. Or we could have
some subset that met whatever objective criteria we came up with to
address concerns about supportability.  Or we could be liberal about
the drivers we accept, but conservative about the support we provide
(i.e. set realistic expectations).

One thing is as certain now as it was then, to make such a thing work,
we'd need to be far more willing to pull the trigger on new committers
than we are now.  Personally, I think we could benefit from that,
regardless of how you feel about in-tree drivers.

-- 
Eric Evans
john.eric.ev...@gmail.com

Re: Cassandra Java Driver and DataStax

[Pavel Yaskevich]

Hi Chris,

   On a similar note to what Andres mentioned, me and couple of other
people have recently contributed index implementation (SASI), which
significantly extends
   indexing capabilities of Apache Cassandra, and might be one of the
biggest changes to the database in years.
   I'm a member of PMC for the project and I am not affiliated with
DataStax and although SASI introduces conflict of interests with DSE,
   similar (if not greater) to the work Andres is doing at Stratio, I have
only received positive feedback and help from development community -
people helped to review changes, added new features, contributed tests,
   wrote blog posts about it, organized meetups etc.

Best Regards, Pavel.


On Mon, Jun 6, 2016 at 4:43 PM, Chris Mattmann  wrote:

> Thanks Jonathan.
>
> I have seen several people replying back and citing general
> technical benefits again to having different drivers hosted
> elsewhere. I have also seen people say, “well it’s ALv2
> and open source, so people can fork it and blah and blah”.
>
> “Opensource” and “ALv2” don’t necessarily a community make and
> I think that point is a little lost amongst people who are
> part of this Apache PMC.
>
> Thanks for being willing to update the report as I asked and
> I look forward to your thoughts and the community thinking
> on this and reviewing it with my board hat on.
>
> Cheers,
> Chris
>
>
>
>
> On 6/6/16, 3:19 PM, "Jonathan Ellis"  wrote:
>
> >I’m happy to consult with my peers in other projects for the board report
> >and summarize their ideas and Cassandra PMC's to improve contributor
> >diversity.  I’ll plan to attend the meeting in person to discuss this
> >further.
> >
> >On Sun, Jun 5, 2016 at 5:33 PM, Mattmann, Chris A (3980) <
> >chris.a.mattm...@jpl.nasa.gov> wrote:
> >
> >> Thanks for the info Jonathan. I think have assessed based on
> >> the replies thus far, my studying of the archives and
> >> commit and project history the following situation.
> >>
> >> Unfortunately it seems like there is a bit of control going on
> >> I’m going to call a spade a spade here. A key portion of your
> >> software’s stack, a client driver to use it, exists outside of
> >> Apache in separate communities. This is an inherent risk to the
> >> project. Some of you cite flexibility and adaptability as reasons
> >> for this - I’ve seen it in so many communities over the last 12+
> >> years in the foundation - it’s not really due to those issues.
> >> There is definitely some control going on. I would ask you all
> >> this - has there been a PR or patch in the past year or two that
> >> wasn’t singularly reviewed by DataStax committers and PMC? Also,
> >> as to the composition of the PMC when was the last time a non
> >> DataStax person was elected to the PMC and/or as a committer?
> >>
> >> By itself the diversity issues alone are not damning to the
> >> project, but taken together with the citation to other project
> >> communities even those outside of Apache (e.g., the comments
> >> well “Postgres does it this way, so it’s a good example to
> >> compare us to” or “these other 4 projects at the ASF do it
> >> like this, so X”.. [sic]) and with the perception being created
> >> to those that don’t work at DataStax, and there is an issue here.
> >>
> >> I would like to see a discussion in your next board report about
> >> the diversity and health issues of the project, and also some
> >> ideas about potential strategies for mitigation.
> >>
> >> I appreciate the open and honest conversation thus far. Let’s
> >> keep it up.
> >>
> >> Cheers,
> >> Chris
> >>
> >> ++
> >> Chris Mattmann, Ph.D.
> >> Chief Architect
> >> Instrument Software and Science Data Systems Section (398)
> >> NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
> >> Office: 168-519, Mailstop: 168-527
> >> Email: chris.a.mattm...@nasa.gov
> >> WWW:  http://sunset.usc.edu/~mattmann/
> >> ++
> >> Director, Information Retrieval and Data Science Group (IRDS)
> >> Adjunct Associate Professor, Computer Science Department
> >> University of Southern California, Los Angeles, CA 90089 USA
> >> WWW: http://irds.usc.edu/
> >> ++
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> On 6/5/16, 1:51 PM, "Jonathan Ellis"  wrote:
> >>
> >> >On Sun, Jun 5, 2016 at 8:32 AM, Mattmann, Chris A (3980) <
> >> >chris.a.mattm...@jpl.nasa.gov> wrote:
> >> >
> >> >> 1. Is Apache Cassandra useful *without* a driver? That is, can
> >> >> you use the database without a driver to connect to it or in the
> >> >> real world would your users all have to download at least one
> >> >> driver in order to use the DB?
> >> >>
> >> >
> >> >The users do need to download a driver--but this is pretty normal for
> >> >community-driven OSS databases.  Besides the 

Re: Cassandra Java Driver and DataStax

[Jeremy Hanna]

> On Jun 5, 2016, at 4:33 PM, Mattmann, Chris A (3980) 
>  wrote:
> 
> Thanks for the info Jonathan. I think have assessed based on
> the replies thus far, my studying of the archives and
> commit and project history the following situation.
> 
> Unfortunately it seems like there is a bit of control going on
> I’m going to call a spade a spade here. A key portion of your 
> software’s stack, a client driver to use it, exists outside of
> Apache in separate communities. This is an inherent risk to the
> project. Some of you cite flexibility and adaptability as reasons
> for this - I’ve seen it in so many communities over the last 12+
> years in the foundation - it’s not really due to those issues.

Not all open-source projects do well under the apache umbrella in my opinion.  
Additionally not all library dependencies for all apache projects come from 
apache.

> There is definitely some control going on.

One thing I like about the ASF is that it’s about contribution and meritocracy. 
 If you have a company that is devoted to making a project successful, you’ll 
have more contribution from them.  Some people will gravitate to work for that 
company because they are passionate about the project and working there allows 
them to spend more time on it than they would have been able to at other 
companies.  And yet there are several committers and PMC members that don’t 
work for DataStax who have an influence over its development.  I think you may 
mean control in terms of contribution as you talk about in your next questions. 
 If that’s the case, how do you get other people to contribute more?  DataStax 
has already sponsored several contributor bootcamps for instance.  If it’s 
about contribution and meritocracy, is there an instance where a contribution 
was not accepted because of where an individual was employed?  Is there an 
instance where someone wasn’t accepted as a contributor or committer or pmc 
member because of where they worked?  Several of those committers/PMC members 
who are currently at DataStax became committers/PMC members before joining 
DataStax.  I’m just trying to understand the nature of where you see a problem.

> I would ask you all
> this - has there been a PR or patch in the past year or two that
> wasn’t singularly reviewed by DataStax committers and PMC? Also,
> as to the composition of the PMC when was the last time a non 
> DataStax person was elected to the PMC and/or as a committer?
> 
> By itself the diversity issues alone are not damning to the 
> project, but taken together with the citation to other project
> communities even those outside of Apache (e.g., the comments
> well “Postgres does it this way, so it’s a good example to
> compare us to” or “these other 4 projects at the ASF do it 
> like this, so X”.. [sic]) and with the perception being created
> to those that don’t work at DataStax, and there is an issue here.

I don’t quite understand the thinking here - referencing how successful 
open-source projects operate (outside the asf) is damning?  Mentioning that 
Cassandra is not unique within Apache to have client drivers outside of the 
main project is damning?  I don’t understand why that either of those would be 
in any way negative or invalid.

Regarding the thread generally, I still haven’t seen 1) an instance where 
having client drivers developed outside of the core project being a problem or 
2) an example where employees of datastax exerted control over the project to 
the detriment of others or 3) an example of anyone in the community saying 
“yeah, you’re right, they do control stuff and it sucks.”

Personally, I would like to see more specific concrete evidence of a problem.  
I’ve been involved with the project since 0.6 and it’s always had a very open 
and active community complete with ideas, disagreements, and mistakes.  Take 
for example CASSANDRA-9666 where the best time series compaction strategy 
alternatives are discussed.  It was determined that a community contribution 
from a third party company was going to supersede/replace what was in the tree. 
 If there are specific concerns, I think everyone involved in the project would 
like to know.

> 
> I would like to see a discussion in your next board report about
> the diversity and health issues of the project, and also some 
> ideas about potential strategies for mitigation. 
> 
> I appreciate the open and honest conversation thus far. Let’s
> keep it up.
> 
> Cheers,
> Chris
> 
> ++
> Chris Mattmann, Ph.D.
> Chief Architect
> Instrument Software and Science Data Systems Section (398)
> NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
> Office: 168-519, Mailstop: 168-527
> Email: chris.a.mattm...@nasa.gov
> WWW:  http://sunset.usc.edu/~mattmann/
> ++
> Director, Information Retrieval and Data Science Group (IRDS)
> Adjunct 

Re: Cassandra Java Driver and DataStax

[Brandon Williams]

On Sun, Jun 5, 2016 at 3:20 PM, Mattmann, Chris A (3980) <
chris.a.mattm...@jpl.nasa.gov> wrote:

> #1 - a driver is needed to use Apache Cassandra right? As in, you
> wouldn’t expect users of Apache Cassandra to get the database core
> from the ASF, and then use it without a driver (from somewhere else?)
>

I need a browser to use Apache HTTPD, right?

Re: Cassandra Java Driver and DataStax

[Eric Stevens]

> A key portion of your software’s stack, a client driver to use it, exists
outside of Apache in separate communities. This is an inherent risk to the
project.

That's not at all obvious to me.  The driver you're concerned about is not
under ASF, but it is Apache licensed, if DataStax took it in a direction
unfavorable to the community, the community would be able to just fork it.
Your concern here seems mostly to be surrounding one project vs two.  At
worst this is a layout concern.

> I would ask you all this - has there been a PR or patch in the past year
or two that wasn’t singularly reviewed by DataStax committers and PMC?

There are numerous non-PMC non-DataStax committers.  Regardless, this is
the wrong question to ask.  The question is not how well reviewed the code
is and whether there are a tight set of gate keepers, but rather whether
there are contributions being rejected which would advance the product in a
material way, but are being rejected by reviewers due to, for example, a
conflict of interest.

> Does anyone in the community see this “controlling” behavior going on?
... Thanks for any help you can provide in rooting this out.
> ...
> Unfortunately it seems like there is a bit of control going on...There is
definitely some control going on

You asked the community for feedback on this, and it was pretty clear to me
that nobody here felt like that was the case.

If you're aware of *actual* examples of impropriety in this or another
sense, I think the community would like to hear about it.  Something more
substantial than vague assertions and hand waving.  However, claiming
repeatedly that you see control going on, but without something to
substantiate the accusation feels like an expedition fishing for drama.

On Mon, Jun 6, 2016 at 5:36 AM Jeremiah D Jordan 
wrote:

> The Apache Cassandra project has always left development of its drivers up
> to the community.  The DataStax Java Driver is not part of the Apache
> Cassandra project, it is an open source project created by DataStax.  You
> can find a large list of drivers for Cassandra here:
> https://wiki.apache.org/cassandra/ClientOptions some of them developed by
> DataStax, some developed by Netflix, and many others.
>
> -Jeremiah
>
> > On Jun 3, 2016, at 9:29 PM, Chris Mattmann  wrote:
> >
> > Hi All,
> >
> > I’m investigating something a few ASF members contacted
> > me about and pointed out, so I’m hoping you can help
> > guide me here as a community. I have heard that a company,
> > DataStax, whose marketing material mentions it as the only
> > Cassandra vendor, “controls” the Java Driver for Apache
> > Cassandra.
> >
> > Of course, no company “controls” our projects or its code,
> > so I told the folks that mentioned it to me that I’d investigate
> > with my board hat on.
> >
> > I’d like to hear the community’s thoughts here on this. Does
> > anyone in the community see this “controlling” behavior going
> > on? Please speak up, as I’d like to get to the bottom of it,
> > and I’ll be around on the lists, doing some homework and reading
> > up on the archives to see what’s up.
> >
> > Thanks for any help you can provide in rooting this out.
> >
> > Cheers,
> > Chris
> >
> >
> >
> >
>
>

Re: Cassandra Java Driver and DataStax

[Jeremiah D Jordan]

The Apache Cassandra project has always left development of its drivers up to 
the community.  The DataStax Java Driver is not part of the Apache Cassandra 
project, it is an open source project created by DataStax.  You can find a 
large list of drivers for Cassandra here: 
https://wiki.apache.org/cassandra/ClientOptions some of them developed by 
DataStax, some developed by Netflix, and many others.

-Jeremiah

> On Jun 3, 2016, at 9:29 PM, Chris Mattmann  wrote:
> 
> Hi All,
> 
> I’m investigating something a few ASF members contacted
> me about and pointed out, so I’m hoping you can help 
> guide me here as a community. I have heard that a company,
> DataStax, whose marketing material mentions it as the only
> Cassandra vendor, “controls” the Java Driver for Apache 
> Cassandra. 
> 
> Of course, no company “controls” our projects or its code,
> so I told the folks that mentioned it to me that I’d investigate
> with my board hat on.
> 
> I’d like to hear the community’s thoughts here on this. Does
> anyone in the community see this “controlling” behavior going
> on? Please speak up, as I’d like to get to the bottom of it,
> and I’ll be around on the lists, doing some homework and reading
> up on the archives to see what’s up.
> 
> Thanks for any help you can provide in rooting this out.
> 
> Cheers,
> Chris
> 
> 
> 
> 

Re: Cassandra Java Driver and DataStax

[Dave Brosius]

I am a non-datastax-employee committer, and the large percentage of my 
commits are not reviewed by datastax exmployees. I see problems or areas 
of improvement in the code base, and directly commit them. No questions 
asked, no oversight, no direction at all from datastax or their 
employees. I have had a minor number of commits that were reviewed by 
cassandra committers, some of which are datastax employees, but the 
overwhelming number have not been that way.


If you go by pure commit counts, (an admittedly dubious rating, but 
still) i am #4 on number of commits.




On 06/05/2016 06:33 PM, Mattmann, Chris A (3980) wrote:

Thanks for the info Jonathan. I think have assessed based on
the replies thus far, my studying of the archives and
commit and project history the following situation.

Unfortunately it seems like there is a bit of control going on
I’m going to call a spade a spade here. A key portion of your
software’s stack, a client driver to use it, exists outside of
Apache in separate communities. This is an inherent risk to the
project. Some of you cite flexibility and adaptability as reasons
for this - I’ve seen it in so many communities over the last 12+
years in the foundation - it’s not really due to those issues.
There is definitely some control going on. I would ask you all
this - has there been a PR or patch in the past year or two that
wasn’t singularly reviewed by DataStax committers and PMC? Also,
as to the composition of the PMC when was the last time a non
DataStax person was elected to the PMC and/or as a committer?

By itself the diversity issues alone are not damning to the
project, but taken together with the citation to other project
communities even those outside of Apache (e.g., the comments
well “Postgres does it this way, so it’s a good example to
compare us to” or “these other 4 projects at the ASF do it
like this, so X”.. [sic]) and with the perception being created
to those that don’t work at DataStax, and there is an issue here.

I would like to see a discussion in your next board report about
the diversity and health issues of the project, and also some
ideas about potential strategies for mitigation.

I appreciate the open and honest conversation thus far. Let’s
keep it up.

Cheers,
Chris

++
Chris Mattmann, Ph.D.
Chief Architect
Instrument Software and Science Data Systems Section (398)
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 168-519, Mailstop: 168-527
Email: chris.a.mattm...@nasa.gov
WWW:  http://sunset.usc.edu/~mattmann/
++
Director, Information Retrieval and Data Science Group (IRDS)
Adjunct Associate Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
WWW: http://irds.usc.edu/
++









On 6/5/16, 1:51 PM, "Jonathan Ellis"  wrote:


On Sun, Jun 5, 2016 at 8:32 AM, Mattmann, Chris A (3980) <
chris.a.mattm...@jpl.nasa.gov> wrote:


1. Is Apache Cassandra useful *without* a driver? That is, can
you use the database without a driver to connect to it or in the
real world would your users all have to download at least one
driver in order to use the DB?


The users do need to download a driver--but this is pretty normal for
community-driven OSS databases.  Besides the Apache projects I listed,
PostgreSQL also runs on a community-maintained driver model.



2. To confirm again, at one point at least the Java driver code
lived in the code-base, and further, at one point, people did
submit some patches to add drivers, but the PMC didn’t want to
maintain that code (and apparently they didn’t want to create
any new PMC members and/or committers to do so) and so thus
people started their own new projects? That right?


I think that summary over-emphasizes the governance aspect at the expense
of more important considerations:

0. The very first Cassandra driver interface was Thrift.  No Thrift clients
were ever part of the Cassandra tree.

1. When we created the CQL protocol, we initially had a Java driver in tree
as a reference implementation.

2. But due primarily to the project management issues mentioned by Nate,
and secondarily to the governance aspects above, we moved quickly back to
the pure community-driven drivers approach that had worked for us before.

2a. While some Apache databases do ship a Java driver in tree, I think that
this hinders adoption because it signals to users that non-Java drivers are
second-class citizens.  (No doubt this is not the *intent* of that
decision, but it is a likely consequence nevertheless.)

2b. DataStax saw CQL adoption as a key driver for Cassandra adoption and
hence its own success, and hired a team to accelerate the production of
drivers for the new CQL protocol.  These drivers are Apache licensed and
see broad community participation, e.g. with ~70 

Re: Cassandra Java Driver and DataStax

[Mattmann, Chris A (3980)]

Thanks for the info Jonathan. I think have assessed based on
the replies thus far, my studying of the archives and
commit and project history the following situation.

Unfortunately it seems like there is a bit of control going on
I’m going to call a spade a spade here. A key portion of your 
software’s stack, a client driver to use it, exists outside of
Apache in separate communities. This is an inherent risk to the
project. Some of you cite flexibility and adaptability as reasons
for this - I’ve seen it in so many communities over the last 12+
years in the foundation - it’s not really due to those issues.
There is definitely some control going on. I would ask you all
this - has there been a PR or patch in the past year or two that
wasn’t singularly reviewed by DataStax committers and PMC? Also,
as to the composition of the PMC when was the last time a non 
DataStax person was elected to the PMC and/or as a committer?

By itself the diversity issues alone are not damning to the 
project, but taken together with the citation to other project
communities even those outside of Apache (e.g., the comments
well “Postgres does it this way, so it’s a good example to
compare us to” or “these other 4 projects at the ASF do it 
like this, so X”.. [sic]) and with the perception being created
to those that don’t work at DataStax, and there is an issue here.

I would like to see a discussion in your next board report about
the diversity and health issues of the project, and also some 
ideas about potential strategies for mitigation. 

I appreciate the open and honest conversation thus far. Let’s
keep it up.

Cheers,
Chris

++
Chris Mattmann, Ph.D.
Chief Architect
Instrument Software and Science Data Systems Section (398)
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 168-519, Mailstop: 168-527
Email: chris.a.mattm...@nasa.gov
WWW:  http://sunset.usc.edu/~mattmann/
++
Director, Information Retrieval and Data Science Group (IRDS)
Adjunct Associate Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
WWW: http://irds.usc.edu/
++









On 6/5/16, 1:51 PM, "Jonathan Ellis"  wrote:

>On Sun, Jun 5, 2016 at 8:32 AM, Mattmann, Chris A (3980) <
>chris.a.mattm...@jpl.nasa.gov> wrote:
>
>> 1. Is Apache Cassandra useful *without* a driver? That is, can
>> you use the database without a driver to connect to it or in the
>> real world would your users all have to download at least one
>> driver in order to use the DB?
>>
>
>The users do need to download a driver--but this is pretty normal for
>community-driven OSS databases.  Besides the Apache projects I listed,
>PostgreSQL also runs on a community-maintained driver model.
>
>
>> 2. To confirm again, at one point at least the Java driver code
>> lived in the code-base, and further, at one point, people did
>> submit some patches to add drivers, but the PMC didn’t want to
>> maintain that code (and apparently they didn’t want to create
>> any new PMC members and/or committers to do so) and so thus
>> people started their own new projects? That right?
>>
>
>I think that summary over-emphasizes the governance aspect at the expense
>of more important considerations:
>
>0. The very first Cassandra driver interface was Thrift.  No Thrift clients
>were ever part of the Cassandra tree.
>
>1. When we created the CQL protocol, we initially had a Java driver in tree
>as a reference implementation.
>
>2. But due primarily to the project management issues mentioned by Nate,
>and secondarily to the governance aspects above, we moved quickly back to
>the pure community-driven drivers approach that had worked for us before.
>
>2a. While some Apache databases do ship a Java driver in tree, I think that
>this hinders adoption because it signals to users that non-Java drivers are
>second-class citizens.  (No doubt this is not the *intent* of that
>decision, but it is a likely consequence nevertheless.)
>
>2b. DataStax saw CQL adoption as a key driver for Cassandra adoption and
>hence its own success, and hired a team to accelerate the production of
>drivers for the new CQL protocol.  These drivers are Apache licensed and
>see broad community participation, e.g. with ~70 contributors to the Java
>driver.
>
>2c. Neither has DataStax "sucked the oxygen out of the room."  Lots of
>non-DataStax drivers exist as well.
>
>As Aleksey pointed out earlier, I don't see anyone being harmed by this
>state of affairs.  Cassandra PMC doesn't want to run drivers projects,
>driver authors don't want to be run by Cassandra PMC, and meanwhile users
>have Apache licensed drivers that let them be productive with Cassandra.

Re: Cassandra Java Driver and DataStax

[Jonathan Ellis]

On Sun, Jun 5, 2016 at 8:32 AM, Mattmann, Chris A (3980) <
chris.a.mattm...@jpl.nasa.gov> wrote:

> 1. Is Apache Cassandra useful *without* a driver? That is, can
> you use the database without a driver to connect to it or in the
> real world would your users all have to download at least one
> driver in order to use the DB?
>

The users do need to download a driver--but this is pretty normal for
community-driven OSS databases.  Besides the Apache projects I listed,
PostgreSQL also runs on a community-maintained driver model.


> 2. To confirm again, at one point at least the Java driver code
> lived in the code-base, and further, at one point, people did
> submit some patches to add drivers, but the PMC didn’t want to
> maintain that code (and apparently they didn’t want to create
> any new PMC members and/or committers to do so) and so thus
> people started their own new projects? That right?
>

I think that summary over-emphasizes the governance aspect at the expense
of more important considerations:

0. The very first Cassandra driver interface was Thrift.  No Thrift clients
were ever part of the Cassandra tree.

1. When we created the CQL protocol, we initially had a Java driver in tree
as a reference implementation.

2. But due primarily to the project management issues mentioned by Nate,
and secondarily to the governance aspects above, we moved quickly back to
the pure community-driven drivers approach that had worked for us before.

2a. While some Apache databases do ship a Java driver in tree, I think that
this hinders adoption because it signals to users that non-Java drivers are
second-class citizens.  (No doubt this is not the *intent* of that
decision, but it is a likely consequence nevertheless.)

2b. DataStax saw CQL adoption as a key driver for Cassandra adoption and
hence its own success, and hired a team to accelerate the production of
drivers for the new CQL protocol.  These drivers are Apache licensed and
see broad community participation, e.g. with ~70 contributors to the Java
driver.

2c. Neither has DataStax "sucked the oxygen out of the room."  Lots of
non-DataStax drivers exist as well.

As Aleksey pointed out earlier, I don't see anyone being harmed by this
state of affairs.  Cassandra PMC doesn't want to run drivers projects,
driver authors don't want to be run by Cassandra PMC, and meanwhile users
have Apache licensed drivers that let them be productive with Cassandra.

Re: Cassandra Java Driver and DataStax

[Mattmann, Chris A (3980)]

Hi Jake,

Thanks for the email. So back to my 2 questions - and in particular
#1 - a driver is needed to use Apache Cassandra right? As in, you
wouldn’t expect users of Apache Cassandra to get the database core
from the ASF, and then use it without a driver (from somewhere else?)

Cheers,
Chris

++
Chris Mattmann, Ph.D.
Chief Architect
Instrument Software and Science Data Systems Section (398)
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 168-519, Mailstop: 168-527
Email: chris.a.mattm...@nasa.gov
WWW:  http://sunset.usc.edu/~mattmann/
++
Director, Information Retrieval and Data Science Group (IRDS)
Adjunct Associate Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
WWW: http://irds.usc.edu/
++










On 6/5/16, 9:25 AM, "jak...@gmail.com on behalf of Jake Luciani" 
 wrote:

>Chris,
>
>We technically do have barebones java client in tree [1]
>CQL was designed as an open protocol anyone can implement [2]
>
>We really want to see a thriving eco-system for drivers.   By making CQL an
>open protocol vs making it some internally controlled document/code we feel
>it's the best way to achieve this. I'll throw up as a random example [3].
>
>-Jake
>
>
>[1]:
>https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/transport/SimpleClient.java
>[2]:
>https://github.com/apache/cassandra/blob/trunk/doc/native_protocol_v4.spec
>[3]: https://github.com/matehat/cqerl
>
>On Sun, Jun 5, 2016 at 9:32 AM, Mattmann, Chris A (3980) <
>chris.a.mattm...@jpl.nasa.gov> wrote:
>
>> Hi All,
>>
>> Thanks for the replies so far. A few last questions:
>>
>> 1. Is Apache Cassandra useful *without* a driver? That is, can
>> you use the database without a driver to connect to it or in the
>> real world would your users all have to download at least one
>> driver in order to use the DB?
>>
>> 2. To confirm again, at one point at least the Java driver code
>> lived in the code-base, and further, at one point, people did
>> submit some patches to add drivers, but the PMC didn’t want to
>> maintain that code (and apparently they didn’t want to create
>> any new PMC members and/or committers to do so) and so thus
>> people started their own new projects? That right?
>>
>> Thanks,
>> Chris
>>
>> ++
>> Chris Mattmann, Ph.D.
>> Chief Architect
>> Instrument Software and Science Data Systems Section (398)
>> NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
>> Office: 168-519, Mailstop: 168-527
>> Email: chris.a.mattm...@nasa.gov
>> WWW:  http://sunset.usc.edu/~mattmann/
>> ++
>> Director, Information Retrieval and Data Science Group (IRDS)
>> Adjunct Associate Professor, Computer Science Department
>> University of Southern California, Los Angeles, CA 90089 USA
>> WWW: http://irds.usc.edu/
>> ++
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On 6/4/16, 11:59 AM, "Brandon Williams"  wrote:
>>
>> >First off, full disclosure: contributor, committer, PMC member, and
>> >finally, Datastax employee, in about that order chronologically.
>> >
>> >All of the drivers, as far as I know, are Apache licensed, just as is
>> >Cassandra itself.  There is no 'control', there is only momentum, since
>> >anyone can fork the code if needed and then perhaps gain the momentum if
>> >Datastax loses it.  Nobody is locked in to anything, and no sufficient
>> >traction has been found to take the momentum away from Datastax yet,
>> >because at least in my own admittedly biased opinion, our drivers team has
>> >done an excellent job of accepting community feedback and requests.
>> >
>> >tl;dr don't fix what is not broken
>> >
>> >On Fri, Jun 3, 2016 at 11:11 PM, Mattmann, Chris A (3980) <
>> >chris.a.mattm...@jpl.nasa.gov> wrote:
>> >
>> >> Thanks Jason for the information - I’m going to continue
>> >> researching and hope more people will chime in that are on
>> >> the PMC.
>> >>
>> >> Thank you.
>> >>
>> >> Cheers,
>> >> Chris
>> >>
>> >> ++
>> >> Chris Mattmann, Ph.D.
>> >> Chief Architect
>> >> Instrument Software and Science Data Systems Section (398)
>> >> NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
>> >> Office: 168-519, Mailstop: 168-527
>> >> Email: chris.a.mattm...@nasa.gov
>> >> WWW:  http://sunset.usc.edu/~mattmann/
>> >> ++
>> >> Director, Information Retrieval and Data Science Group (IRDS)
>> >> Adjunct Associate Professor, Computer Science Department
>> >> University of Southern California, Los Angeles, CA 

Re: Cassandra Java Driver and DataStax

[Mattmann, Chris A (3980)]

Hi All,

Thanks for the replies so far. A few last questions:

1. Is Apache Cassandra useful *without* a driver? That is, can
you use the database without a driver to connect to it or in the
real world would your users all have to download at least one
driver in order to use the DB?

2. To confirm again, at one point at least the Java driver code
lived in the code-base, and further, at one point, people did 
submit some patches to add drivers, but the PMC didn’t want to
maintain that code (and apparently they didn’t want to create 
any new PMC members and/or committers to do so) and so thus 
people started their own new projects? That right?

Thanks,
Chris

++
Chris Mattmann, Ph.D.
Chief Architect
Instrument Software and Science Data Systems Section (398)
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 168-519, Mailstop: 168-527
Email: chris.a.mattm...@nasa.gov
WWW:  http://sunset.usc.edu/~mattmann/
++
Director, Information Retrieval and Data Science Group (IRDS)
Adjunct Associate Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
WWW: http://irds.usc.edu/
++









On 6/4/16, 11:59 AM, "Brandon Williams"  wrote:

>First off, full disclosure: contributor, committer, PMC member, and
>finally, Datastax employee, in about that order chronologically.
>
>All of the drivers, as far as I know, are Apache licensed, just as is
>Cassandra itself.  There is no 'control', there is only momentum, since
>anyone can fork the code if needed and then perhaps gain the momentum if
>Datastax loses it.  Nobody is locked in to anything, and no sufficient
>traction has been found to take the momentum away from Datastax yet,
>because at least in my own admittedly biased opinion, our drivers team has
>done an excellent job of accepting community feedback and requests.
>
>tl;dr don't fix what is not broken
>
>On Fri, Jun 3, 2016 at 11:11 PM, Mattmann, Chris A (3980) <
>chris.a.mattm...@jpl.nasa.gov> wrote:
>
>> Thanks Jason for the information - I’m going to continue
>> researching and hope more people will chime in that are on
>> the PMC.
>>
>> Thank you.
>>
>> Cheers,
>> Chris
>>
>> ++
>> Chris Mattmann, Ph.D.
>> Chief Architect
>> Instrument Software and Science Data Systems Section (398)
>> NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
>> Office: 168-519, Mailstop: 168-527
>> Email: chris.a.mattm...@nasa.gov
>> WWW:  http://sunset.usc.edu/~mattmann/
>> ++
>> Director, Information Retrieval and Data Science Group (IRDS)
>> Adjunct Associate Professor, Computer Science Department
>> University of Southern California, Los Angeles, CA 90089 USA
>> WWW: http://irds.usc.edu/
>> ++
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On 6/3/16, 8:33 PM, "Jason Brown"  wrote:
>>
>> >
>> >
>> >
>> >The client-server protocol is well defined in the Cassandra repo, so any
>> one may implement a client library for any language. However, it is a far
>> from trivial task, so not many folks build their own. Thus, already-built
>> drivers tend to become the de facto
>> > standard, but we (the Apache Cassandra committers/PMC) do not/have not
>> blessed any vendor's driver(s) as official.
>> >
>> >
>> >As to why there is not a canonical set of drivers in the Cassandra repo,
>> well, we've just never gotten into that game as an OSS community.
>> >
>> >
>> >-Jason (not affiliated with DataStax)
>> >
>> >On Friday, June 3, 2016, Johan Edstrom  wrote:
>> >
>> >
>> >
>> >On Jun 3, 2016, at 9:14 PM, Jeff Jirsa > > wrote:
>> >
>> >
>> >https://github.com/hector-client/hector
>> >
>> >
>> >
>> >
>> >
>> >
>> >So - that isn’t doing CQL, Right?
>> >
>> >
>> >https://github.com/Netflix/astyanax
>> >
>> >
>> >
>> >
>> >
>> >
>> >Upgrading to CQL?
>> >
>> >
>> >
>> >http://doanduyhai.github.io/Achilles/
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >Which driver do you use?
>> >
>> >
>> >https://github.com/noorq/casser
>> >
>> >
>> >
>> >
>> >
>> >
>> >2.1.5
>> >
>> >
>> >
>> >
>> >
>> >https://github.com/impetus-opensource/Kundera
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >ds-driver
>> >
>> >false
>> >
>> >
>> >cassandra-core
>> >cassandra-ds-driver
>> >
>> >
>> >
>> >thrift
>> >
>> >false
>> >
>> >
>> >cassandra-core
>> >cassandra-thrift
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >https://github.com/deanhiller/playorm
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >- Jeff ( Not affiliated with datastax )
>> >
>> >
>> >
>> >
>> >
>> >On 6/3/16, 7:58 PM, "Johan 

Re: Cassandra Java Driver and DataStax

[Jonathan Ellis]

He already showed himself a good man by apologizing. Please, no more
mudslinging. We're on the same team here.
On Jun 4, 2016 2:22 PM, "Michael Kjellman" 
wrote:

> No need to argue your point to me anymore. I've already tuned you out.
>
> These are good people who I consider my friends and insulting people just
> shows your arguments really have no merit.
>
> Good luck with your new driver contribution! I look forward to reviewing
> the code.
>
> Sent from my iPhone
>
> > On Jun 4, 2016, at 10:10 AM, James Carman 
> wrote:
> >
> > I apologized else-thread about that one.  It was a low blow.  Anyway, to
> > answer your question. The Cassandra community wins!  How do we know if
> they
> > won't make you pay for the driver in the future (after all your code is
> > written against it)?  It has happened before.  Also, the rest of the
> > community can have a say in the direction (because that's the Apache
> Way).
> > The driver can be more intimate with the database, because it's the same
> > people developing it.
> >
> >> On Sat, Jun 4, 2016 at 1:06 PM Aleksey Yeschenko 
> wrote:
> >>
> >> An eloquent and powerful response, but please, reply to my points
> instead
> >> of resorting to ad hominem arguments.
> >>
> >> In practical terms, who would benefit from such a merge, and who is
> >> suffering from the current state of affairs?
> >>
> >> --
> >> AY
> >>
> >> On 4 June 2016 at 18:03:05, James Carman (ja...@carmanconsulting.com)
> >> wrote:
> >>
> >> "Sr. Software Engineer at DataStax", imagine that.
> >>
> >> On Sat, Jun 4, 2016 at 1:01 PM Aleksey Yeschenko 
> >> wrote:
> >>
> >>> As a member of that governing body (Cassandra PMC), I would much prefer
> >>> not to deal with the drivers as well.
> >>>
> >>> And I’m just as certain that java-driver - and other driver
> communities -
> >>> would much rather prefer to keep their process and organisation instead
> >> of
> >>> being forced to conform to ours.
> >>>
> >>> I’m finding it hard to see a single party that would benefit from such
> a
> >>> merge, and who suffers from the current state of things.
> >>>
> >>> --
> >>> AY
> >>>
> >>> On 4 June 2016 at 17:46:48, James Carman (ja...@carmanconsulting.com)
> >>> wrote:
> >>>
> >>> How does it add more complexity by having one governing body (the PMC)?
> >>> What I am suggesting is that the driver project be somewhat of a
> >> subproject
> >>> or a "module". It can still have its own life cycle, just like it does
> >> now.
> >>>
> >>> On Sat, Jun 4, 2016 at 12:44 PM Nate McCall 
> >>> wrote:
> >>>
>  It doesnt. But then we add complexity in communicating and managing
>  versions, releases, etc. to the project. Again, from my experience
> with
>  hector, I just didnt want the hassle of owning that within the project
>  confines.
> 
>  On Sat, Jun 4, 2016 at 11:30 AM, James Carman <
> >>> ja...@carmanconsulting.com>
>  wrote:
> 
> > Who said the driver has to be released with the database?
> >
> > On Sat, Jun 4, 2016 at 12:29 PM Nate McCall 
> > wrote:
> >
> >> On Sat, Jun 4, 2016 at 10:05 AM, James Carman <
> > ja...@carmanconsulting.com>
> >> wrote:
> >>
> >>> So why not just donate the Java driver and keep that in house?
> > Cassandra
> >> is
> >>> a Java project. Makes sense to me.
> >>>
> >>>
> >> I won't deny there is an argument to be made here, but as a former
>  client
> >> maintainer (Hector), current ASF committer (Usergrid) and active
> > community
> >> member since late 2009, my opinion is that this would be a step
> > backwards.
> >>
> >> Maintaining Hector independently allowed me the freedom to release
>  major
> >> features with technology that I wanted to use while maintaining
>  backwards
> >> compatibility without having to be bound to the project's release
> >>> cycle
> > and
> >> process. (And to use a build system that didnt suck).
> >>
> >> The initial concern of the use of the word "controls" is *super*
> >> not
>  cool
> >> and I hope that this is being fixed. That said, the reality, from
> >> my
> >> (external to DataStax) perspective, is that this is not the case. I
>  like
> >> the current project separation the way it is and don't feel like
> >>> there
>  is
> >> any attempt at "control" of the java driver's direction and
>  development.
> >>
> >> -Nate
> >>
> >
> 
> 
> 
>  --
>  -
>  Nate McCall
>  Austin, TX
>  @zznate
> 
>  CTO
>  Apache Cassandra Consulting
>  http://www.thelastpickle.com
> 
> >>>
> >>
>

Re: Cassandra Java Driver and DataStax

[Michael Kjellman]

No need to argue your point to me anymore. I've already tuned you out.

These are good people who I consider my friends and insulting people just shows 
your arguments really have no merit. 

Good luck with your new driver contribution! I look forward to reviewing the 
code. 

Sent from my iPhone

> On Jun 4, 2016, at 10:10 AM, James Carman  wrote:
> 
> I apologized else-thread about that one.  It was a low blow.  Anyway, to
> answer your question. The Cassandra community wins!  How do we know if they
> won't make you pay for the driver in the future (after all your code is
> written against it)?  It has happened before.  Also, the rest of the
> community can have a say in the direction (because that's the Apache Way).
> The driver can be more intimate with the database, because it's the same
> people developing it.
> 
>> On Sat, Jun 4, 2016 at 1:06 PM Aleksey Yeschenko  wrote:
>> 
>> An eloquent and powerful response, but please, reply to my points instead
>> of resorting to ad hominem arguments.
>> 
>> In practical terms, who would benefit from such a merge, and who is
>> suffering from the current state of affairs?
>> 
>> --
>> AY
>> 
>> On 4 June 2016 at 18:03:05, James Carman (ja...@carmanconsulting.com)
>> wrote:
>> 
>> "Sr. Software Engineer at DataStax", imagine that.
>> 
>> On Sat, Jun 4, 2016 at 1:01 PM Aleksey Yeschenko 
>> wrote:
>> 
>>> As a member of that governing body (Cassandra PMC), I would much prefer
>>> not to deal with the drivers as well.
>>> 
>>> And I’m just as certain that java-driver - and other driver communities -
>>> would much rather prefer to keep their process and organisation instead
>> of
>>> being forced to conform to ours.
>>> 
>>> I’m finding it hard to see a single party that would benefit from such a
>>> merge, and who suffers from the current state of things.
>>> 
>>> --
>>> AY
>>> 
>>> On 4 June 2016 at 17:46:48, James Carman (ja...@carmanconsulting.com)
>>> wrote:
>>> 
>>> How does it add more complexity by having one governing body (the PMC)?
>>> What I am suggesting is that the driver project be somewhat of a
>> subproject
>>> or a "module". It can still have its own life cycle, just like it does
>> now.
>>> 
>>> On Sat, Jun 4, 2016 at 12:44 PM Nate McCall 
>>> wrote:
>>> 
 It doesnt. But then we add complexity in communicating and managing
 versions, releases, etc. to the project. Again, from my experience with
 hector, I just didnt want the hassle of owning that within the project
 confines.
 
 On Sat, Jun 4, 2016 at 11:30 AM, James Carman <
>>> ja...@carmanconsulting.com>
 wrote:
 
> Who said the driver has to be released with the database?
> 
> On Sat, Jun 4, 2016 at 12:29 PM Nate McCall 
> wrote:
> 
>> On Sat, Jun 4, 2016 at 10:05 AM, James Carman <
> ja...@carmanconsulting.com>
>> wrote:
>> 
>>> So why not just donate the Java driver and keep that in house?
> Cassandra
>> is
>>> a Java project. Makes sense to me.
>>> 
>>> 
>> I won't deny there is an argument to be made here, but as a former
 client
>> maintainer (Hector), current ASF committer (Usergrid) and active
> community
>> member since late 2009, my opinion is that this would be a step
> backwards.
>> 
>> Maintaining Hector independently allowed me the freedom to release
 major
>> features with technology that I wanted to use while maintaining
 backwards
>> compatibility without having to be bound to the project's release
>>> cycle
> and
>> process. (And to use a build system that didnt suck).
>> 
>> The initial concern of the use of the word "controls" is *super*
>> not
 cool
>> and I hope that this is being fixed. That said, the reality, from
>> my
>> (external to DataStax) perspective, is that this is not the case. I
 like
>> the current project separation the way it is and don't feel like
>>> there
 is
>> any attempt at "control" of the java driver's direction and
 development.
>> 
>> -Nate
>> 
> 
 
 
 
 --
 -
 Nate McCall
 Austin, TX
 @zznate
 
 CTO
 Apache Cassandra Consulting
 http://www.thelastpickle.com
 
>>> 
>> 

Re: Cassandra Java Driver and DataStax

[Brandon Williams]

First off, full disclosure: contributor, committer, PMC member, and
finally, Datastax employee, in about that order chronologically.

All of the drivers, as far as I know, are Apache licensed, just as is
Cassandra itself.  There is no 'control', there is only momentum, since
anyone can fork the code if needed and then perhaps gain the momentum if
Datastax loses it.  Nobody is locked in to anything, and no sufficient
traction has been found to take the momentum away from Datastax yet,
because at least in my own admittedly biased opinion, our drivers team has
done an excellent job of accepting community feedback and requests.

tl;dr don't fix what is not broken

On Fri, Jun 3, 2016 at 11:11 PM, Mattmann, Chris A (3980) <
chris.a.mattm...@jpl.nasa.gov> wrote:

> Thanks Jason for the information - I’m going to continue
> researching and hope more people will chime in that are on
> the PMC.
>
> Thank you.
>
> Cheers,
> Chris
>
> ++
> Chris Mattmann, Ph.D.
> Chief Architect
> Instrument Software and Science Data Systems Section (398)
> NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
> Office: 168-519, Mailstop: 168-527
> Email: chris.a.mattm...@nasa.gov
> WWW:  http://sunset.usc.edu/~mattmann/
> ++
> Director, Information Retrieval and Data Science Group (IRDS)
> Adjunct Associate Professor, Computer Science Department
> University of Southern California, Los Angeles, CA 90089 USA
> WWW: http://irds.usc.edu/
> ++
>
>
>
>
>
>
>
>
>
> On 6/3/16, 8:33 PM, "Jason Brown"  wrote:
>
> >
> >
> >
> >The client-server protocol is well defined in the Cassandra repo, so any
> one may implement a client library for any language. However, it is a far
> from trivial task, so not many folks build their own. Thus, already-built
> drivers tend to become the de facto
> > standard, but we (the Apache Cassandra committers/PMC) do not/have not
> blessed any vendor's driver(s) as official.
> >
> >
> >As to why there is not a canonical set of drivers in the Cassandra repo,
> well, we've just never gotten into that game as an OSS community.
> >
> >
> >-Jason (not affiliated with DataStax)
> >
> >On Friday, June 3, 2016, Johan Edstrom  wrote:
> >
> >
> >
> >On Jun 3, 2016, at 9:14 PM, Jeff Jirsa  > wrote:
> >
> >
> >https://github.com/hector-client/hector
> >
> >
> >
> >
> >
> >
> >So - that isn’t doing CQL, Right?
> >
> >
> >https://github.com/Netflix/astyanax
> >
> >
> >
> >
> >
> >
> >Upgrading to CQL?
> >
> >
> >
> >http://doanduyhai.github.io/Achilles/
> >
> >
> >
> >
> >
> >
> >
> >Which driver do you use?
> >
> >
> >https://github.com/noorq/casser
> >
> >
> >
> >
> >
> >
> >2.1.5
> >
> >
> >
> >
> >
> >https://github.com/impetus-opensource/Kundera
> >
> >
> >
> >
> >
> >
> >
> >ds-driver
> >
> >false
> >
> >
> >cassandra-core
> >cassandra-ds-driver
> >
> >
> >
> >thrift
> >
> >false
> >
> >
> >cassandra-core
> >cassandra-thrift
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >https://github.com/deanhiller/playorm
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >- Jeff ( Not affiliated with datastax )
> >
> >
> >
> >
> >
> >On 6/3/16, 7:58 PM, "Johan Edstrom"  > wrote:
> >
> >
> >How many Java drivers could you point out?
> >Doesn’t it strike you slightly off that you’d not have a driver for a DB
> >in the same project you found the DB?
> >
> >
> >
> >On Jun 3, 2016, at 8:51 PM, Dave Brosius  > wrote:
> >
> >There are many drivers for cassandra, supplied by various individuals and
> groups, one of those drivers was started by people at datastax which is
> available as an opensource project.
> >
> >The open source project is not open to any random person on the internet
> to commit to (just like any open source project), so i suppose in that
> regard there is some 'control'. But i doubt that is what you are fishing
> for.
> >
> >--dave
> >
> >(not affiliated with datastax)
> >
> >On 06/03/2016 10:29 PM, Chris Mattmann wrote:
> >Hi All,
> >
> >I’m investigating something a few ASF members contacted
> >me about and pointed out, so I’m hoping you can help
> >guide me here as a community. I have heard that a company,
> >DataStax, whose marketing material mentions it as the only
> >Cassandra vendor, “controls” the Java Driver for Apache
> >Cassandra.
> >
> >Of course, no company “controls” our projects or its code,
> >so I told the folks that mentioned it to me that I’d investigate
> >with my board hat on.
> >
> >I’d like to hear the community’s thoughts here on this. Does
> >anyone in the community see this “controlling” behavior going
> >on? Please speak 

Re: Cassandra Java Driver and DataStax

[Aleksey Yeschenko]

The java-driver is fully Apache licensed. In the implausible scenario something 
like that happens, we can always simply fork it and start maintaining it 
ourselves.

As long as java-driver community are good community citizens - as they are, and 
have been since day one - we are happy to have that non-trivial amount of work 
done by them.

Also, I’m curious to know where/when ‘it has happened before’.

-- 
AY

On 4 June 2016 at 18:10:35, James Carman (ja...@carmanconsulting.com) wrote:

I apologized else-thread about that one. It was a low blow. Anyway, to  
answer your question. The Cassandra community wins! How do we know if they  
won't make you pay for the driver in the future (after all your code is  
written against it)? It has happened before. Also, the rest of the  
community can have a say in the direction (because that's the Apache Way).  
The driver can be more intimate with the database, because it's the same  
people developing it.  

On Sat, Jun 4, 2016 at 1:06 PM Aleksey Yeschenko  wrote:  

> An eloquent and powerful response, but please, reply to my points instead  
> of resorting to ad hominem arguments.  
>  
> In practical terms, who would benefit from such a merge, and who is  
> suffering from the current state of affairs?  
>  
> --  
> AY  
>  
> On 4 June 2016 at 18:03:05, James Carman (ja...@carmanconsulting.com)  
> wrote:  
>  
> "Sr. Software Engineer at DataStax", imagine that.  
>  
> On Sat, Jun 4, 2016 at 1:01 PM Aleksey Yeschenko   
> wrote:  
>  
> > As a member of that governing body (Cassandra PMC), I would much prefer  
> > not to deal with the drivers as well.  
> >  
> > And I’m just as certain that java-driver - and other driver communities -  
> > would much rather prefer to keep their process and organisation instead  
> of  
> > being forced to conform to ours.  
> >  
> > I’m finding it hard to see a single party that would benefit from such a  
> > merge, and who suffers from the current state of things.  
> >  
> > --  
> > AY  
> >  
> > On 4 June 2016 at 17:46:48, James Carman (ja...@carmanconsulting.com)  
> > wrote:  
> >  
> > How does it add more complexity by having one governing body (the PMC)?  
> > What I am suggesting is that the driver project be somewhat of a  
> subproject  
> > or a "module". It can still have its own life cycle, just like it does  
> now.  
> >  
> > On Sat, Jun 4, 2016 at 12:44 PM Nate McCall   
> > wrote:  
> >  
> > > It doesnt. But then we add complexity in communicating and managing  
> > > versions, releases, etc. to the project. Again, from my experience with  
> > > hector, I just didnt want the hassle of owning that within the project  
> > > confines.  
> > >  
> > > On Sat, Jun 4, 2016 at 11:30 AM, James Carman <  
> > ja...@carmanconsulting.com>  
> > > wrote:  
> > >  
> > > > Who said the driver has to be released with the database?  
> > > >  
> > > > On Sat, Jun 4, 2016 at 12:29 PM Nate McCall   
> > > > wrote:  
> > > >  
> > > > > On Sat, Jun 4, 2016 at 10:05 AM, James Carman <  
> > > > ja...@carmanconsulting.com>  
> > > > > wrote:  
> > > > >  
> > > > > > So why not just donate the Java driver and keep that in house?  
> > > > Cassandra  
> > > > > is  
> > > > > > a Java project. Makes sense to me.  
> > > > > >  
> > > > > >  
> > > > > I won't deny there is an argument to be made here, but as a former  
> > > client  
> > > > > maintainer (Hector), current ASF committer (Usergrid) and active  
> > > > community  
> > > > > member since late 2009, my opinion is that this would be a step  
> > > > backwards.  
> > > > >  
> > > > > Maintaining Hector independently allowed me the freedom to release  
> > > major  
> > > > > features with technology that I wanted to use while maintaining  
> > > backwards  
> > > > > compatibility without having to be bound to the project's release  
> > cycle  
> > > > and  
> > > > > process. (And to use a build system that didnt suck).  
> > > > >  
> > > > > The initial concern of the use of the word "controls" is *super*  
> not  
> > > cool  
> > > > > and I hope that this is being fixed. That said, the reality, from  
> my  
> > > > > (external to DataStax) perspective, is that this is not the case. I  
> > > like  
> > > > > the current project separation the way it is and don't feel like  
> > there  
> > > is  
> > > > > any attempt at "control" of the java driver's direction and  
> > > development.  
> > > > >  
> > > > > -Nate  
> > > > >  
> > > >  
> > >  
> > >  
> > >  
> > > --  
> > > -  
> > > Nate McCall  
> > > Austin, TX  
> > > @zznate  
> > >  
> > > CTO  
> > > Apache Cassandra Consulting  
> > > http://www.thelastpickle.com  
> > >  
> >  
>  

Re: Cassandra Java Driver and DataStax

[Nate McCall]

On Sat, Jun 4, 2016 at 12:07 PM, James Carman 
wrote:
>
> On Sat, Jun 4, 2016 at 1:05 PM Nate McCall  wrote:
>
> > Whereas the health of my company and title rely heavily on a thriving
open
> > source community, yet Aleksey and I are in agreement. Let's keep it up
at
> > the level of the project and technical merits, please.
> >
> >
> Okay, that might have been a bit of a low-blow, and I apologize.  But,
> we've seen this sort of thing happen around the organization.  We need to
> make sure that things stay "fair" for everyone and that outside influences
> don't unduly drive the project.


I understand and I have been equally frustrated by other projects recently.
At the end of the day, I do appreciate the effort in looking into this.

I'm going to re-iterate and call it a day:
- I dont feel like there is an issue with the current driver being separate
- There are some technical and project direction reasons whey it's good
idea to keep it out of the PMC's purview

Cheers,
-Nate

Re: Cassandra Java Driver and DataStax

[James Carman]

I apologized else-thread about that one.  It was a low blow.  Anyway, to
answer your question. The Cassandra community wins!  How do we know if they
won't make you pay for the driver in the future (after all your code is
written against it)?  It has happened before.  Also, the rest of the
community can have a say in the direction (because that's the Apache Way).
The driver can be more intimate with the database, because it's the same
people developing it.

On Sat, Jun 4, 2016 at 1:06 PM Aleksey Yeschenko  wrote:

> An eloquent and powerful response, but please, reply to my points instead
> of resorting to ad hominem arguments.
>
> In practical terms, who would benefit from such a merge, and who is
> suffering from the current state of affairs?
>
> --
> AY
>
> On 4 June 2016 at 18:03:05, James Carman (ja...@carmanconsulting.com)
> wrote:
>
> "Sr. Software Engineer at DataStax", imagine that.
>
> On Sat, Jun 4, 2016 at 1:01 PM Aleksey Yeschenko 
> wrote:
>
> > As a member of that governing body (Cassandra PMC), I would much prefer
> > not to deal with the drivers as well.
> >
> > And I’m just as certain that java-driver - and other driver communities -
> > would much rather prefer to keep their process and organisation instead
> of
> > being forced to conform to ours.
> >
> > I’m finding it hard to see a single party that would benefit from such a
> > merge, and who suffers from the current state of things.
> >
> > --
> > AY
> >
> > On 4 June 2016 at 17:46:48, James Carman (ja...@carmanconsulting.com)
> > wrote:
> >
> > How does it add more complexity by having one governing body (the PMC)?
> > What I am suggesting is that the driver project be somewhat of a
> subproject
> > or a "module". It can still have its own life cycle, just like it does
> now.
> >
> > On Sat, Jun 4, 2016 at 12:44 PM Nate McCall 
> > wrote:
> >
> > > It doesnt. But then we add complexity in communicating and managing
> > > versions, releases, etc. to the project. Again, from my experience with
> > > hector, I just didnt want the hassle of owning that within the project
> > > confines.
> > >
> > > On Sat, Jun 4, 2016 at 11:30 AM, James Carman <
> > ja...@carmanconsulting.com>
> > > wrote:
> > >
> > > > Who said the driver has to be released with the database?
> > > >
> > > > On Sat, Jun 4, 2016 at 12:29 PM Nate McCall 
> > > > wrote:
> > > >
> > > > > On Sat, Jun 4, 2016 at 10:05 AM, James Carman <
> > > > ja...@carmanconsulting.com>
> > > > > wrote:
> > > > >
> > > > > > So why not just donate the Java driver and keep that in house?
> > > > Cassandra
> > > > > is
> > > > > > a Java project. Makes sense to me.
> > > > > >
> > > > > >
> > > > > I won't deny there is an argument to be made here, but as a former
> > > client
> > > > > maintainer (Hector), current ASF committer (Usergrid) and active
> > > > community
> > > > > member since late 2009, my opinion is that this would be a step
> > > > backwards.
> > > > >
> > > > > Maintaining Hector independently allowed me the freedom to release
> > > major
> > > > > features with technology that I wanted to use while maintaining
> > > backwards
> > > > > compatibility without having to be bound to the project's release
> > cycle
> > > > and
> > > > > process. (And to use a build system that didnt suck).
> > > > >
> > > > > The initial concern of the use of the word "controls" is *super*
> not
> > > cool
> > > > > and I hope that this is being fixed. That said, the reality, from
> my
> > > > > (external to DataStax) perspective, is that this is not the case. I
> > > like
> > > > > the current project separation the way it is and don't feel like
> > there
> > > is
> > > > > any attempt at "control" of the java driver's direction and
> > > development.
> > > > >
> > > > > -Nate
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > > -
> > > Nate McCall
> > > Austin, TX
> > > @zznate
> > >
> > > CTO
> > > Apache Cassandra Consulting
> > > http://www.thelastpickle.com
> > >
> >
>

Re: Cassandra Java Driver and DataStax

[James Carman]

On Sat, Jun 4, 2016 at 1:05 PM Nate McCall  wrote:

> Whereas the health of my company and title rely heavily on a thriving open
> source community, yet Aleksey and I are in agreement. Let's keep it up at
> the level of the project and technical merits, please.
>
>
Okay, that might have been a bit of a low-blow, and I apologize.  But,
we've seen this sort of thing happen around the organization.  We need to
make sure that things stay "fair" for everyone and that outside influences
don't unduly drive the project.

Re: Cassandra Java Driver and DataStax

[Aleksey Yeschenko]

An eloquent and powerful response, but please, reply to my points instead of 
resorting to ad hominem arguments.

In practical terms, who would benefit from such a merge, and who is suffering 
from the current state of affairs?

-- 
AY

On 4 June 2016 at 18:03:05, James Carman (ja...@carmanconsulting.com) wrote:

"Sr. Software Engineer at DataStax", imagine that.  

On Sat, Jun 4, 2016 at 1:01 PM Aleksey Yeschenko  wrote:  

> As a member of that governing body (Cassandra PMC), I would much prefer  
> not to deal with the drivers as well.  
>  
> And I’m just as certain that java-driver - and other driver communities -  
> would much rather prefer to keep their process and organisation instead of  
> being forced to conform to ours.  
>  
> I’m finding it hard to see a single party that would benefit from such a  
> merge, and who suffers from the current state of things.  
>  
> --  
> AY  
>  
> On 4 June 2016 at 17:46:48, James Carman (ja...@carmanconsulting.com)  
> wrote:  
>  
> How does it add more complexity by having one governing body (the PMC)?  
> What I am suggesting is that the driver project be somewhat of a subproject  
> or a "module". It can still have its own life cycle, just like it does now.  
>  
> On Sat, Jun 4, 2016 at 12:44 PM Nate McCall   
> wrote:  
>  
> > It doesnt. But then we add complexity in communicating and managing  
> > versions, releases, etc. to the project. Again, from my experience with  
> > hector, I just didnt want the hassle of owning that within the project  
> > confines.  
> >  
> > On Sat, Jun 4, 2016 at 11:30 AM, James Carman <  
> ja...@carmanconsulting.com>  
> > wrote:  
> >  
> > > Who said the driver has to be released with the database?  
> > >  
> > > On Sat, Jun 4, 2016 at 12:29 PM Nate McCall   
> > > wrote:  
> > >  
> > > > On Sat, Jun 4, 2016 at 10:05 AM, James Carman <  
> > > ja...@carmanconsulting.com>  
> > > > wrote:  
> > > >  
> > > > > So why not just donate the Java driver and keep that in house?  
> > > Cassandra  
> > > > is  
> > > > > a Java project. Makes sense to me.  
> > > > >  
> > > > >  
> > > > I won't deny there is an argument to be made here, but as a former  
> > client  
> > > > maintainer (Hector), current ASF committer (Usergrid) and active  
> > > community  
> > > > member since late 2009, my opinion is that this would be a step  
> > > backwards.  
> > > >  
> > > > Maintaining Hector independently allowed me the freedom to release  
> > major  
> > > > features with technology that I wanted to use while maintaining  
> > backwards  
> > > > compatibility without having to be bound to the project's release  
> cycle  
> > > and  
> > > > process. (And to use a build system that didnt suck).  
> > > >  
> > > > The initial concern of the use of the word "controls" is *super* not  
> > cool  
> > > > and I hope that this is being fixed. That said, the reality, from my  
> > > > (external to DataStax) perspective, is that this is not the case. I  
> > like  
> > > > the current project separation the way it is and don't feel like  
> there  
> > is  
> > > > any attempt at "control" of the java driver's direction and  
> > development.  
> > > >  
> > > > -Nate  
> > > >  
> > >  
> >  
> >  
> >  
> > --  
> > -  
> > Nate McCall  
> > Austin, TX  
> > @zznate  
> >  
> > CTO  
> > Apache Cassandra Consulting  
> > http://www.thelastpickle.com  
> >  
>  

Re: Cassandra Java Driver and DataStax

[Nate McCall]

Whereas the health of my company and title rely heavily on a thriving open
source community, yet Aleksey and I are in agreement. Let's keep it up at
the level of the project and technical merits, please.

On Sat, Jun 4, 2016 at 12:02 PM, James Carman 
wrote:

> "Sr. Software Engineer at DataStax", imagine that.
>
> On Sat, Jun 4, 2016 at 1:01 PM Aleksey Yeschenko 
> wrote:
>
> > As a member of that governing body (Cassandra PMC), I would much prefer
> > not to deal with the drivers as well.
> >
> > And I’m just as certain that java-driver - and other driver communities -
> > would much rather prefer to keep their process and organisation instead
> of
> > being forced to conform to ours.
> >
> > I’m finding it hard to see a single party that would benefit from such a
> > merge, and who suffers from the current state of things.
> >
> > --
> > AY
> >
> > On 4 June 2016 at 17:46:48, James Carman (ja...@carmanconsulting.com)
> > wrote:
> >
> > How does it add more complexity by having one governing body (the PMC)?
> > What I am suggesting is that the driver project be somewhat of a
> subproject
> > or a "module". It can still have its own life cycle, just like it does
> now.
> >
> > On Sat, Jun 4, 2016 at 12:44 PM Nate McCall 
> > wrote:
> >
> > > It doesnt. But then we add complexity in communicating and managing
> > > versions, releases, etc. to the project. Again, from my experience with
> > > hector, I just didnt want the hassle of owning that within the project
> > > confines.
> > >
> > > On Sat, Jun 4, 2016 at 11:30 AM, James Carman <
> > ja...@carmanconsulting.com>
> > > wrote:
> > >
> > > > Who said the driver has to be released with the database?
> > > >
> > > > On Sat, Jun 4, 2016 at 12:29 PM Nate McCall 
> > > > wrote:
> > > >
> > > > > On Sat, Jun 4, 2016 at 10:05 AM, James Carman <
> > > > ja...@carmanconsulting.com>
> > > > > wrote:
> > > > >
> > > > > > So why not just donate the Java driver and keep that in house?
> > > > Cassandra
> > > > > is
> > > > > > a Java project. Makes sense to me.
> > > > > >
> > > > > >
> > > > > I won't deny there is an argument to be made here, but as a former
> > > client
> > > > > maintainer (Hector), current ASF committer (Usergrid) and active
> > > > community
> > > > > member since late 2009, my opinion is that this would be a step
> > > > backwards.
> > > > >
> > > > > Maintaining Hector independently allowed me the freedom to release
> > > major
> > > > > features with technology that I wanted to use while maintaining
> > > backwards
> > > > > compatibility without having to be bound to the project's release
> > cycle
> > > > and
> > > > > process. (And to use a build system that didnt suck).
> > > > >
> > > > > The initial concern of the use of the word "controls" is *super*
> not
> > > cool
> > > > > and I hope that this is being fixed. That said, the reality, from
> my
> > > > > (external to DataStax) perspective, is that this is not the case. I
> > > like
> > > > > the current project separation the way it is and don't feel like
> > there
> > > is
> > > > > any attempt at "control" of the java driver's direction and
> > > development.
> > > > >
> > > > > -Nate
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > > -
> > > Nate McCall
> > > Austin, TX
> > > @zznate
> > >
> > > CTO
> > > Apache Cassandra Consulting
> > > http://www.thelastpickle.com
> > >
> >
>



-- 
-
Nate McCall
Austin, TX
@zznate

CTO
Apache Cassandra Consulting
http://www.thelastpickle.com

Re: Cassandra Java Driver and DataStax

[James Carman]

On Sat, Jun 4, 2016 at 1:02 PM Nate McCall  wrote:

> For me, most of the complexity would have been dealing with the governing
> body :)
>
> Seriously though, being independant allowed me to experiment with things
> like going directly to the internal Storage API from the client which would
> have definitely been -1'ed by some committers (rightly so as it would have
> provided a level of endorsement of this type of client access, making
> refactoring more difficult).
>
>
Right, you wanted "control" of you project.  I get it.

Re: Cassandra Java Driver and DataStax

[James Carman]

"Sr. Software Engineer at DataStax", imagine that.

On Sat, Jun 4, 2016 at 1:01 PM Aleksey Yeschenko  wrote:

> As a member of that governing body (Cassandra PMC), I would much prefer
> not to deal with the drivers as well.
>
> And I’m just as certain that java-driver - and other driver communities -
> would much rather prefer to keep their process and organisation instead of
> being forced to conform to ours.
>
> I’m finding it hard to see a single party that would benefit from such a
> merge, and who suffers from the current state of things.
>
> --
> AY
>
> On 4 June 2016 at 17:46:48, James Carman (ja...@carmanconsulting.com)
> wrote:
>
> How does it add more complexity by having one governing body (the PMC)?
> What I am suggesting is that the driver project be somewhat of a subproject
> or a "module". It can still have its own life cycle, just like it does now.
>
> On Sat, Jun 4, 2016 at 12:44 PM Nate McCall 
> wrote:
>
> > It doesnt. But then we add complexity in communicating and managing
> > versions, releases, etc. to the project. Again, from my experience with
> > hector, I just didnt want the hassle of owning that within the project
> > confines.
> >
> > On Sat, Jun 4, 2016 at 11:30 AM, James Carman <
> ja...@carmanconsulting.com>
> > wrote:
> >
> > > Who said the driver has to be released with the database?
> > >
> > > On Sat, Jun 4, 2016 at 12:29 PM Nate McCall 
> > > wrote:
> > >
> > > > On Sat, Jun 4, 2016 at 10:05 AM, James Carman <
> > > ja...@carmanconsulting.com>
> > > > wrote:
> > > >
> > > > > So why not just donate the Java driver and keep that in house?
> > > Cassandra
> > > > is
> > > > > a Java project. Makes sense to me.
> > > > >
> > > > >
> > > > I won't deny there is an argument to be made here, but as a former
> > client
> > > > maintainer (Hector), current ASF committer (Usergrid) and active
> > > community
> > > > member since late 2009, my opinion is that this would be a step
> > > backwards.
> > > >
> > > > Maintaining Hector independently allowed me the freedom to release
> > major
> > > > features with technology that I wanted to use while maintaining
> > backwards
> > > > compatibility without having to be bound to the project's release
> cycle
> > > and
> > > > process. (And to use a build system that didnt suck).
> > > >
> > > > The initial concern of the use of the word "controls" is *super* not
> > cool
> > > > and I hope that this is being fixed. That said, the reality, from my
> > > > (external to DataStax) perspective, is that this is not the case. I
> > like
> > > > the current project separation the way it is and don't feel like
> there
> > is
> > > > any attempt at "control" of the java driver's direction and
> > development.
> > > >
> > > > -Nate
> > > >
> > >
> >
> >
> >
> > --
> > -
> > Nate McCall
> > Austin, TX
> > @zznate
> >
> > CTO
> > Apache Cassandra Consulting
> > http://www.thelastpickle.com
> >
>

Re: Cassandra Java Driver and DataStax

[Nate McCall]

For me, most of the complexity would have been dealing with the governing
body :)

Seriously though, being independant allowed me to experiment with things
like going directly to the internal Storage API from the client which would
have definitely been -1'ed by some committers (rightly so as it would have
provided a level of endorsement of this type of client access, making
refactoring more difficult).

On Sat, Jun 4, 2016 at 11:46 AM, James Carman 
wrote:

> How does it add more complexity by having one governing body (the PMC)?
> What I am suggesting is that the driver project be somewhat of a subproject
> or a "module". It can still have its own life cycle, just like it does now.
>
> On Sat, Jun 4, 2016 at 12:44 PM Nate McCall 
> wrote:
>
> > It doesnt. But then we add complexity in communicating and managing
> > versions, releases, etc. to the project. Again, from my experience with
> > hector, I just didnt want the hassle of owning that within the project
> > confines.
> >
> > On Sat, Jun 4, 2016 at 11:30 AM, James Carman <
> ja...@carmanconsulting.com>
> > wrote:
> >
> > > Who said the driver has to be released with the database?
> > >
> > > On Sat, Jun 4, 2016 at 12:29 PM Nate McCall 
> > > wrote:
> > >
> > > > On Sat, Jun 4, 2016 at 10:05 AM, James Carman <
> > > ja...@carmanconsulting.com>
> > > > wrote:
> > > >
> > > > > So why not just donate the Java driver and keep that in house?
> > > Cassandra
> > > > is
> > > > > a Java project. Makes sense to me.
> > > > >
> > > > >
> > > > I won't deny there is an argument to be made here, but as a former
> > client
> > > > maintainer (Hector), current ASF committer (Usergrid) and active
> > > community
> > > > member since late 2009, my opinion is that this would be a step
> > > backwards.
> > > >
> > > > Maintaining Hector independently allowed me the freedom to release
> > major
> > > > features with technology that I wanted to use while maintaining
> > backwards
> > > > compatibility without having to be bound to the project's release
> cycle
> > > and
> > > > process. (And to use a build system that didnt suck).
> > > >
> > > > The initial concern of the use of the word "controls" is *super* not
> > cool
> > > > and I hope that this is being fixed. That said, the reality, from my
> > > > (external to DataStax) perspective, is that this is not the case. I
> > like
> > > > the current project separation the way it is and don't feel like
> there
> > is
> > > > any attempt at "control" of the java driver's direction and
> > development.
> > > >
> > > > -Nate
> > > >
> > >
> >
> >
> >
> > --
> > -
> > Nate McCall
> > Austin, TX
> > @zznate
> >
> > CTO
> > Apache Cassandra Consulting
> > http://www.thelastpickle.com
> >
>



-- 
-
Nate McCall
Austin, TX
@zznate

CTO
Apache Cassandra Consulting
http://www.thelastpickle.com

Re: Cassandra Java Driver and DataStax

[Aleksey Yeschenko]

As a member of that governing body (Cassandra PMC), I would much prefer not to 
deal with the drivers as well.

And I’m just as certain that java-driver - and other driver communities - would 
much rather prefer to keep their process and organisation instead of being 
forced to conform to ours.

I’m finding it hard to see a single party that would benefit from such a merge, 
and who suffers from the current state of things.

-- 
AY

On 4 June 2016 at 17:46:48, James Carman (ja...@carmanconsulting.com) wrote:

How does it add more complexity by having one governing body (the PMC)?  
What I am suggesting is that the driver project be somewhat of a subproject  
or a "module". It can still have its own life cycle, just like it does now.  

On Sat, Jun 4, 2016 at 12:44 PM Nate McCall  wrote:  

> It doesnt. But then we add complexity in communicating and managing  
> versions, releases, etc. to the project. Again, from my experience with  
> hector, I just didnt want the hassle of owning that within the project  
> confines.  
>  
> On Sat, Jun 4, 2016 at 11:30 AM, James Carman   
> wrote:  
>  
> > Who said the driver has to be released with the database?  
> >  
> > On Sat, Jun 4, 2016 at 12:29 PM Nate McCall   
> > wrote:  
> >  
> > > On Sat, Jun 4, 2016 at 10:05 AM, James Carman <  
> > ja...@carmanconsulting.com>  
> > > wrote:  
> > >  
> > > > So why not just donate the Java driver and keep that in house?  
> > Cassandra  
> > > is  
> > > > a Java project. Makes sense to me.  
> > > >  
> > > >  
> > > I won't deny there is an argument to be made here, but as a former  
> client  
> > > maintainer (Hector), current ASF committer (Usergrid) and active  
> > community  
> > > member since late 2009, my opinion is that this would be a step  
> > backwards.  
> > >  
> > > Maintaining Hector independently allowed me the freedom to release  
> major  
> > > features with technology that I wanted to use while maintaining  
> backwards  
> > > compatibility without having to be bound to the project's release cycle  
> > and  
> > > process. (And to use a build system that didnt suck).  
> > >  
> > > The initial concern of the use of the word "controls" is *super* not  
> cool  
> > > and I hope that this is being fixed. That said, the reality, from my  
> > > (external to DataStax) perspective, is that this is not the case. I  
> like  
> > > the current project separation the way it is and don't feel like there  
> is  
> > > any attempt at "control" of the java driver's direction and  
> development.  
> > >  
> > > -Nate  
> > >  
> >  
>  
>  
>  
> --  
> -  
> Nate McCall  
> Austin, TX  
> @zznate  
>  
> CTO  
> Apache Cassandra Consulting  
> http://www.thelastpickle.com  
>  

Re: Cassandra Java Driver and DataStax

[James Carman]

How does it add more complexity by having one governing body (the PMC)?
What I am suggesting is that the driver project be somewhat of a subproject
or a "module". It can still have its own life cycle, just like it does now.

On Sat, Jun 4, 2016 at 12:44 PM Nate McCall  wrote:

> It doesnt. But then we add complexity in communicating and managing
> versions, releases, etc. to the project. Again, from my experience with
> hector, I just didnt want the hassle of owning that within the project
> confines.
>
> On Sat, Jun 4, 2016 at 11:30 AM, James Carman 
> wrote:
>
> > Who said the driver has to be released with the database?
> >
> > On Sat, Jun 4, 2016 at 12:29 PM Nate McCall 
> > wrote:
> >
> > > On Sat, Jun 4, 2016 at 10:05 AM, James Carman <
> > ja...@carmanconsulting.com>
> > > wrote:
> > >
> > > > So why not just donate the Java driver and keep that in house?
> > Cassandra
> > > is
> > > > a Java project. Makes sense to me.
> > > >
> > > >
> > > I won't deny there is an argument to be made here, but as a former
> client
> > > maintainer (Hector), current ASF committer (Usergrid) and active
> > community
> > > member since late 2009, my opinion is that this would be a step
> > backwards.
> > >
> > > Maintaining Hector independently allowed me the freedom to release
> major
> > > features with technology that I wanted to use while maintaining
> backwards
> > > compatibility without having to be bound to the project's release cycle
> > and
> > > process. (And to use a build system that didnt suck).
> > >
> > > The initial concern of the use of the word "controls" is *super* not
> cool
> > > and I hope that this is being fixed. That said, the reality, from my
> > > (external to DataStax) perspective, is that this is not the case. I
> like
> > > the current project separation the way it is and don't feel like there
> is
> > > any attempt at "control" of the java driver's direction and
> development.
> > >
> > > -Nate
> > >
> >
>
>
>
> --
> -
> Nate McCall
> Austin, TX
> @zznate
>
> CTO
> Apache Cassandra Consulting
> http://www.thelastpickle.com
>

Re: Cassandra Java Driver and DataStax

[Nate McCall]

It doesnt. But then we add complexity in communicating and managing
versions, releases, etc. to the project. Again, from my experience with
hector, I just didnt want the hassle of owning that within the project
confines.

On Sat, Jun 4, 2016 at 11:30 AM, James Carman 
wrote:

> Who said the driver has to be released with the database?
>
> On Sat, Jun 4, 2016 at 12:29 PM Nate McCall 
> wrote:
>
> > On Sat, Jun 4, 2016 at 10:05 AM, James Carman <
> ja...@carmanconsulting.com>
> > wrote:
> >
> > > So why not just donate the Java driver and keep that in house?
> Cassandra
> > is
> > > a Java project. Makes sense to me.
> > >
> > >
> > I won't deny there is an argument to be made here, but as a former client
> > maintainer (Hector), current ASF committer (Usergrid) and active
> community
> > member since late 2009, my opinion is that this would be a step
> backwards.
> >
> > Maintaining Hector independently allowed me the freedom to release major
> > features with technology that I wanted to use while maintaining backwards
> > compatibility without having to be bound to the project's release cycle
> and
> > process. (And to use a build system that didnt suck).
> >
> > The initial concern of the use of the word "controls" is *super* not cool
> > and I hope that this is being fixed. That said, the reality, from my
> > (external to DataStax) perspective, is that this is not the case. I like
> > the current project separation the way it is and don't feel like there is
> > any attempt at "control" of the java driver's direction and development.
> >
> > -Nate
> >
>



-- 
-
Nate McCall
Austin, TX
@zznate

CTO
Apache Cassandra Consulting
http://www.thelastpickle.com

Re: Cassandra Java Driver and DataStax

[James Carman]

Who said the driver has to be released with the database?

On Sat, Jun 4, 2016 at 12:29 PM Nate McCall  wrote:

> On Sat, Jun 4, 2016 at 10:05 AM, James Carman 
> wrote:
>
> > So why not just donate the Java driver and keep that in house? Cassandra
> is
> > a Java project. Makes sense to me.
> >
> >
> I won't deny there is an argument to be made here, but as a former client
> maintainer (Hector), current ASF committer (Usergrid) and active community
> member since late 2009, my opinion is that this would be a step backwards.
>
> Maintaining Hector independently allowed me the freedom to release major
> features with technology that I wanted to use while maintaining backwards
> compatibility without having to be bound to the project's release cycle and
> process. (And to use a build system that didnt suck).
>
> The initial concern of the use of the word "controls" is *super* not cool
> and I hope that this is being fixed. That said, the reality, from my
> (external to DataStax) perspective, is that this is not the case. I like
> the current project separation the way it is and don't feel like there is
> any attempt at "control" of the java driver's direction and development.
>
> -Nate
>

Re: Cassandra Java Driver and DataStax

[Nate McCall]

On Sat, Jun 4, 2016 at 10:05 AM, James Carman 
wrote:

> So why not just donate the Java driver and keep that in house? Cassandra is
> a Java project. Makes sense to me.
>
>
I won't deny there is an argument to be made here, but as a former client
maintainer (Hector), current ASF committer (Usergrid) and active community
member since late 2009, my opinion is that this would be a step backwards.

Maintaining Hector independently allowed me the freedom to release major
features with technology that I wanted to use while maintaining backwards
compatibility without having to be bound to the project's release cycle and
process. (And to use a build system that didnt suck).

The initial concern of the use of the word "controls" is *super* not cool
and I hope that this is being fixed. That said, the reality, from my
(external to DataStax) perspective, is that this is not the case. I like
the current project separation the way it is and don't feel like there is
any attempt at "control" of the java driver's direction and development.

-Nate

Re: Cassandra Java Driver and DataStax

[James Carman]

So why not just donate the Java driver and keep that in house? Cassandra is
a Java project. Makes sense to me.

On Sat, Jun 4, 2016 at 10:58 AM Jonathan Ellis  wrote:

> On Sat, Jun 4, 2016 at 8:59 AM, Chris Mattmann 
> wrote:
>
> > Thanks Jonathan. I’m starting to get a clearer idea of what’s
> > going on here. Do you think it was a walled garden in terms of
> > making reviews for incoming driver patches when you did have
> > them in the tree?
>
>
> Not exactly sure what you mean, but we did see our responsibility in terms
> of maintaining our project extend to reviewing patches for drivers while
> they were in tree.
>
>
> > What you are talking about in the first paragraph
> > is precisely the reason that your community expands and that you
> > create new PMC members and committers as they contribute things.
> >
>
> In principle I agree, but when you have six or seven or more parts of the
> tree whose committers' expertise does not overlap, I think it really does
> make sense for these to be organized as separate projects.
>
> Furthermore, it sounds like you are saying for Java and Python
> > these weren’t “fly by” contributions and more work has gone on
> > in those drivers than e.g., compared to Clojure, C++, etc.
> >
>
> That was the case five years ago, and would probably still be the case if
> we had kept drivers in tree.  Making them their own projects has resulted
> in more and higher quality drivers overall.
>
> I note that among similar Apache projects,
>
> - CouchDB drivers are not maintained in-tree
> 
> - HBase maintains only a Java driver in-tree
> - Accumulo maintains only a Java driver in-tree
>
> Put another way, I see four projects that have all more or less
> independently concluded that trying to maintain a lot of drivers as part of
> a single Apache project is not a good way to organize things.
>
> --
> Jonathan Ellis
> Project Chair, Apache Cassandra
> co-founder, http://www.datastax.com
> @spyced
>

Re: Cassandra Java Driver and DataStax

[Jonathan Ellis]

On Sat, Jun 4, 2016 at 8:59 AM, Chris Mattmann  wrote:

> Thanks Jonathan. I’m starting to get a clearer idea of what’s
> going on here. Do you think it was a walled garden in terms of
> making reviews for incoming driver patches when you did have
> them in the tree?


Not exactly sure what you mean, but we did see our responsibility in terms
of maintaining our project extend to reviewing patches for drivers while
they were in tree.


> What you are talking about in the first paragraph
> is precisely the reason that your community expands and that you
> create new PMC members and committers as they contribute things.
>

In principle I agree, but when you have six or seven or more parts of the
tree whose committers' expertise does not overlap, I think it really does
make sense for these to be organized as separate projects.

Furthermore, it sounds like you are saying for Java and Python
> these weren’t “fly by” contributions and more work has gone on
> in those drivers than e.g., compared to Clojure, C++, etc.
>

That was the case five years ago, and would probably still be the case if
we had kept drivers in tree.  Making them their own projects has resulted
in more and higher quality drivers overall.

I note that among similar Apache projects,

- CouchDB drivers are not maintained in-tree

- HBase maintains only a Java driver in-tree
- Accumulo maintains only a Java driver in-tree

Put another way, I see four projects that have all more or less
independently concluded that trying to maintain a lot of drivers as part of
a single Apache project is not a good way to organize things.

-- 
Jonathan Ellis
Project Chair, Apache Cassandra
co-founder, http://www.datastax.com
@spyced

Re: Cassandra Java Driver and DataStax

[Chris Mattmann]

Thanks Jonathan. I’m starting to get a clearer idea of what’s
going on here. Do you think it was a walled garden in terms of
making reviews for incoming driver patches when you did have 
them in the tree? What you are talking about in the first paragraph
is precisely the reason that your community expands and that you 
create new PMC members and committers as they contribute things.
You inevitably as a community will run into that situation and
in those cases it’s time to make the new people PMC members and
committers especially if you didn’t have the expertise in the
code they are contributing to start with.

Furthermore, it sounds like you are saying for Java and Python
these weren’t “fly by” contributions and more work has gone on
in those drivers than e.g., compared to Clojure, C++, etc.

Thoughts?

Cheers,
Chris




On 6/4/16, 5:38 AM, "Jonathan Ellis"  wrote:

>FWIW, in very very ancient history we actually had the drivers in tree.  It
>sucked, because the people who wanted to contribute to the drivers were for
>the most part not Committers, and the committers for the most part weren't
>interested in reviewing drivers patches, and you have different,
>non-overlapping sets of contributors for each driver.  (A C++ driver author
>generally isn't very interested in clojure and vice versa.)
>
>Two things really convinced us they didn't belong in tree, even if we
>wanted to live with the above drawbacks:
>
>- If it's in tree, then the Apache committers are viewed as responsible for
>maintaining it.  Never mind if the Perl driver was (hypothetically)
>contributed by some guy who disappeared after a month and none of the
>committers know Perl, we have by committing it implicitly promised to fix
>bugs and keep it up to date with new features.
>- The obvious solution to this problem is to just not commit any driver
>that we don't have enough expertise to maintain ourselves or are not
>sufficiently confident in the author's commitment.  But then you have a
>very clear distinction between "first class," in tree drivers (probably
>just Java, maybe Python too) and everyone else, which didn't sit right with
>us either.
>
>On Fri, Jun 3, 2016 at 10:47 PM, J. D. Jordan 
>wrote:
>
>> This is the way our community has operated for at least the 6ish years I
>> have been involved with it. The Apache project develops the database,
>> others in the community develop drivers. It's the way we have always
>> worked, I'm sorry if you don't like that.
>>
>
>-- 
>Jonathan Ellis
>Project Chair, Apache Cassandra
>co-founder, http://www.datastax.com
>@spyced

Re: Cassandra Java Driver and DataStax

[Jonathan Ellis]

FWIW, in very very ancient history we actually had the drivers in tree.  It
sucked, because the people who wanted to contribute to the drivers were for
the most part not Committers, and the committers for the most part weren't
interested in reviewing drivers patches, and you have different,
non-overlapping sets of contributors for each driver.  (A C++ driver author
generally isn't very interested in clojure and vice versa.)

Two things really convinced us they didn't belong in tree, even if we
wanted to live with the above drawbacks:

- If it's in tree, then the Apache committers are viewed as responsible for
maintaining it.  Never mind if the Perl driver was (hypothetically)
contributed by some guy who disappeared after a month and none of the
committers know Perl, we have by committing it implicitly promised to fix
bugs and keep it up to date with new features.
- The obvious solution to this problem is to just not commit any driver
that we don't have enough expertise to maintain ourselves or are not
sufficiently confident in the author's commitment.  But then you have a
very clear distinction between "first class," in tree drivers (probably
just Java, maybe Python too) and everyone else, which didn't sit right with
us either.

On Fri, Jun 3, 2016 at 10:47 PM, J. D. Jordan 
wrote:

> This is the way our community has operated for at least the 6ish years I
> have been involved with it. The Apache project develops the database,
> others in the community develop drivers. It's the way we have always
> worked, I'm sorry if you don't like that.
>

-- 
Jonathan Ellis
Project Chair, Apache Cassandra
co-founder, http://www.datastax.com
@spyced

Re: Cassandra Java Driver and DataStax

[Mattmann, Chris A (3980)]

Thanks Jason for the information - I’m going to continue 
researching and hope more people will chime in that are on
the PMC.

Thank you.

Cheers,
Chris

++
Chris Mattmann, Ph.D.
Chief Architect
Instrument Software and Science Data Systems Section (398)
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 168-519, Mailstop: 168-527
Email: chris.a.mattm...@nasa.gov
WWW:  http://sunset.usc.edu/~mattmann/
++
Director, Information Retrieval and Data Science Group (IRDS)
Adjunct Associate Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
WWW: http://irds.usc.edu/
++









On 6/3/16, 8:33 PM, "Jason Brown"  wrote:

>
>
>
>The client-server protocol is well defined in the Cassandra repo, so any one 
>may implement a client library for any language. However, it is a far from 
>trivial task, so not many folks build their own. Thus, already-built drivers 
>tend to become the de facto
> standard, but we (the Apache Cassandra committers/PMC) do not/have not 
> blessed any vendor's driver(s) as official.
>
>
>As to why there is not a canonical set of drivers in the Cassandra repo, well, 
>we've just never gotten into that game as an OSS community.
>
>
>-Jason (not affiliated with DataStax)
>
>On Friday, June 3, 2016, Johan Edstrom  wrote:
>
>
>
>On Jun 3, 2016, at 9:14 PM, Jeff Jirsa > wrote:
>
>
>https://github.com/hector-client/hector
>
>
>
>
>
>
>So - that isn’t doing CQL, Right?
>
>
>https://github.com/Netflix/astyanax
>
>
>
>
>
>
>Upgrading to CQL?
>
>
>
>http://doanduyhai.github.io/Achilles/
>
>
>
>
>
>
>
>Which driver do you use?
>
>
>https://github.com/noorq/casser
>
>
>
>
>
>
>2.1.5
>
>
>
>
>
>https://github.com/impetus-opensource/Kundera
>
>
>
>
>
>
>
>ds-driver
>
>false
>
>
>cassandra-core
>cassandra-ds-driver
>
>
>
>thrift
>
>false
>
>
>cassandra-core
>cassandra-thrift
>
>
>
>
>
>
>
>
>
>
>
>
>https://github.com/deanhiller/playorm
>
>
>
>
>
>
>
>
>
>
>
>
>- Jeff ( Not affiliated with datastax )
>
>
>
>
>
>On 6/3/16, 7:58 PM, "Johan Edstrom" > wrote:
>
>
>How many Java drivers could you point out?
>Doesn’t it strike you slightly off that you’d not have a driver for a DB 
>in the same project you found the DB?
>
>
>
>On Jun 3, 2016, at 8:51 PM, Dave Brosius > wrote:
>
>There are many drivers for cassandra, supplied by various individuals and 
>groups, one of those drivers was started by people at datastax which is 
>available as an opensource project.
>
>The open source project is not open to any random person on the internet to 
>commit to (just like any open source project), so i suppose in that regard 
>there is some 'control'. But i doubt that is what you are fishing for.
>
>--dave
>
>(not affiliated with datastax)
>
>On 06/03/2016 10:29 PM, Chris Mattmann wrote:
>Hi All,
>
>I’m investigating something a few ASF members contacted
>me about and pointed out, so I’m hoping you can help
>guide me here as a community. I have heard that a company,
>DataStax, whose marketing material mentions it as the only
>Cassandra vendor, “controls” the Java Driver for Apache
>Cassandra.
>
>Of course, no company “controls” our projects or its code,
>so I told the folks that mentioned it to me that I’d investigate
>with my board hat on.
>
>I’d like to hear the community’s thoughts here on this. Does
>anyone in the community see this “controlling” behavior going
>on? Please speak up, as I’d like to get to the bottom of it,
>and I’ll be around on the lists, doing some homework and reading
>up on the archives to see what’s up.
>
>Thanks for any help you can provide in rooting this out.
>
>Cheers,
>Chris
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>

Re: Cassandra Java Driver and DataStax

[J. D. Jordan]

This is the way our community has operated for at least the 6ish years I have 
been involved with it. The Apache project develops the database, others in the 
community develop drivers. It's the way we have always worked, I'm sorry if you 
don't like that. 

DataStax has released their driver under a license that gives you free reign to 
fork it and do with it what you please if you don't like what they are doing 
with it.  https://github.com/datastax/java-driver/blob/3.0/LICENSE

This conversation clearly isn't going anywhere so I will be bowing out of it 
now.

> On Jun 3, 2016, at 10:37 PM, Johan Edstrom  wrote:
> 
> 
> As an Apache guy, one to another, seriously, how would you respond to that?
> 
> 
> 
> 
> 
>> On Jun 3, 2016, at 9:33 PM, Jason Brown  wrote:
>> 
>> The client-server protocol is well defined in the Cassandra repo, so any one 
>> may implement a client library for any language. However, it is a far from 
>> trivial task, so not many folks build their own. Thus, already-built drivers 
>> tend to become the de facto standard, but we (the Apache Cassandra 
>> committers/PMC) do not/have not blessed any vendor's driver(s) as official.
>> 
>> As to why there is not a canonical set of drivers in the Cassandra repo, 
>> well, we've just never gotten into that game as an OSS community.
>> 
>> -Jason (not affiliated with DataStax)
>> 
>>> On Friday, June 3, 2016, Johan Edstrom >> > wrote:
>>> 
>>> On Jun 3, 2016, at 9:14 PM, Jeff Jirsa >> > wrote:
>>> 
>>> 
>>> https://github.com/hector-client/hector 
>>> 
>> 
>> So - that isn’t doing CQL, Right?
>>> 
>>> https://github.com/Netflix/astyanax 
>> 
>> Upgrading to CQL?
>> 
>>> 
>>> http://doanduyhai.github.io/Achilles/ 
>>> 
>> 
>> Which driver do you use?
>> 
>>> https://github.com/noorq/casser 
>> 
>> 2.1.5
>> 
>> 
>>> 
>>> https://github.com/impetus-opensource/Kundera 
>>> 
>> 
>> 
>>  ds-driver
>>  
>>false
>>  
>>  
>>cassandra-core
>>cassandra-ds-driver
>>  
>>
>>
>>  thrift
>>  
>>false
>>  
>>  
>>cassandra-core
>>cassandra-thrift
>>  
>>
>> 
>> 
>> 
>> 
>> 
>>> 
>>> https://github.com/deanhiller/playorm 
>>> 
>> 
>> 
>> 
>>> 
>>> 
>>> 
>>> - Jeff ( Not affiliated with datastax )
>>> 
>>> 
>>> 
>>> 
>>> 
 On 6/3/16, 7:58 PM, "Johan Edstrom" > wrote:
 
 How many Java drivers could you point out?
 Doesn’t it strike you slightly off that you’d not have a driver for a DB 
 in the same project you found the DB?
 
 
 
> On Jun 3, 2016, at 8:51 PM, Dave Brosius  > wrote:
> 
> There are many drivers for cassandra, supplied by various individuals and 
> groups, one of those drivers was started by people at datastax which is 
> available as an opensource project.
> 
> The open source project is not open to any random person on the internet 
> to commit to (just like any open source project), so i suppose in that 
> regard there is some 'control'. But i doubt that is what you are fishing 
> for.
> 
> --dave
> 
> (not affiliated with datastax)
> 
>> On 06/03/2016 10:29 PM, Chris Mattmann wrote:
>> Hi All,
>> 
>> I’m investigating something a few ASF members contacted
>> me about and pointed out, so I’m hoping you can help
>> guide me here as a community. I have heard that a company,
>> DataStax, whose marketing material mentions it as the only
>> Cassandra vendor, “controls” the Java Driver for Apache
>> Cassandra.
>> 
>> Of course, no company “controls” our projects or its code,
>> so I told the folks that mentioned it to me that I’d investigate
>> with my board hat on.
>> 
>> I’d like to hear the community’s thoughts here on this. Does
>> anyone in the community see this “controlling” behavior going
>> on? Please speak up, as I’d like to get to the bottom of it,
>> and I’ll be around on the lists, doing some homework and reading
>> up on the archives to see what’s up.
>> 
>> Thanks for any help you can provide in rooting this out.
>> 
>> Cheers,
>> Chris
> 

Re: Cassandra Java Driver and DataStax

[Johan Edstrom]

As an Apache guy, one to another, seriously, how would you respond to that?





> On Jun 3, 2016, at 9:33 PM, Jason Brown  wrote:
> 
> The client-server protocol is well defined in the Cassandra repo, so any one 
> may implement a client library for any language. However, it is a far from 
> trivial task, so not many folks build their own. Thus, already-built drivers 
> tend to become the de facto standard, but we (the Apache Cassandra 
> committers/PMC) do not/have not blessed any vendor's driver(s) as official.
> 
> As to why there is not a canonical set of drivers in the Cassandra repo, 
> well, we've just never gotten into that game as an OSS community.
> 
> -Jason (not affiliated with DataStax)
> 
> On Friday, June 3, 2016, Johan Edstrom  > wrote:
> 
>> On Jun 3, 2016, at 9:14 PM, Jeff Jirsa > > wrote:
>> 
>> 
>> https://github.com/hector-client/hector 
>>  
> 
> So - that isn’t doing CQL, Right?
>> 
>> https://github.com/Netflix/astyanax 
> 
> Upgrading to CQL?
> 
>> 
>> http://doanduyhai.github.io/Achilles/ 
>> 
> 
> Which driver do you use?
> 
>> https://github.com/noorq/casser 
> 
> 2.1.5
> 
> 
>> 
>> https://github.com/impetus-opensource/Kundera 
>> 
> 
>  
>   ds-driver
>   
> false
>   
>   
> cassandra-core
> cassandra-ds-driver
>   
> 
> 
>   thrift
>   
> false
>   
>   
> cassandra-core
> cassandra-thrift
>   
> 
> 
> 
> 
> 
> 
>> 
>> https://github.com/deanhiller/playorm 
> 
> 
> 
>> 
>> 
>> 
>> - Jeff ( Not affiliated with datastax )
>> 
>> 
>> 
>> 
>> 
>> On 6/3/16, 7:58 PM, "Johan Edstrom" > > wrote:
>> 
>>> How many Java drivers could you point out?
>>> Doesn’t it strike you slightly off that you’d not have a driver for a DB 
>>> in the same project you found the DB?
>>> 
>>> 
>>> 
 On Jun 3, 2016, at 8:51 PM, Dave Brosius > wrote:
 
 There are many drivers for cassandra, supplied by various individuals and 
 groups, one of those drivers was started by people at datastax which is 
 available as an opensource project.
 
 The open source project is not open to any random person on the internet 
 to commit to (just like any open source project), so i suppose in that 
 regard there is some 'control'. But i doubt that is what you are fishing 
 for.
 
 --dave
 
 (not affiliated with datastax)
 
 On 06/03/2016 10:29 PM, Chris Mattmann wrote:
> Hi All,
> 
> I’m investigating something a few ASF members contacted
> me about and pointed out, so I’m hoping you can help
> guide me here as a community. I have heard that a company,
> DataStax, whose marketing material mentions it as the only
> Cassandra vendor, “controls” the Java Driver for Apache
> Cassandra.
> 
> Of course, no company “controls” our projects or its code,
> so I told the folks that mentioned it to me that I’d investigate
> with my board hat on.
> 
> I’d like to hear the community’s thoughts here on this. Does
> anyone in the community see this “controlling” behavior going
> on? Please speak up, as I’d like to get to the bottom of it,
> and I’ll be around on the lists, doing some homework and reading
> up on the archives to see what’s up.
> 
> Thanks for any help you can provide in rooting this out.
> 
> Cheers,
> Chris
> 
> 
> 
> 
> 
 
> 

Re: Cassandra Java Driver and DataStax

[Jason Brown]

The client-server protocol is well defined in the Cassandra repo, so any
one may implement a client library for any language. However, it is a far
from trivial task, so not many folks build their own. Thus, already-built
drivers tend to become the de facto standard, but we (the Apache Cassandra
committers/PMC) do not/have not blessed any vendor's driver(s) as official.

As to why there is not a canonical set of drivers in the Cassandra repo,
well, we've just never gotten into that game as an OSS community.

-Jason (not affiliated with DataStax)

On Friday, June 3, 2016, Johan Edstrom  wrote:

>
> On Jun 3, 2016, at 9:14 PM, Jeff Jirsa  > wrote:
>
>
> https://github.com/hector-client/hector
>
>
> So - that isn’t doing CQL, Right?
>
>
> https://github.com/Netflix/astyanax
>
>
> Upgrading to CQL?
>
>
> http://doanduyhai.github.io/Achilles/
>
>
> Which driver do you use?
>
> https://github.com/noorq/casser
>
>
> 2.1.5
>
>
>
> https://github.com/impetus-opensource/Kundera
>
>
> 
> ds-driver
> 
> false
> 
> 
> cassandra-core
> cassandra-ds-driver
> 
> 
> 
> thrift
> 
> false
> 
> 
> cassandra-core
> cassandra-thrift
> 
> 
>
>
>
>
>
>
> https://github.com/deanhiller/playorm
>
>
>
>
>
>
> - Jeff ( Not affiliated with datastax )
>
>
>
>
>
> On 6/3/16, 7:58 PM, "Johan Edstrom"  > wrote:
>
> How many Java drivers could you point out?
> Doesn’t it strike you slightly off that you’d not have a driver for a DB
> in the same project you found the DB?
>
>
>
> On Jun 3, 2016, at 8:51 PM, Dave Brosius  > wrote:
>
> There are many drivers for cassandra, supplied by various individuals and
> groups, one of those drivers was started by people at datastax which is
> available as an opensource project.
>
> The open source project is not open to any random person on the internet
> to commit to (just like any open source project), so i suppose in that
> regard there is some 'control'. But i doubt that is what you are fishing
> for.
>
> --dave
>
> (not affiliated with datastax)
>
> On 06/03/2016 10:29 PM, Chris Mattmann wrote:
>
> Hi All,
>
> I’m investigating something a few ASF members contacted
> me about and pointed out, so I’m hoping you can help
> guide me here as a community. I have heard that a company,
> DataStax, whose marketing material mentions it as the only
> Cassandra vendor, “controls” the Java Driver for Apache
> Cassandra.
>
> Of course, no company “controls” our projects or its code,
> so I told the folks that mentioned it to me that I’d investigate
> with my board hat on.
>
> I’d like to hear the community’s thoughts here on this. Does
> anyone in the community see this “controlling” behavior going
> on? Please speak up, as I’d like to get to the bottom of it,
> and I’ll be around on the lists, doing some homework and reading
> up on the archives to see what’s up.
>
> Thanks for any help you can provide in rooting this out.
>
> Cheers,
> Chris
>
>
>
>
>
>
>
>

Re: Cassandra Java Driver and DataStax

[Johan Edstrom]

You can find a very small list containing Hector and the DataStax driver.
Hector was made obsolete by quite a few architecture changes (That I don’t 
disagree with)

Claiming you have a large list of drivers is just dishonest.





> On Jun 3, 2016, at 9:16 PM, J. D. Jordan  wrote:
> 
> The Apache Cassandra project has always left development of its drivers up to 
> the community.  The DataStax Java Driver is not part of the Apache Cassandra 
> project, it is an open source project created by DataStax.  You can find a 
> large list of drivers for Cassandra here: 
> https://wiki.apache.org/cassandra/ClientOptions some of them developed by 
> DataStax, many are developed by others in the community.
> 
>> On Jun 3, 2016, at 9:51 PM, Dave Brosius  wrote:
>> 
>> There are many drivers for cassandra, supplied by various individuals and 
>> groups, one of those drivers was started by people at datastax which is 
>> available as an opensource project.
>> 
>> The open source project is not open to any random person on the internet to 
>> commit to (just like any open source project), so i suppose in that regard 
>> there is some 'control'. But i doubt that is what you are fishing for.
>> 
>> --dave
>> 
>> (not affiliated with datastax)
>> 
>>> On 06/03/2016 10:29 PM, Chris Mattmann wrote:
>>> Hi All,
>>> 
>>> I’m investigating something a few ASF members contacted
>>> me about and pointed out, so I’m hoping you can help
>>> guide me here as a community. I have heard that a company,
>>> DataStax, whose marketing material mentions it as the only
>>> Cassandra vendor, “controls” the Java Driver for Apache
>>> Cassandra.
>>> 
>>> Of course, no company “controls” our projects or its code,
>>> so I told the folks that mentioned it to me that I’d investigate
>>> with my board hat on.
>>> 
>>> I’d like to hear the community’s thoughts here on this. Does
>>> anyone in the community see this “controlling” behavior going
>>> on? Please speak up, as I’d like to get to the bottom of it,
>>> and I’ll be around on the lists, doing some homework and reading
>>> up on the archives to see what’s up.
>>> 
>>> Thanks for any help you can provide in rooting this out.
>>> 
>>> Cheers,
>>> Chris
>> 

Re: Cassandra Java Driver and DataStax

[Johan Edstrom]

> On Jun 3, 2016, at 9:14 PM, Jeff Jirsa  wrote:
> 
> 
> https://github.com/hector-client/hector 

So - that isn’t doing CQL, Right?
> 
> https://github.com/Netflix/astyanax

Upgrading to CQL?

> 
> http://doanduyhai.github.io/Achilles/
> 

Which driver do you use?

> https://github.com/noorq/casser

2.1.5


> 
> https://github.com/impetus-opensource/Kundera

 
  ds-driver
  
false
  
  
cassandra-core
cassandra-ds-driver
  


  thrift
  
false
  
  
cassandra-core
cassandra-thrift
  






> 
> https://github.com/deanhiller/playorm



> 
> 
> 
> - Jeff ( Not affiliated with datastax )
> 
> 
> 
> 
> 
> On 6/3/16, 7:58 PM, "Johan Edstrom"  wrote:
> 
>> How many Java drivers could you point out?
>> Doesn’t it strike you slightly off that you’d not have a driver for a DB 
>> in the same project you found the DB?
>> 
>> 
>> 
>>> On Jun 3, 2016, at 8:51 PM, Dave Brosius  wrote:
>>> 
>>> There are many drivers for cassandra, supplied by various individuals and 
>>> groups, one of those drivers was started by people at datastax which is 
>>> available as an opensource project.
>>> 
>>> The open source project is not open to any random person on the internet to 
>>> commit to (just like any open source project), so i suppose in that regard 
>>> there is some 'control'. But i doubt that is what you are fishing for.
>>> 
>>> --dave
>>> 
>>> (not affiliated with datastax)
>>> 
>>> On 06/03/2016 10:29 PM, Chris Mattmann wrote:
 Hi All,
 
 I’m investigating something a few ASF members contacted
 me about and pointed out, so I’m hoping you can help
 guide me here as a community. I have heard that a company,
 DataStax, whose marketing material mentions it as the only
 Cassandra vendor, “controls” the Java Driver for Apache
 Cassandra.
 
 Of course, no company “controls” our projects or its code,
 so I told the folks that mentioned it to me that I’d investigate
 with my board hat on.
 
 I’d like to hear the community’s thoughts here on this. Does
 anyone in the community see this “controlling” behavior going
 on? Please speak up, as I’d like to get to the bottom of it,
 and I’ll be around on the lists, doing some homework and reading
 up on the archives to see what’s up.
 
 Thanks for any help you can provide in rooting this out.
 
 Cheers,
 Chris
 
 
 
 
 
>>> 

Re: Cassandra Java Driver and DataStax

[J. D. Jordan]

The Apache Cassandra project has always left development of its drivers up to 
the community.  The DataStax Java Driver is not part of the Apache Cassandra 
project, it is an open source project created by DataStax.  You can find a 
large list of drivers for Cassandra here: 
https://wiki.apache.org/cassandra/ClientOptions some of them developed by 
DataStax, many are developed by others in the community.

> On Jun 3, 2016, at 9:51 PM, Dave Brosius  wrote:
> 
> There are many drivers for cassandra, supplied by various individuals and 
> groups, one of those drivers was started by people at datastax which is 
> available as an opensource project.
> 
> The open source project is not open to any random person on the internet to 
> commit to (just like any open source project), so i suppose in that regard 
> there is some 'control'. But i doubt that is what you are fishing for.
> 
> --dave
> 
> (not affiliated with datastax)
> 
>> On 06/03/2016 10:29 PM, Chris Mattmann wrote:
>> Hi All,
>> 
>> I’m investigating something a few ASF members contacted
>> me about and pointed out, so I’m hoping you can help
>> guide me here as a community. I have heard that a company,
>> DataStax, whose marketing material mentions it as the only
>> Cassandra vendor, “controls” the Java Driver for Apache
>> Cassandra.
>> 
>> Of course, no company “controls” our projects or its code,
>> so I told the folks that mentioned it to me that I’d investigate
>> with my board hat on.
>> 
>> I’d like to hear the community’s thoughts here on this. Does
>> anyone in the community see this “controlling” behavior going
>> on? Please speak up, as I’d like to get to the bottom of it,
>> and I’ll be around on the lists, doing some homework and reading
>> up on the archives to see what’s up.
>> 
>> Thanks for any help you can provide in rooting this out.
>> 
>> Cheers,
>> Chris
> 

Re: Cassandra Java Driver and DataStax

[Jeff Jirsa]

https://github.com/hector-client/hector 

https://github.com/Netflix/astyanax

http://doanduyhai.github.io/Achilles/

https://github.com/noorq/casser

https://github.com/impetus-opensource/Kundera

https://github.com/deanhiller/playorm



- Jeff ( Not affiliated with datastax )





On 6/3/16, 7:58 PM, "Johan Edstrom"  wrote:

>How many Java drivers could you point out?
>Doesn’t it strike you slightly off that you’d not have a driver for a DB 
>in the same project you found the DB?
>
>
>
>> On Jun 3, 2016, at 8:51 PM, Dave Brosius  wrote:
>> 
>> There are many drivers for cassandra, supplied by various individuals and 
>> groups, one of those drivers was started by people at datastax which is 
>> available as an opensource project.
>> 
>> The open source project is not open to any random person on the internet to 
>> commit to (just like any open source project), so i suppose in that regard 
>> there is some 'control'. But i doubt that is what you are fishing for.
>> 
>> --dave
>> 
>> (not affiliated with datastax)
>> 
>> On 06/03/2016 10:29 PM, Chris Mattmann wrote:
>>> Hi All,
>>> 
>>> I’m investigating something a few ASF members contacted
>>> me about and pointed out, so I’m hoping you can help
>>> guide me here as a community. I have heard that a company,
>>> DataStax, whose marketing material mentions it as the only
>>> Cassandra vendor, “controls” the Java Driver for Apache
>>> Cassandra.
>>> 
>>> Of course, no company “controls” our projects or its code,
>>> so I told the folks that mentioned it to me that I’d investigate
>>> with my board hat on.
>>> 
>>> I’d like to hear the community’s thoughts here on this. Does
>>> anyone in the community see this “controlling” behavior going
>>> on? Please speak up, as I’d like to get to the bottom of it,
>>> and I’ll be around on the lists, doing some homework and reading
>>> up on the archives to see what’s up.
>>> 
>>> Thanks for any help you can provide in rooting this out.
>>> 
>>> Cheers,
>>> Chris
>>> 
>>> 
>>> 
>>> 
>>> 
>> 
>

smime.p7s
Description: S/MIME cryptographic signature

Re: Cassandra Java Driver and DataStax

[Johan Edstrom]

Fame and fortune awaits me?
What does that mean?



> On Jun 3, 2016, at 9:10 PM, Dave Brosius  wrote:
> 
> Here are just some of the drivers.
> 
> https://wiki.apache.org/cassandra/ClientOptions
> 
> There's tons more for the older thrift interface
> 
> https://wiki.apache.org/cassandra/ClientOptionsThrift
> 
> Being as the new interface is, well, newer, there are less options.
> If you'd like to write your own and build a better one, fame and fortune 
> awaits you.
> 
> --dave
> 
> On 06/03/2016 10:58 PM, Johan Edstrom wrote:
>> How many Java drivers could you point out?
>> Doesn’t it strike you slightly off that you’d not have a driver for a DB
>> in the same project you found the DB?
>> 
>> 
>> 
>>> On Jun 3, 2016, at 8:51 PM, Dave Brosius  wrote:
>>> 
>>> There are many drivers for cassandra, supplied by various individuals and 
>>> groups, one of those drivers was started by people at datastax which is 
>>> available as an opensource project.
>>> 
>>> The open source project is not open to any random person on the internet to 
>>> commit to (just like any open source project), so i suppose in that regard 
>>> there is some 'control'. But i doubt that is what you are fishing for.
>>> 
>>> --dave
>>> 
>>> (not affiliated with datastax)
>>> 
>>> On 06/03/2016 10:29 PM, Chris Mattmann wrote:
 Hi All,
 
 I’m investigating something a few ASF members contacted
 me about and pointed out, so I’m hoping you can help
 guide me here as a community. I have heard that a company,
 DataStax, whose marketing material mentions it as the only
 Cassandra vendor, “controls” the Java Driver for Apache
 Cassandra.
 
 Of course, no company “controls” our projects or its code,
 so I told the folks that mentioned it to me that I’d investigate
 with my board hat on.
 
 I’d like to hear the community’s thoughts here on this. Does
 anyone in the community see this “controlling” behavior going
 on? Please speak up, as I’d like to get to the bottom of it,
 and I’ll be around on the lists, doing some homework and reading
 up on the archives to see what’s up.
 
 Thanks for any help you can provide in rooting this out.
 
 Cheers,
 Chris
 
 
 
 
 
>> 
> 

Re: Cassandra Java Driver and DataStax

[Dave Brosius]

Here are just some of the drivers.

https://wiki.apache.org/cassandra/ClientOptions

There's tons more for the older thrift interface

https://wiki.apache.org/cassandra/ClientOptionsThrift

Being as the new interface is, well, newer, there are less options.
If you'd like to write your own and build a better one, fame and fortune 
awaits you.


--dave

On 06/03/2016 10:58 PM, Johan Edstrom wrote:

How many Java drivers could you point out?
Doesn’t it strike you slightly off that you’d not have a driver for a DB
in the same project you found the DB?




On Jun 3, 2016, at 8:51 PM, Dave Brosius  wrote:

There are many drivers for cassandra, supplied by various individuals and 
groups, one of those drivers was started by people at datastax which is 
available as an opensource project.

The open source project is not open to any random person on the internet to 
commit to (just like any open source project), so i suppose in that regard 
there is some 'control'. But i doubt that is what you are fishing for.

--dave

(not affiliated with datastax)

On 06/03/2016 10:29 PM, Chris Mattmann wrote:

Hi All,

I’m investigating something a few ASF members contacted
me about and pointed out, so I’m hoping you can help
guide me here as a community. I have heard that a company,
DataStax, whose marketing material mentions it as the only
Cassandra vendor, “controls” the Java Driver for Apache
Cassandra.

Of course, no company “controls” our projects or its code,
so I told the folks that mentioned it to me that I’d investigate
with my board hat on.

I’d like to hear the community’s thoughts here on this. Does
anyone in the community see this “controlling” behavior going
on? Please speak up, as I’d like to get to the bottom of it,
and I’ll be around on the lists, doing some homework and reading
up on the archives to see what’s up.

Thanks for any help you can provide in rooting this out.

Cheers,
Chris

Re: Cassandra Java Driver and DataStax

[Johan Edstrom]

How many Java drivers could you point out?
Doesn’t it strike you slightly off that you’d not have a driver for a DB 
in the same project you found the DB?



> On Jun 3, 2016, at 8:51 PM, Dave Brosius  wrote:
> 
> There are many drivers for cassandra, supplied by various individuals and 
> groups, one of those drivers was started by people at datastax which is 
> available as an opensource project.
> 
> The open source project is not open to any random person on the internet to 
> commit to (just like any open source project), so i suppose in that regard 
> there is some 'control'. But i doubt that is what you are fishing for.
> 
> --dave
> 
> (not affiliated with datastax)
> 
> On 06/03/2016 10:29 PM, Chris Mattmann wrote:
>> Hi All,
>> 
>> I’m investigating something a few ASF members contacted
>> me about and pointed out, so I’m hoping you can help
>> guide me here as a community. I have heard that a company,
>> DataStax, whose marketing material mentions it as the only
>> Cassandra vendor, “controls” the Java Driver for Apache
>> Cassandra.
>> 
>> Of course, no company “controls” our projects or its code,
>> so I told the folks that mentioned it to me that I’d investigate
>> with my board hat on.
>> 
>> I’d like to hear the community’s thoughts here on this. Does
>> anyone in the community see this “controlling” behavior going
>> on? Please speak up, as I’d like to get to the bottom of it,
>> and I’ll be around on the lists, doing some homework and reading
>> up on the archives to see what’s up.
>> 
>> Thanks for any help you can provide in rooting this out.
>> 
>> Cheers,
>> Chris
>> 
>> 
>> 
>> 
>> 
> 

Re: Cassandra Java Driver and DataStax

[Dave Brosius]

There are many drivers for cassandra, supplied by various individuals 
and groups, one of those drivers was started by people at datastax which 
is available as an opensource project.


The open source project is not open to any random person on the internet 
to commit to (just like any open source project), so i suppose in that 
regard there is some 'control'. But i doubt that is what you are fishing 
for.


--dave

(not affiliated with datastax)

On 06/03/2016 10:29 PM, Chris Mattmann wrote:

Hi All,

I’m investigating something a few ASF members contacted
me about and pointed out, so I’m hoping you can help
guide me here as a community. I have heard that a company,
DataStax, whose marketing material mentions it as the only
Cassandra vendor, “controls” the Java Driver for Apache
Cassandra.

Of course, no company “controls” our projects or its code,
so I told the folks that mentioned it to me that I’d investigate
with my board hat on.

I’d like to hear the community’s thoughts here on this. Does
anyone in the community see this “controlling” behavior going
on? Please speak up, as I’d like to get to the bottom of it,
and I’ll be around on the lists, doing some homework and reading
up on the archives to see what’s up.

Thanks for any help you can provide in rooting this out.

Cheers,
Chris