incubator-cassandra-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ran Tavory <>
Subject Re: Reducing confusion around client libraries
Date Fri, 03 Dec 2010 21:07:02 GMT
As developer of one of the client libraries I can say that competition keeps
us the library maintainers healthy and in the long run creates more value to
the users so we should keep competition fair.
I can certainly see Jonathan's point regarding the level of confusion b/w
newcomers and I'm all for reducing it, but only as long as there's a fair
chance for all clients to evolve.
To the points that the server can provide a better interface (avro or CQL
and what have you), I think this can improve overall client development but
will not eliminate the need for clients, there will always be a higher level
and nicer interface a client can provide or plugins to 3rd party (spring and
such) so it does not solve the confusion problem, there will always be more
clients as long as cassandra keeps evolving.

I like transparency and I think that if you present users enough data they
will be able to decide mind, even new comers. It would be correct to say
that generally folks who'd been involved with cassandra for a few years are
better informed than newcomers however it is sometimes hard to make an
objective decision and it's also hard to make a one-size-fits-all decision,
for example some clients implement feature x and not y and for most users it
makes a lot of sense only that for some users they need y and not x. We need
to be transparent and list the features and tradeoffs and let the users
I like Paul's idea of a table with a list of libraries and for each library
a set of columns such as [maintainer, last release, next release, support
forum, number of committers, number of users, spring support, jpa support
etc]. There's a challenge of keeping this table up to date but on the other
hand if a library maintainer does not keep his row up to date then it's a
signal. If voting can be made easily then I'm all for it as well as part of
this table. I don't think the table would be huge, it's probably 2-3 per

On Fri, Dec 3, 2010 at 10:25 PM, Paul Brown <> wrote:

> On Dec 3, 2010, at 12:13 PM, Eric Evans wrote:
> > On Fri, 2010-12-03 at 13:46 -0600, Tyler Hobbs wrote:
> >> Personally, I like the Mongo drivers page:
> >>
> >>
> >> I like the clear distinction between preferred and alternative clients
> >> without a lot of clutter about release dates and supported versions.
> >> How do we make that distinction, though?  A "supported by Riptano"
> >> section is one option, but that doesn't even encompass all of the
> >> preferred clients.
> > This sounds like you're suggesting that we place an "official according
> > to Riptano" section on the project wiki.  That sounds... worse.
> The PMC can sort it out, but I don't think it's within the purview/charter
> of the project to bless third-party libraries.  For libraries/content that
> are shipped with officially Apache artifacts, there are clear and specific
> standards in terms of licenses, intellectual property, etc., and endorsing
> (versus simply listing) third-party components on a project site is probably
> inappropriate.  (IMHO.)  What happens on a third party's site is another
> matter.
> -- Paul


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message