incubator-cassandra-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jonathan Ellis <jbel...@gmail.com>
Subject Re: Reducing confusion around client libraries
Date Fri, 03 Dec 2010 20:05:40 GMT
On Fri, Dec 3, 2010 at 1:46 PM, Gary Dusbabek <gdusbabek@gmail.com> wrote:
> We develop the cassandra database.  I believe it is currently beyond
> the scope of this project to advocate for and against third party
> client libraries.

Wait, if we're not qualified to say "this is the best PHP client," who is?

We are doing our users a massive disservice by saying "everybody
figure it out for themselves."  It's very fair -- the experience is
terrible for everyone -- but that's not the right kind of fairness.

>  If it isn't, then we should be actively developing
> client libraries.

As I said, I would rather keep things loosely coupled, but if that is
what it takes to satisfy our OCD then I would prefer that to what we
have now.

> That this is a reactive solution (to client library proliferation)
> makes me think there is an underlying problem that ought to be fixed.
> The charge has been leveled more than once that the cassandra API is a
> bear to work with.  After denying it at first, I am now inclined to
> agree.  Why don't we work instead to improve that?

It's (1) not possible and (2) the wrong solution and (3) the wrong time frame.

To elaborate:

1) We've already tried Avro over Thrift and it's basically six of one,
half a dozen of the other.  Avro/Thrift is as high-level as you're
going to get and still retaining cross-language compatibility.  The
right way to think of these is as "easier to wrap than a C driver"
which is what everyone else does.  (libpq would be a nightmare to
program directly from Python but nobody does that because it's
obviously stupid.  Thrift's problem is that it's sort of usable
directly, but that's not how you should do it.)

2) The gold standard is SQL, but even with SQL databases people build
higher-level APIs, e.g. JPA on top of JDBC, SQLAlchemy on top of the
Python DBAPI, ActiveRecord on top of whatever it is in Ruby.  You're
always going to need a native, idiomatic library.

3) Even if I'm wrong about (1) and (2) we need to fix this for 0.7 and
the earliest we could have a new Perfect API with Double Ponies is the
next major release.

-- 
Jonathan Ellis
Project Chair, Apache Cassandra
co-founder of Riptano, the source for professional Cassandra support
http://riptano.com

Mime
View raw message