couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexander Shorin <kxe...@gmail.com>
Subject Re: Nano and Futon CLI
Date Tue, 27 Jan 2015 11:44:02 GMT
On Tue, Jan 27, 2015 at 1:51 PM, Jan Lehnardt <jan@apache.org> wrote:
>> Why do you think that would be an improvement?
>
> In the past, we let the community come up with whatever it needs, which was a decent
call, but it has lead to a situation, where we have 5+ libraries per language and they all
implement another 80%-set of the CouchDB functionality. When one gets started with CouchDB,
there is always some research to be done, on what to use.

There is also quite opposite situation when "official"
clients/drivers/libs falls into the trap when initial bad
architectural decisions makes them unusable in real life. Such
situation puts official solution on the line: to continue be "bad",
but keep compatibility for existed users or break it to have a chance
still be actual in near future.

I don't see anything bad in having 5+ libraries per language: almost
of of them people made to solve own problems. The most successful ones
became popular and have own community to continue maintaining, testing
and improving them. Others left as personal pet-projects what is again
ok.

I think we could simply limit us by providing recommendation on each
library(-ries) per language that we would like to see as official and
provide them informational support. The community will do everything
else. This action wouldn't require much from us and will not cause any
breaking changes in projects life.

> I think it would be beneficial for people new to CouchDB to know where to get the definite
library that will get them started. That still leaves room for more specialised or opinionated
libraries beside that.
>
> One of the things that people like about MongoDB is that it is so easy to get started
with, because the language integration is part of the whole package and maintained by the
MongoDB people. I wouldn’t mind stealing that from their run book.

There is a little difference between MongoDB and our approach:
MongoDB's clients were made by the same team, not by various side
people. The difference is in clients API consistency: you may switch
the language, but you'll be sure that the official client implements
methods you used and they works in the same way.

I personally, didn't investigated MongoDB drivers much, but if you
look on RethinkDB ones: http://rethinkdb.com/api/javascript/ - they
uses the same "official clients" approach - you'll see that clients
API is almost equivalent whatever language you select. If it will not,
then there is no much sense for having "official client" if each will
acts different for the same API call.

>> What are the advantages to both the CouchDB project and a random library project?
>
> In this specific case, the project maintainer wants to make sure the project survives
and trusts this community with it. For every other library that we may or may not be integrating,
it will depend :)
>
> I’d be happy to make it work for everyone, though.
>
> A side benefit, as I see it, is that more people get familiar with the CouchDB development
process and are more likely to help out on other things on the project.

That's really great point, but we should make this step carefully and
define first what the thirdparty libraries we would like to see and
what the requirements we apply on them. For instance, I, as a man from
aside, wonder why nano if there is more popular and active crade for
node.js? FIFO principle?

--
,,,^..^,,,

Mime
View raw message