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
