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 >