couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexander Shorin <>
Subject Re: Nano and Futon CLI
Date Tue, 27 Jan 2015 13:21:57 GMT
On Tue, Jan 27, 2015 at 3:43 PM, Jan Lehnardt <> wrote:
>> On 27 Jan 2015, at 12:44 , Alexander Shorin <> wrote:
>> On Tue, Jan 27, 2015 at 1:51 PM, Jan Lehnardt <> 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.
> That’s why I like the idea of using proven libraries from the field.

Need to define what we call "proven library". Proven by time? Number
of stars on Github? Amount of downloads or questions on StackOverflow?
Or CouchDB API coverage and simplicity to work with it? Clear rules
will simplify decision making and will cut off personal taste from it
("oh, I love X let pick it!").

>> 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.
> In addition, I don’t see the project-provided libraries as an exclusionary
> thing. There will always be room for alternatives and we will point people
> to them, should their needs warrant it.

Sure, we shouldn't and cannot ban users to create new libraries
around. The problem is that after "official libraries" the others will
have to stay in the shadow. I think some maintainable page on wiki
with libraries short overview + comparison table is good enough to
also provide informational support for non-official ones.

>> 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.
> That’s the status quo, it is not working out so well :)

We didn't even tries. Two years ago I raised that question for the
docs: should we mention third party tools and clients to work with
CouchDB. The answer was no: we shouldn't shift the balance of end user
decision. Now it seems the mind is changed on this question.

>>> 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.
> This is correct, but that’s not really relevant to what the end users
> see: I use PHP, what should I use to talk to MongoDB? Oh right, there.
> This has been consistent good feedback for them and bad feedback for us
> since the very early days. I’d be very happy to address that.

Tutorial in docs is pretty enough. "How to start with PHP" and here
are the ways you can use...Currently we don't have anything like that.
Only strong propaganda of curl tool (:

>> I personally, didn't investigated MongoDB drivers much, but if you
>> look on RethinkDB ones: - 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.
> I don’t think unifying clients is a good idea.

This is what makes official clients different from group of various
projects that called official clients.

>>>> What are the advantages to both the CouchDB project and a random library
>>> 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?
> I don’t think we have to solve the general case right now (although it is
> good to have this discussion). We currently have the offer to make Nano
> ours. Let’s start with that and see how it goes. If nothing else, we can
> always spin it out into GitHub again.

Agreed. Let's make this experiment and see how it goes. In case of
success we could expand it for more.


View raw message