couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Lehnardt <>
Subject Re: Nano and Futon CLI
Date Tue, 10 Feb 2015 10:08:25 GMT

> On 05 Feb 2015, at 20:13, Robert Kowalski <> wrote:
> Wow that's great!
> Seems we would have two initial contributors who would take care of
> nano - that's great!
> I know that Jan asked regarding GitHub contributions and donating to
> the ASF:
> and while thinking about his question I got reminded that Phonegap
> (now Cordova) was initially a GitHub project. I'll ping Brian Leroux,
> maybe he can provide some insights.

There is some more discussion on legal-discuss@.a.o — It might be a bit of an involved process.

> On Thu, Jan 29, 2015 at 10:18 AM, Garren Smith <> wrote:
>> I think bringing Nano.js under Apache CouchDB is a fantastic idea. This is really
exciting. Nano.js is a very well written library with a great API. Its also very popular.
If we could get it into ASF we can make sure that when CouchDB 2.0 lands we have a library
that works properly with it immediately and supports all new features like Query.
>> Another positive is that Nano.js should bring more contributors to the CouchDB community
which is a always a good thing.
>> I would be interested in contributing to Nano.js to make sure it stays up to date.
I don’t have a lot of free time but I would be keen to help where I can.
>> Thanks Nuno for starting this.
>> Cheers
>> Garren
>>> On 27 Jan 2015, at 4:09 PM, Alexander Shorin <> wrote:
>>> Ok, fair enough. I got your point. Let's try and see how it goes.
>>> --
>>> ,,,^..^,,,
>>> On Tue, Jan 27, 2015 at 4:48 PM, Jan Lehnardt <> wrote:
>>>>> On 27 Jan 2015, at 14:21 , Alexander Shorin <>
>>>>> On Tue, Jan 27, 2015 at 3:43 PM, Jan Lehnardt <>
>>>>>>> On 27 Jan 2015, at 12:44 , Alexander Shorin <>
>>>>>>> On Tue, Jan 27, 2015 at 1:51 PM, Jan Lehnardt <>
>>>>>>>>> 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
>>>>>>> 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!").
>>>> As I mentioned in the last mail, I don’t want to open a new stream of activity,
>>>> let’s focus on the proposal at hand.
>>>>>>> I don't see anything bad in having 5+ libraries per language:
>>>>>>> of of them people made to solve own problems. The most successful
>>>>>>> became popular and have own community to continue maintaining,
>>>>>>> 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
>>>>>> 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
>>>>>>> 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 wasn’t part of that discussion but it sounds misguided to me.
>>>> The drawback with this is having to keep up to date with the relative
>>>> reliability of all entries, and that could be a lot of work. It’d be
>>>> easier to just have a primary client and focus on keeping that relevant.
>>>>>>>> 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
>>>>>>> people. The difference is in clients API consistency: you may
>>>>>>> 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
>>>>>> 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 (:
>>>> We used to have a long list of “How to get started with X” wiki pages,
>>>> we should revive that, if it is stale.
>>>>>>> I personally, didn't investigated MongoDB drivers much, but if
>>>>>>> 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
>>>>>>> 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.
>>>> I’d strongly disagree. I think the use-case of familiarity with one particular
API being the same in a different language is a very minor one. Since CouchDB’s API surface
is rather small, we don’t have a big spread anyway. Libraries should use whatever is most
natural in their environment.
>>>>>>>>> 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
>>>>>>> That's really great point, but we should make this step carefully
>>>>>>> define first what the thirdparty libraries we would like to see
>>>>>>> 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
>>>>>>> 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
>>>>>> 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