You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cassandra.apache.org by Jonathan Ellis <jb...@gmail.com> on 2010/12/03 18:43:45 UTC
Reducing confusion around client libraries
The status quo is not working. There are way too many questions on
the user list and on irc about problems with writing Thrift code, even
when well-maintained clients exist for their language of choice. And
that's just the users who were motivated enough to ask instead of
tweeting that thrift sucks and giving up.
I think driving people to a real client is primarily a problem we can
solve with cleanup of the wiki and web site.
A harder problem is that Choice Is Bad from a user perspective. We
shouldn't be making people evaluate Hector vs Pelops, FluentCassandra
vs Aquiles, phpcassa vs SimpleCassie before writing their application.
At the time they need to make this decision they have the very least
amount of experience with Cassandra on which to base their evaluation;
we should be guiding them to a sensible default.
We are failing our users if we make them click through to the version
control history to see whether phpcassa is more actively maintained
than simplecassie.
It's a vicious cycle, too: since there are no "official" clients,
people are quicker to write their own instead of contributing to an
existing one, leading to more proliferation of (often) half-baked
clients taking up space on the wiki page. We're just getting started
on this process for 0.7, but take a look at how 0.6 ended up:
http://wiki.apache.org/cassandra/ClientOptions06. Over half of those
are abandoned now, but a new user would have to do a lot of spelunking
to figure out which was which.
Moving clients in-tree would solve this, and the problem is bad enough
that I almost wrote an email proposing that, but I would really prefer
to avoid subjecting clients to our PMC, voting process, ticket
tracking system, etc.
Instead, I think we we should aggressively curate the ClientOptions
page: pick an official client for each language, and move the rest to
an AlternativeClients page. This wouldn't be written in stone; if
someone wrote a Twisted client that he thinks is better than Telephus,
we can have a discussion on whether to move to the new one. But we
need to have a default choice to take the pain out of getting started
with Cassandra.
--
Jonathan Ellis
Project Chair, Apache Cassandra
co-founder of Riptano, the source for professional Cassandra support
http://riptano.com
Re: Reducing confusion around client libraries
Posted by Jeremy Hanna <je...@gmail.com>.
+1
I think it's great to start with cleaning up the wiki, especially the areas for beginners. With 0.7 coming out too, it might be nice to clean up the FAQ and other common pages.
On Dec 4, 2010, at 11:27 AM, Peter Schuller wrote:
> Without weighing in on the remainder of the discussion; regardless of
> what happens what do people think about at least making some minor
> structural changes to e.g. the wiki? For example, putting the Thrift
> API in a section other than the "user documentation", and being pretty
> vocal (to the point of sounding repetitious) about recommending that
> applications use the higher level clients?
>
> I think it's pretty easy to "accidentally" land in the Thrift
> documentation if you browse around.
>
> I'd be happy to try to tweak this a bit. Stuff like moving the thrift
> refs, and trying to find places on the wiki that links to the thrift
> API page and re-consider whether (or at least how) to link, etc.
>
> --
> / Peter Schuller
Re: Reducing confusion around client libraries
Posted by Gary Dusbabek <gd...@gmail.com>.
+1. I say go for it.
On Sat, Dec 4, 2010 at 11:27, Peter Schuller
<pe...@infidyne.com> wrote:
> Without weighing in on the remainder of the discussion; regardless of
> what happens what do people think about at least making some minor
> structural changes to e.g. the wiki? For example, putting the Thrift
> API in a section other than the "user documentation", and being pretty
> vocal (to the point of sounding repetitious) about recommending that
> applications use the higher level clients?
>
> I think it's pretty easy to "accidentally" land in the Thrift
> documentation if you browse around.
>
> I'd be happy to try to tweak this a bit. Stuff like moving the thrift
> refs, and trying to find places on the wiki that links to the thrift
> API page and re-consider whether (or at least how) to link, etc.
>
> --
> / Peter Schuller
>
Re: Reducing confusion around client libraries
Posted by Jonathan Ellis <jb...@gmail.com>.
I think that much at least is uncontroversial. Go for it.
On Dec 4, 2010 11:27 AM, "Peter Schuller" <pe...@infidyne.com>
wrote:
> Without weighing in on the remainder of the discussion; regardless of
> what happens what do people think about at least making some minor
> structural changes to e.g. the wiki? For example, putting the Thrift
> API in a section other than the "user documentation", and being pretty
> vocal (to the point of sounding repetitious) about recommending that
> applications use the higher level clients?
>
> I think it's pretty easy to "accidentally" land in the Thrift
> documentation if you browse around.
>
> I'd be happy to try to tweak this a bit. Stuff like moving the thrift
> refs, and trying to find places on the wiki that links to the thrift
> API page and re-consider whether (or at least how) to link, etc.
>
> --
> / Peter Schuller
Re: Reducing confusion around client libraries
Posted by Peter Schuller <pe...@infidyne.com>.
Without weighing in on the remainder of the discussion; regardless of
what happens what do people think about at least making some minor
structural changes to e.g. the wiki? For example, putting the Thrift
API in a section other than the "user documentation", and being pretty
vocal (to the point of sounding repetitious) about recommending that
applications use the higher level clients?
I think it's pretty easy to "accidentally" land in the Thrift
documentation if you browse around.
I'd be happy to try to tweak this a bit. Stuff like moving the thrift
refs, and trying to find places on the wiki that links to the thrift
API page and re-consider whether (or at least how) to link, etc.
--
/ Peter Schuller
Re: Reducing confusion around client libraries
Posted by Bjorn Borud <bb...@gmail.com>.
Bjorn Borud <bb...@gmail.com> writes:
> Eric Evans <ee...@rackspace.com> writes:
>
>> I'd be +1 for establishing objective criteria for listing libraries on
>> our wiki, but opposed to having the Apache Cassandra project declare
>> something Official.
>
> to be brutally honest, the problem would be bruised egos (which can be
> dangerous) but it would be a temporary problem -- and after that it
> would most likely be the best option of the Cassandra project in the
> long term.
clarification: I interpreted "something official" to mean "client is
part of the Cassandra project". when I read the post again I realized
that was probably not what you meant.
-Bjørn
Re: Reducing confusion around client libraries
Posted by Bjorn Borud <bb...@gmail.com>.
Eric Evans <ee...@rackspace.com> writes:
> I'd be +1 for establishing objective criteria for listing libraries on
> our wiki, but opposed to having the Apache Cassandra project declare
> something Official.
to be brutally honest, the problem would be bruised egos (which can be
dangerous) but it would be a temporary problem -- and after that it
would most likely be the best option of the Cassandra project in the
long term.
I fully agree with Jonathan that the client situation is confusing and I
think that his point about people having to make decisions *before*
having a qualified opinion is key. (thanks for articulating what I was
thinking, Jonathan!).
-Bjørn
Re: Reducing confusion around client libraries
Posted by Eric Evans <ee...@rackspace.com>.
On Fri, 2010-12-03 at 11:43 -0600, Jonathan Ellis wrote:
> The status quo is not working. There are way too many questions on
> the user list and on irc about problems with writing Thrift code, even
> when well-maintained clients exist for their language of choice. And
> that's just the users who were motivated enough to ask instead of
> tweeting that thrift sucks and giving up.
>
> I think driving people to a real client is primarily a problem we can
> solve with cleanup of the wiki and web site.
>
> A harder problem is that Choice Is Bad from a user perspective. We
> shouldn't be making people evaluate Hector vs Pelops, FluentCassandra
> vs Aquiles, phpcassa vs SimpleCassie before writing their application.
> At the time they need to make this decision they have the very least
> amount of experience with Cassandra on which to base their evaluation;
> we should be guiding them to a sensible default.
I agree that we have a problem, I've been pretty vocal about that on
this venue and others, but the proliferation is a symptom, not the
disease.
> We are failing our users if we make them click through to the version
> control history to see whether phpcassa is more actively maintained
> than simplecassie.
The Apache Cassandra project isn't responsible for either phpcassa or
simplecassie, these are projects of their own. That doesn't imply that
I don't want Cassandra/PHP users to have the best possible experience,
but having them independently developed is a feature, not a bug. So, if
there is an obvious choice, why isn't it more obvious? And, if it's not
obvious, maybe it's Good that people have a choice.
> It's a vicious cycle, too: since there are no "official" clients,
> people are quicker to write their own instead of contributing to an
> existing one, leading to more proliferation of (often) half-baked
> clients taking up space on the wiki page. We're just getting started
> on this process for 0.7, but take a look at how 0.6 ended up:
> http://wiki.apache.org/cassandra/ClientOptions06. Over half of those
> are abandoned now, but a new user would have to do a lot of spelunking
> to figure out which was which.
This is a self-fulfilling prophecy.
> Moving clients in-tree would solve this, and the problem is bad enough
> that I almost wrote an email proposing that, but I would really prefer
> to avoid subjecting clients to our PMC, voting process, ticket
> tracking system, etc.
I *really* dislike this idea, but based on what you are proposing, it
would be the most honest.
> Instead, I think we we should aggressively curate the ClientOptions
> page: pick an official client for each language, and move the rest to
> an AlternativeClients page. This wouldn't be written in stone; if
> someone wrote a Twisted client that he thinks is better than Telephus,
> we can have a discussion on whether to move to the new one. But we
> need to have a default choice to take the pain out of getting started
> with Cassandra.
I'd be +1 for establishing objective criteria for listing libraries on
our wiki, but opposed to having the Apache Cassandra project declare
something Official.
--
Eric Evans
eevans@rackspace.com
Re: Reducing confusion around client libraries
Posted by Jonathan Ellis <jb...@gmail.com>.
On Fri, Dec 3, 2010 at 1:46 PM, Gary Dusbabek <gd...@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
Re: Reducing confusion around client libraries
Posted by Ted Zlatanov <tz...@lifelogs.com>.
On Sun, 12 Dec 2010 01:56:17 +0100 Bjorn Borud <bb...@gmail.com> wrote:
BB> (users ought to be named, because an anonymous "upvote" or "downvote"
BB> conveys next to no meaningful information to me)
Alternatively the votes could be kept as two separate sets for
authenticated vs. anonymous users.
Ted
Re: Reducing confusion around client libraries
Posted by Bjorn Borud <bb...@gmail.com>.
Gary Dusbabek <gd...@gmail.com> writes:
> 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. If it isn't, then we should be actively developing
> client libraries.
I think client libraries *is* within the scope of the project, and
though I understand any reluctance towards curating the "official" list
I think that at least providing some guidance might be appropriate. if
only allowing (named) users to rate and comment on the pros and cons of
different libraries.
(users ought to be named, because an anonymous "upvote" or "downvote"
conveys next to no meaningful information to me)
-Bjørn
Re: Reducing confusion around client libraries
Posted by Gary Dusbabek <gd...@gmail.com>.
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. If it isn't, then we should be actively developing
client libraries.
I think that to take it upon ourselves to do this advocating as a
project is a bit arrogant.
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?
I am -1 on advocating official third-party client libraries.
Gary.
On Fri, Dec 3, 2010 at 11:43, Jonathan Ellis <jb...@gmail.com> wrote:
> The status quo is not working. There are way too many questions on
> the user list and on irc about problems with writing Thrift code, even
> when well-maintained clients exist for their language of choice. And
> that's just the users who were motivated enough to ask instead of
> tweeting that thrift sucks and giving up.
>
> I think driving people to a real client is primarily a problem we can
> solve with cleanup of the wiki and web site.
>
> A harder problem is that Choice Is Bad from a user perspective. We
> shouldn't be making people evaluate Hector vs Pelops, FluentCassandra
> vs Aquiles, phpcassa vs SimpleCassie before writing their application.
> At the time they need to make this decision they have the very least
> amount of experience with Cassandra on which to base their evaluation;
> we should be guiding them to a sensible default.
>
> We are failing our users if we make them click through to the version
> control history to see whether phpcassa is more actively maintained
> than simplecassie.
>
> It's a vicious cycle, too: since there are no "official" clients,
> people are quicker to write their own instead of contributing to an
> existing one, leading to more proliferation of (often) half-baked
> clients taking up space on the wiki page. We're just getting started
> on this process for 0.7, but take a look at how 0.6 ended up:
> http://wiki.apache.org/cassandra/ClientOptions06. Over half of those
> are abandoned now, but a new user would have to do a lot of spelunking
> to figure out which was which.
>
> Moving clients in-tree would solve this, and the problem is bad enough
> that I almost wrote an email proposing that, but I would really prefer
> to avoid subjecting clients to our PMC, voting process, ticket
> tracking system, etc.
>
> Instead, I think we we should aggressively curate the ClientOptions
> page: pick an official client for each language, and move the rest to
> an AlternativeClients page. This wouldn't be written in stone; if
> someone wrote a Twisted client that he thinks is better than Telephus,
> we can have a discussion on whether to move to the new one. But we
> need to have a default choice to take the pain out of getting started
> with Cassandra.
>
> --
> Jonathan Ellis
> Project Chair, Apache Cassandra
> co-founder of Riptano, the source for professional Cassandra support
> http://riptano.com
>
Re: Reducing confusion around client libraries
Posted by Bjorn Borud <bb...@gmail.com>.
Eric Evans <ee...@rackspace.com> writes:
>
> +1 This is a sensible approach IMO. A user rating system would make
> something like this even better.
for such a small community this is only useful if the person giving a
rating also puts his or her name on the rating.
-Bjørn
Re: Reducing confusion around client libraries
Posted by Eric Evans <ee...@rackspace.com>.
On Fri, 2010-12-03 at 09:59 -0800, Paul Brown wrote:
> On Dec 3, 2010, at 9:43 AM, Jonathan Ellis wrote:
> > The status quo is not working. There are way too many questions on
> > the user list and on irc about problems with writing Thrift code,
> even
> > when well-maintained clients exist for their language of choice.
> And
> > that's just the users who were motivated enough to ask instead of
> > tweeting that thrift sucks and giving up. [...]
>
> This problem isn't unique to Cassandra. It cropped up, e.g., in
> managing the proliferation of Haskell libraries on Hackage.
>
> One way that this could be accomplished with a relatively even hand is
> to ensure that the relative liveliness of the client libraries is
> apparent on the page, e.g., a most recent release date, the target
> language (and potentially any additional decoration like Spring or
> Rails or...), and a list of versions of Cassandra supported.
>
> The onus is on the client library maintainer to properly advertise
> their wares by updating the entry on the page, and making it
> sortable/searchable would be a win. (There are some rumblings about
> MoinMoin (http://moinmo.in/FeatureRequests/SortableTables) being able
> to do this, and there is also something like a Google Spreadsheet as
> an option.
+1 This is a sensible approach IMO. A user rating system would make
something like this even better.
--
Eric Evans
eevans@rackspace.com
Re: Reducing confusion around client libraries
Posted by SriSatish Ambati <sr...@gmail.com>.
This is not the first or last of these discussions:
Need for standards/good clients to access Databases has happened before one
in the early 90s.. leading to emergence of an sql-92 standard. Fast forward
to today: No database/data management software out there distributes the
server software without the necessary client drivers/software to
access/insert data. Whether in the form of default clients, type-4 drivers
etc. One could argue that a data store is incomplete without having robust
client libraries to manipulate data in there.
Notice that the end user still keeps (& has kept in other instances) the
option to install his chosen client if it performs better or works
well/supports his particular usecase well. It does not necessarily limit
choice but ups the quality barrier for distributing/creating new clients (as
opposed to contributing the existing one.) Having a default one makes
integration into larger stacks dead simple.
What we have today is power users writing their own robust features (for ex,
Thread/Connection Pooling, proper exception handling) that are not
necessarily available in all the clients & fragmented development leading to
poor overall experience. (Not to say the underlying coupling with Thrift:
Client software could inadvertently upgrade/modify thrift libraries leading
to a bit of chaos) While this is fine for experimental stages it is not a
sign of matured stacks. Not having a good client will limit the power of
Apache Cassandra and in the end drive users towards non-free client
software.
+1 For having a default client library maintained and distributed with
server.
For I believe this would make for faster wider adoption of Apache Cassandra
and bring it to a lot of new users and workloads with the goodness that
comes with being under ASF.
thanks,
Sri
On Fri, Dec 3, 2010 at 12:13 PM, Eric Evans <ee...@rackspace.com> wrote:
> On Fri, 2010-12-03 at 13:46 -0600, Tyler Hobbs wrote:
> > Personally, I like the Mongo drivers page:
> > http://www.mongodb.org/display/DOCS/Drivers
> >
> > 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.
>
> --
> Eric Evans
> eevans@rackspace.com
>
>
Re: Reducing confusion around client libraries
Posted by Tyler Hobbs <ty...@riptano.com>.
No, that's actually what I was specifically saying was not a good option.
Agreed.
On Fri, Dec 3, 2010 at 2:13 PM, Eric Evans <ee...@rackspace.com> wrote:
> On Fri, 2010-12-03 at 13:46 -0600, Tyler Hobbs wrote:
> > Personally, I like the Mongo drivers page:
> > http://www.mongodb.org/display/DOCS/Drivers
> >
> > 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.
>
> --
> Eric Evans
> eevans@rackspace.com
>
>
Re: Reducing confusion around client libraries
Posted by Tyler Hobbs <ty...@riptano.com>.
+1 Daniel.
I find the wiki to be completely unnavigable, and cleaner and clearer
documentation about the clients (including a possible per-language page)
might solve 50% of the problem.
- Tyler
On Fri, Dec 3, 2010 at 3:10 PM, Daniel Lundin <dl...@eintr.org> wrote:
> On Fri, Dec 3, 2010 at 10:07 PM, Daniel Lundin <dl...@eintr.org> wrote:
> > ... for each language/library would work (like the mongodb "language
> > centers", but with ..
>
> .. but with fewer levels of hierarchy, perhaps.
>
> /d
>
Re: Reducing confusion around client libraries
Posted by Daniel Lundin <dl...@eintr.org>.
On Fri, Dec 3, 2010 at 10:07 PM, Daniel Lundin <dl...@eintr.org> wrote:
> ... for each language/library would work (like the mongodb "language
> centers", but with ..
.. but with fewer levels of hierarchy, perhaps.
/d
Re: Reducing confusion around client libraries
Posted by Daniel Lundin <dl...@eintr.org>.
I think one issue is a lack of liveness on the web end of the project
itself. The project web site doesn't feel like the natural focal point
it ought to be, and client confusion might (in part) be an artifact of
that.
The mongodb wiki works alright without much effort because it has a
clear structure, and - in all honesty - doesn't look like raw
moinmoin. If the Cassandra web site and wiki was on confluence using a
common theme, it'd be more coherent and also encourage participation,
I think.
As for client confusion, I think having a separate page on the wiki
for each language/library would work (like the mongodb "language
centers", but with ). "What's best for ____" will distill if there's
an obvious place for the relevant people to arrive and contribute.
I don't think the project itself should be responsible for endorsing
or maintaining client, but highlighting/featuring favored options is
probably good though - especially for newcomers.
/d
Re: Reducing confusion around client libraries
Posted by Aaron Morton <aa...@thelastpickle.com>.
I agree with the importance of the Thrift API.
When I starting using Cassandra I found the idiomatic API's hid the true nature of what Cassandra does. It felt like trying to learn how a RDBMS works by learning how something like (java) hibernate or (ms) LINQ works.
IMHO Cassandra *is* the thrift/avro API just like any RDBMS *is* the SQL language.
Thanks
Aaron
On 07 Dec, 2010,at 07:15 AM, Hannes Schmidt <ha...@eyealike.com> wrote:
Probably chiming in a little late here, but I liked having the Thrift API
documentation in a prominent place. It is a canonical reference that
describes on a logical level what the system can and can't do. Without that
information it would have been much harder to understand how to use the
Hector client. And without that information I wouldn't have been able to
pinpoint bugs in libcassandra.
Having a language- and platform-independent interface specification is worth
gold in my opinion. Moving the clients under the umbrella of the project
would increase the danger that the vetted client source becomes the de-facto
reference because it would be temptingly easy to modify server and client in
lock-step for changes of the on-the-wire format without bothering to
document the change.
I also like seeing the competition of ideas in the client world. I think it
will take some time for the API to mature and settle and a wider variety of
client architectures needs to be evaluated before a set of vetted clients
should be chosen.
On Sun, Dec 5, 2010 at 6:48 AM, Simon Reavely <si...@gmail.com>wrote:
> Maybe there needs to be a "listing criteria" for a client library, that
> includes things like examples for what is considered enough to get folks
> started (connections, reads, writes, etc) in addition to what Ran
> suggested "[maintainer, last release, next release, support
> forum, number of committers, number of users, spring support, jpa support
> etc]." I would also have a "who's using us" column as well.
>
> If the library maintainer does not satisfy the listing criteria they can't
> get listed. Then we just need to decide what the criteria is ;-)
>
> Other than understanding how up to date and frequently maintained a library
> is I think that (full) good examples are essential.
>
> Having said that, I am not actually against some hierarchical organization
> in which there is some form of "tested/verified" client library list, then
> "others". To keep things fair the question would then be how something gets
> to be "tested/verified". In an opensource community I expect the library
> developers could take some of this on themselves even if the
> testing/verification is part of the main builds by way of some form of
> plugin/test suite but my level of thinking on this is shallow.
>
> Just my 2 cents/pennies on this topic!
>
> Cheers,
> Simon
>
> On Fri, Dec 3, 2010 at 4:07 PM, Ran Tavory <ra...@gmail.com> wrote:
>
> > 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
> > decide.
> > 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
> > language.
> >
> >
> > On Fri, Dec 3, 2010 at 10:25 PM, Paul Brown <pa...@gmail.com>
> 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:
> > > >> http://www.mongodb.org/display/DOCS/Drivers
> > > >>
> > > >> 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
> >
> >
> >
> >
> > --
> > /Ran
> >
>
>
>
> --
> Simon Reavely
> simon.reavely@gmail.com
>
Re: Reducing confusion around client libraries
Posted by Hannes Schmidt <ha...@eyealike.com>.
Probably chiming in a little late here, but I liked having the Thrift API
documentation in a prominent place. It is a canonical reference that
describes on a logical level what the system can and can't do. Without that
information it would have been much harder to understand how to use the
Hector client. And without that information I wouldn't have been able to
pinpoint bugs in libcassandra.
Having a language- and platform-independent interface specification is worth
gold in my opinion. Moving the clients under the umbrella of the project
would increase the danger that the vetted client source becomes the de-facto
reference because it would be temptingly easy to modify server and client in
lock-step for changes of the on-the-wire format without bothering to
document the change.
I also like seeing the competition of ideas in the client world. I think it
will take some time for the API to mature and settle and a wider variety of
client architectures needs to be evaluated before a set of vetted clients
should be chosen.
On Sun, Dec 5, 2010 at 6:48 AM, Simon Reavely <si...@gmail.com>wrote:
> Maybe there needs to be a "listing criteria" for a client library, that
> includes things like examples for what is considered enough to get folks
> started (connections, reads, writes, etc) in addition to what Ran
> suggested "[maintainer, last release, next release, support
> forum, number of committers, number of users, spring support, jpa support
> etc]." I would also have a "who's using us" column as well.
>
> If the library maintainer does not satisfy the listing criteria they can't
> get listed. Then we just need to decide what the criteria is ;-)
>
> Other than understanding how up to date and frequently maintained a library
> is I think that (full) good examples are essential.
>
> Having said that, I am not actually against some hierarchical organization
> in which there is some form of "tested/verified" client library list, then
> "others". To keep things fair the question would then be how something gets
> to be "tested/verified". In an opensource community I expect the library
> developers could take some of this on themselves even if the
> testing/verification is part of the main builds by way of some form of
> plugin/test suite but my level of thinking on this is shallow.
>
> Just my 2 cents/pennies on this topic!
>
> Cheers,
> Simon
>
> On Fri, Dec 3, 2010 at 4:07 PM, Ran Tavory <ra...@gmail.com> wrote:
>
> > 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
> > decide.
> > 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
> > language.
> >
> >
> > On Fri, Dec 3, 2010 at 10:25 PM, Paul Brown <pa...@gmail.com>
> 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:
> > > >> http://www.mongodb.org/display/DOCS/Drivers
> > > >>
> > > >> 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
> >
> >
> >
> >
> > --
> > /Ran
> >
>
>
>
> --
> Simon Reavely
> simon.reavely@gmail.com
>
Re: Reducing confusion around client libraries
Posted by Simon Reavely <si...@gmail.com>.
Maybe there needs to be a "listing criteria" for a client library, that
includes things like examples for what is considered enough to get folks
started (connections, reads, writes, etc) in addition to what Ran
suggested "[maintainer, last release, next release, support
forum, number of committers, number of users, spring support, jpa support
etc]." I would also have a "who's using us" column as well.
If the library maintainer does not satisfy the listing criteria they can't
get listed. Then we just need to decide what the criteria is ;-)
Other than understanding how up to date and frequently maintained a library
is I think that (full) good examples are essential.
Having said that, I am not actually against some hierarchical organization
in which there is some form of "tested/verified" client library list, then
"others". To keep things fair the question would then be how something gets
to be "tested/verified". In an opensource community I expect the library
developers could take some of this on themselves even if the
testing/verification is part of the main builds by way of some form of
plugin/test suite but my level of thinking on this is shallow.
Just my 2 cents/pennies on this topic!
Cheers,
Simon
On Fri, Dec 3, 2010 at 4:07 PM, Ran Tavory <ra...@gmail.com> wrote:
> 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
> decide.
> 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
> language.
>
>
> On Fri, Dec 3, 2010 at 10:25 PM, Paul Brown <pa...@gmail.com> 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:
> > >> http://www.mongodb.org/display/DOCS/Drivers
> > >>
> > >> 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
>
>
>
>
> --
> /Ran
>
--
Simon Reavely
simon.reavely@gmail.com
Re: Reducing confusion around client libraries
Posted by Ran Tavory <ra...@gmail.com>.
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
decide.
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
language.
On Fri, Dec 3, 2010 at 10:25 PM, Paul Brown <pa...@gmail.com> 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:
> >> http://www.mongodb.org/display/DOCS/Drivers
> >>
> >> 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
--
/Ran
Re: Reducing confusion around client libraries
Posted by Paul Brown <pa...@gmail.com>.
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:
>> http://www.mongodb.org/display/DOCS/Drivers
>>
>> 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
Re: Reducing confusion around client libraries
Posted by Eric Evans <ee...@rackspace.com>.
On Fri, 2010-12-03 at 13:46 -0600, Tyler Hobbs wrote:
> Personally, I like the Mongo drivers page:
> http://www.mongodb.org/display/DOCS/Drivers
>
> 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.
--
Eric Evans
eevans@rackspace.com
Re: Reducing confusion around client libraries
Posted by Tyler Hobbs <ty...@riptano.com>.
Personally, I like the Mongo drivers page:
http://www.mongodb.org/display/DOCS/Drivers
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. I
don't know that we have enough active users and maintainers for all of the
languages that we could put up the clients for a democratic vote.
Are client maintainers willing to voluntarily place their clients into
either the "official" list or the "community" list? Perhaps all clients
should be considered community supported unless selected by, say, the
Cassandra committers as being both up to quality standards and the current
best client for that language.
- Tyler
On Fri, Dec 3, 2010 at 12:18 PM, Nate McCall <na...@riptano.com> wrote:
> On Fri, Dec 3, 2010 at 11:59 AM, Paul Brown <pa...@gmail.com> wrote:
> >
> > One way that this could be accomplished with a relatively even hand is to
> ensure that the relative liveliness of the client libraries is apparent on
> the page, e.g., a most recent release date, the target language (and
> potentially any additional decoration like Spring or Rails or...), and a
> list of versions of Cassandra supported.
> >
>
> I agree with Paul - I think some additional "feature" and project
> activity comparison is the way to go near term.
>
> Nothing against ASF, but we Hector folk are happy with Github and Google
> groups.
>
Re: Reducing confusion around client libraries
Posted by Tyler Hobbs <ty...@riptano.com>.
Personally, I like the Mongo drivers page:
http://www.mongodb.org/display/DOCS/Drivers
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. I
don't know that we have enough active users and maintainers for all of the
languages that we could put up the clients for a democratic vote.
Are client maintainers willing to voluntarily place their clients into
either the "official" list or the "community" list? Perhaps all clients
should be considered community supported unless selected by, say, the
Cassandra committers as being both up to quality standards and the current
best client for that language.
- Tyler
On Fri, Dec 3, 2010 at 12:18 PM, Nate McCall <na...@riptano.com> wrote:
> On Fri, Dec 3, 2010 at 11:59 AM, Paul Brown <pa...@gmail.com> wrote:
> >
> > One way that this could be accomplished with a relatively even hand is to
> ensure that the relative liveliness of the client libraries is apparent on
> the page, e.g., a most recent release date, the target language (and
> potentially any additional decoration like Spring or Rails or...), and a
> list of versions of Cassandra supported.
> >
>
> I agree with Paul - I think some additional "feature" and project
> activity comparison is the way to go near term.
>
> Nothing against ASF, but we Hector folk are happy with Github and Google
> groups.
>
Re: Reducing confusion around client libraries
Posted by Nate McCall <na...@riptano.com>.
On Fri, Dec 3, 2010 at 11:59 AM, Paul Brown <pa...@gmail.com> wrote:
>
> One way that this could be accomplished with a relatively even hand is to ensure that the relative liveliness of the client libraries is apparent on the page, e.g., a most recent release date, the target language (and potentially any additional decoration like Spring or Rails or...), and a list of versions of Cassandra supported.
>
I agree with Paul - I think some additional "feature" and project
activity comparison is the way to go near term.
Nothing against ASF, but we Hector folk are happy with Github and Google groups.
Re: Reducing confusion around client libraries
Posted by Jonathan Ellis <jb...@gmail.com>.
On Fri, Dec 3, 2010 at 12:06 PM, Paul Brown <pa...@gmail.com> wrote:
>
> On Dec 3, 2010, at 11:54 AM, Jonathan Ellis wrote:
> >> Or a vendor who wanted Cassandra-related traffic could post a client registry backed by a simple database...
> > :)
> > Backing it with a database doesn't solve the evaluation problem, though.
>
> At the point you back it with a database, you can add a few social features like "I'm using this" or "Like" and have a reasonable collaborative filter...
Maybe that is the best compromise then -- you would still have all the
options listed but there would be a fairly strong signal when there is
momentum around one in particular.
--
Jonathan Ellis
Project Chair, Apache Cassandra
co-founder of Riptano, the source for professional Cassandra support
http://riptano.com
Re: Reducing confusion around client libraries
Posted by Paul Brown <pa...@gmail.com>.
On Dec 3, 2010, at 11:54 AM, Jonathan Ellis wrote:
>> Or a vendor who wanted Cassandra-related traffic could post a client registry backed by a simple database...
> :)
> Backing it with a database doesn't solve the evaluation problem, though.
At the point you back it with a database, you can add a few social features like "I'm using this" or "Like" and have a reasonable collaborative filter...
Cheers.
-- Paul
Re: Reducing confusion around client libraries
Posted by Jonathan Ellis <jb...@gmail.com>.
On Fri, Dec 3, 2010 at 11:59 AM, Paul Brown <pa...@gmail.com> wrote:
> One way that this could be accomplished with a relatively even hand is to ensure that the relative liveliness of the client libraries is apparent on the page, e.g., a most recent release date, the target language (and potentially any additional decoration like Spring or Rails or...), and a list of versions of Cassandra supported.
This gives the users a little more information, but still leaves it up
to each one to evaluate indpendently. (Again, I stress that they have
to do this evaluation at a point when they are not well-equipped to do
so.)
> Or a vendor who wanted Cassandra-related traffic could post a client registry backed by a simple database...
:)
Backing it with a database doesn't solve the evaluation problem, though.
--
Jonathan Ellis
Project Chair, Apache Cassandra
co-founder of Riptano, the source for professional Cassandra support
http://riptano.com
Re: Reducing confusion around client libraries
Posted by Nate McCall <na...@riptano.com>.
On Fri, Dec 3, 2010 at 11:59 AM, Paul Brown <pa...@gmail.com> wrote:
>
> One way that this could be accomplished with a relatively even hand is to ensure that the relative liveliness of the client libraries is apparent on the page, e.g., a most recent release date, the target language (and potentially any additional decoration like Spring or Rails or...), and a list of versions of Cassandra supported.
>
I agree with Paul - I think some additional "feature" and project
activity comparison is the way to go near term.
Nothing against ASF, but we Hector folk are happy with Github and Google groups.
Re: Reducing confusion around client libraries
Posted by Paul Brown <pa...@gmail.com>.
On Dec 3, 2010, at 9:43 AM, Jonathan Ellis wrote:
> The status quo is not working. There are way too many questions on
> the user list and on irc about problems with writing Thrift code, even
> when well-maintained clients exist for their language of choice. And
> that's just the users who were motivated enough to ask instead of
> tweeting that thrift sucks and giving up. [...]
This problem isn't unique to Cassandra. It cropped up, e.g., in managing the proliferation of Haskell libraries on Hackage.
One way that this could be accomplished with a relatively even hand is to ensure that the relative liveliness of the client libraries is apparent on the page, e.g., a most recent release date, the target language (and potentially any additional decoration like Spring or Rails or...), and a list of versions of Cassandra supported.
The onus is on the client library maintainer to properly advertise their wares by updating the entry on the page, and making it sortable/searchable would be a win. (There are some rumblings about MoinMoin (http://moinmo.in/FeatureRequests/SortableTables) being able to do this, and there is also something like a Google Spreadsheet as an option.
Or a vendor who wanted Cassandra-related traffic could post a client registry backed by a simple database...
-- Paul
Re: Reducing confusion around client libraries
Posted by paul cannon <pa...@riptano.com>.
+1 for aggressive curation, and -1 on moving clients in-tree.
p
On Fri, Dec 3, 2010 at 11:43 AM, Jonathan Ellis <jb...@gmail.com> wrote:
> The status quo is not working. There are way too many questions on
> the user list and on irc about problems with writing Thrift code, even
> when well-maintained clients exist for their language of choice. And
> that's just the users who were motivated enough to ask instead of
> tweeting that thrift sucks and giving up.
>
> I think driving people to a real client is primarily a problem we can
> solve with cleanup of the wiki and web site.
>
> A harder problem is that Choice Is Bad from a user perspective. We
> shouldn't be making people evaluate Hector vs Pelops, FluentCassandra
> vs Aquiles, phpcassa vs SimpleCassie before writing their application.
> At the time they need to make this decision they have the very least
> amount of experience with Cassandra on which to base their evaluation;
> we should be guiding them to a sensible default.
>
> We are failing our users if we make them click through to the version
> control history to see whether phpcassa is more actively maintained
> than simplecassie.
>
> It's a vicious cycle, too: since there are no "official" clients,
> people are quicker to write their own instead of contributing to an
> existing one, leading to more proliferation of (often) half-baked
> clients taking up space on the wiki page. We're just getting started
> on this process for 0.7, but take a look at how 0.6 ended up:
> http://wiki.apache.org/cassandra/ClientOptions06. Over half of those
> are abandoned now, but a new user would have to do a lot of spelunking
> to figure out which was which.
>
> Moving clients in-tree would solve this, and the problem is bad enough
> that I almost wrote an email proposing that, but I would really prefer
> to avoid subjecting clients to our PMC, voting process, ticket
> tracking system, etc.
>
> Instead, I think we we should aggressively curate the ClientOptions
> page: pick an official client for each language, and move the rest to
> an AlternativeClients page. This wouldn't be written in stone; if
> someone wrote a Twisted client that he thinks is better than Telephus,
> we can have a discussion on whether to move to the new one. But we
> need to have a default choice to take the pain out of getting started
> with Cassandra.
>
> --
> Jonathan Ellis
> Project Chair, Apache Cassandra
> co-founder of Riptano, the source for professional Cassandra support
> http://riptano.com
>
Re: Reducing confusion around client libraries
Posted by Jeremy Hanna <je...@gmail.com>.
Including the client-dev list for thoughts/ideas.
On Dec 3, 2010, at 11:43 AM, Jonathan Ellis wrote:
> The status quo is not working. There are way too many questions on
> the user list and on irc about problems with writing Thrift code, even
> when well-maintained clients exist for their language of choice. And
> that's just the users who were motivated enough to ask instead of
> tweeting that thrift sucks and giving up.
>
> I think driving people to a real client is primarily a problem we can
> solve with cleanup of the wiki and web site.
>
> A harder problem is that Choice Is Bad from a user perspective. We
> shouldn't be making people evaluate Hector vs Pelops, FluentCassandra
> vs Aquiles, phpcassa vs SimpleCassie before writing their application.
> At the time they need to make this decision they have the very least
> amount of experience with Cassandra on which to base their evaluation;
> we should be guiding them to a sensible default.
>
> We are failing our users if we make them click through to the version
> control history to see whether phpcassa is more actively maintained
> than simplecassie.
>
> It's a vicious cycle, too: since there are no "official" clients,
> people are quicker to write their own instead of contributing to an
> existing one, leading to more proliferation of (often) half-baked
> clients taking up space on the wiki page. We're just getting started
> on this process for 0.7, but take a look at how 0.6 ended up:
> http://wiki.apache.org/cassandra/ClientOptions06. Over half of those
> are abandoned now, but a new user would have to do a lot of spelunking
> to figure out which was which.
>
> Moving clients in-tree would solve this, and the problem is bad enough
> that I almost wrote an email proposing that, but I would really prefer
> to avoid subjecting clients to our PMC, voting process, ticket
> tracking system, etc.
>
> Instead, I think we we should aggressively curate the ClientOptions
> page: pick an official client for each language, and move the rest to
> an AlternativeClients page. This wouldn't be written in stone; if
> someone wrote a Twisted client that he thinks is better than Telephus,
> we can have a discussion on whether to move to the new one. But we
> need to have a default choice to take the pain out of getting started
> with Cassandra.
>
> --
> Jonathan Ellis
> Project Chair, Apache Cassandra
> co-founder of Riptano, the source for professional Cassandra support
> http://riptano.com
Re: Reducing confusion around client libraries
Posted by Jeremy Hanna <je...@gmail.com>.
Including the client-dev list for thoughts/ideas.
On Dec 3, 2010, at 11:43 AM, Jonathan Ellis wrote:
> The status quo is not working. There are way too many questions on
> the user list and on irc about problems with writing Thrift code, even
> when well-maintained clients exist for their language of choice. And
> that's just the users who were motivated enough to ask instead of
> tweeting that thrift sucks and giving up.
>
> I think driving people to a real client is primarily a problem we can
> solve with cleanup of the wiki and web site.
>
> A harder problem is that Choice Is Bad from a user perspective. We
> shouldn't be making people evaluate Hector vs Pelops, FluentCassandra
> vs Aquiles, phpcassa vs SimpleCassie before writing their application.
> At the time they need to make this decision they have the very least
> amount of experience with Cassandra on which to base their evaluation;
> we should be guiding them to a sensible default.
>
> We are failing our users if we make them click through to the version
> control history to see whether phpcassa is more actively maintained
> than simplecassie.
>
> It's a vicious cycle, too: since there are no "official" clients,
> people are quicker to write their own instead of contributing to an
> existing one, leading to more proliferation of (often) half-baked
> clients taking up space on the wiki page. We're just getting started
> on this process for 0.7, but take a look at how 0.6 ended up:
> http://wiki.apache.org/cassandra/ClientOptions06. Over half of those
> are abandoned now, but a new user would have to do a lot of spelunking
> to figure out which was which.
>
> Moving clients in-tree would solve this, and the problem is bad enough
> that I almost wrote an email proposing that, but I would really prefer
> to avoid subjecting clients to our PMC, voting process, ticket
> tracking system, etc.
>
> Instead, I think we we should aggressively curate the ClientOptions
> page: pick an official client for each language, and move the rest to
> an AlternativeClients page. This wouldn't be written in stone; if
> someone wrote a Twisted client that he thinks is better than Telephus,
> we can have a discussion on whether to move to the new one. But we
> need to have a default choice to take the pain out of getting started
> with Cassandra.
>
> --
> Jonathan Ellis
> Project Chair, Apache Cassandra
> co-founder of Riptano, the source for professional Cassandra support
> http://riptano.com