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 <han...@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 <simon.reav...@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 <ran...@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 <paulrbr...@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.reav...@gmail.com
>
