On Sun, 12 Dec 2010 01:56:17 +0100 Bjorn Borud wrote:
BB> (users ought to be named, because an anonymous "upvote" or "downvote"
BB> conveys next to no meaningful information to me)
Alternatively the votes could be kept as two separate sets for
authenticated vs. anonymous users.
Ted
Bjorn Borud writes:
> Eric Evans writes:
>
>> I'd be +1 for establishing objective criteria for listing libraries on
>> our wiki, but opposed to having the Apache Cassandra project declare
>> something Official.
>
> to be brutally honest, the problem would be bruised egos (which can be
> dangero
Gary Dusbabek writes:
> 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 client libraries *is* within the sc
Eric Evans writes:
> I'd be +1 for establishing objective criteria for listing libraries on
> our wiki, but opposed to having the Apache Cassandra project declare
> something Official.
to be brutally honest, the problem would be bruised egos (which can be
dangerous) but it would be a temporary p
Eric Evans writes:
>
> +1 This is a sensible approach IMO. A user rating system would make
> something like this even better.
for such a small community this is only useful if the person giving a
rating also puts his or her name on the rating.
-Bjørn
On Fri, Dec 3, 2010 at 12:06 PM, Paul Brown wrote:
>
> 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 probl
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/av
+1
I think it's great to start with cleaning up the wiki, especially the areas for
beginners. With 0.7 coming out too, it might be nice to clean up the FAQ and
other common pages.
On Dec 4, 2010, at 11:27 AM, Peter Schuller wrote:
> Without weighing in on the remainder of the discussion; rega
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 c
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,
+1. I say go for it.
On Sat, Dec 4, 2010 at 11:27, Peter Schuller
wrote:
> Without weighing in on the remainder of the discussion; regardless of
> what happens what do people think about at least making some minor
> structural changes to e.g. the wiki? For example, putting the Thrift
> API in a s
I think that much at least is uncontroversial. Go for it.
On Dec 4, 2010 11:27 AM, "Peter Schuller"
wrote:
> Without weighing in on the remainder of the discussion; regardless of
> what happens what do people think about at least making some minor
> structural changes to e.g. the wiki? For example
Without weighing in on the remainder of the discussion; regardless of
what happens what do people think about at least making some minor
structural changes to e.g. the wiki? For example, putting the Thrift
API in a section other than the "user documentation", and being pretty
vocal (to the point of
+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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
+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
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
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
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
33 matches
Mail list logo
