incubator-cassandra-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Reavely <simon.reav...@gmail.com>
Subject Re: Reducing confusion around client libraries
Date Sun, 05 Dec 2010 14:48:42 GMT
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 <rantav@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 <paulrbrown@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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message