Build failed in Hudson: Cassandra-0.7 #50

See Changes: [brandonwilliams] Reduce FatClient timeout to RING_DELAY / 2. Patch by brandonwilliams, reviewed by jbellis for CASSANDRA-1730. [jbellis] copy bytebuffers forlocal writes toavoid retainingthe entire Thrift frame patc

Re: Reducing confusion around client libraries

+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 wrote: > On Fri, Dec 3, 2010 at 10:07 PM, Daniel Lundi

Re: Reducing confusion around client libraries

On Fri, Dec 3, 2010 at 10:07 PM, Daniel Lundin 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

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 struct

Re: Reducing confusion around client libraries

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

Re: Reducing confusion around client libraries

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 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 lik

Re: Reducing confusion around client libraries

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 clut

Re: Reducing confusion around client libraries

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 witho

Re: Reducing confusion around client libraries

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 d

Re: Reducing confusion around client libraries

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

Re: Reducing confusion around client libraries

On Fri, Dec 3, 2010 at 1:46 PM, Gary Dusbabek 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 do

Re: Reducing confusion around client libraries

On Fri, Dec 3, 2010 at 11:59 AM, Paul Brown 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 ad

Re: Reducing confusion around client libraries

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 th

Re: Reducing confusion around client libraries

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 i

Re: Reducing confusion around client libraries

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" sec

Re: Reducing confusion around client libraries

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 wh

Build failed in Hudson: Cassandra-0.7 #49

See Changes: [jbellis] improved validation of column_metadata patch by jbellis; reviewed by gdusbabek for CASSANDRA-1813 -- [...truncated 1566 lines...] [junit] Testsuite: org.apache.cassa

Re: Reducing confusion around client libraries

On Fri, Dec 3, 2010 at 11:59 AM, Paul Brown 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

Re: Reducing confusion around client libraries

+1 for aggressive curation, and -1 on moving clients in-tree. p On Fri, 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 ex

Re: Reducing confusion around client libraries

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 langua

Re: Reducing confusion around client libraries

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

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 suc

Build failed in Hudson: Cassandra-0.7 #48

See Changes: [jbellis] validateCfDef on add_keyspace patch by jbellis -- [...truncated 1566 lines...] [junit] Testsuite: org.apache.cassandra.dht.OrderPreservingPartitionerTest [junit]

Build failed in Hudson: Cassandra-0.7 #47

See Changes: [jbellis] add debug messages for system_ thrift calls patch by jbellis -- [...truncated 1575 lines...] [junit] Cobertura: Saved information on 961 classes. [junit] Testsui

Build failed in Hudson: Cassandra-0.7 #46

See Changes: [jbellis] cli support index type enum names patch by Pavel Yaskevich; reviewed by jbellis for CASSANDRA-1810 [jbellis] fix cli case sensitivity for index queries patch by Pavel Yaskevich; reviewed by jbellis for CASSAND