Nano and Futon CLI

[Nuno Job <nu...@yld.io>]

Folks,

I would love to donate the `nano` library and `futon` command line client.

* https://github.com/dscape/nano
* https://github.com/dscape/futoncli

`nano` is incredibly popular in the nodejs community and could easily
become the standard way to access couchdb. It gets lots of issues every
week, and it would be better if part of the apache project itself.

`futon` is less used but incredibly useful. I use it all the time to work
with couchdb directly from the terminal.

Both are nodejs programs.

All the best,
Nuno

Re: Nano and Futon CLI

[Andy Wenk <an...@apache.org>]

On 26 January 2015 at 22:42, Dirkjan Ochtman <di...@ochtman.nl> wrote:

> On Mon, Jan 26, 2015 at 8:18 PM, Jan Lehnardt <ja...@apache.org> wrote:
> > I’m also in favour of getting Nano into the Apache CouchDB fold.
>
> I'm curious; would you like to bring more CouchDB libraries into the
> Apache project proper? Why do you think that would be an improvement?
> What are the advantages to both the CouchDB project and a random
> library project?
>

my understanding is, that nano is not only a random library but the most
widely used library to communicate with CouchDB. The approach here is to
not let the library die and there is already a maintainer who is supporting
the move. Hopefully he will stay with the project ;-)

But I can understand your concerns and we already had discussions about how
to further maintain our own library which is used in Futon.

Cheers

Andy


>
> Cheers,
>
> Dirkjan
>



-- 
Andy Wenk
Hamburg - Germany
RockIt!

GPG fingerprint: C044 8322 9E12 1483 4FEC 9452 B65D 6BE3 9ED3 9588

 https://people.apache.org/keys/committer/andywenk.asc

Re: Nano and Futon CLI

[Jan Lehnardt <ja...@apache.org>]

> On 05 Feb 2015, at 20:13, Robert Kowalski <ro...@kowalski.gd> 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:  http://couchdb.markmail.org/search/?q=%5BQUESTION%5D+Importing+a+project+from+GitHub#query:%5BQUESTION%5D%20Importing%20a%20project%20from%20GitHub%20list%3Aorg.apache.couchdb.dev%20order%3Adate-backward+page:1+mid:lnbsczj5qdfgredq+state:results
> 
> 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 <ga...@apache.org> 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 <kx...@gmail.com> 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 <ja...@apache.org> wrote:
>>>> 
>>>>> On 27 Jan 2015, at 14:21 , Alexander Shorin <kx...@gmail.com> wrote:
>>>>> 
>>>>> On Tue, Jan 27, 2015 at 3:43 PM, Jan Lehnardt <ja...@apache.org> wrote:
>>>>>> 
>>>>>>> On 27 Jan 2015, at 12:44 , Alexander Shorin <kx...@gmail.com> wrote:
>>>>>>> 
>>>>>>> On Tue, Jan 27, 2015 at 1:51 PM, Jan Lehnardt <ja...@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.
>>>>>> 
>>>>>> 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: 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 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 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 (:
>>>> 
>>>> 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 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.
>>>>>> 
>>>>>> 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 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.
>>>>> 
>>>>> --
>>>>> ,,,^..^,,,
>>>> 
>> 

Re: Nano and Futon CLI

[Robert Kowalski <ro...@kowalski.gd>]

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:  http://couchdb.markmail.org/search/?q=%5BQUESTION%5D+Importing+a+project+from+GitHub#query:%5BQUESTION%5D%20Importing%20a%20project%20from%20GitHub%20list%3Aorg.apache.couchdb.dev%20order%3Adate-backward+page:1+mid:lnbsczj5qdfgredq+state:results

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.

On Thu, Jan 29, 2015 at 10:18 AM, Garren Smith <ga...@apache.org> 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 <kx...@gmail.com> 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 <ja...@apache.org> wrote:
>>>
>>>> On 27 Jan 2015, at 14:21 , Alexander Shorin <kx...@gmail.com> wrote:
>>>>
>>>> On Tue, Jan 27, 2015 at 3:43 PM, Jan Lehnardt <ja...@apache.org> wrote:
>>>>>
>>>>>> On 27 Jan 2015, at 12:44 , Alexander Shorin <kx...@gmail.com> wrote:
>>>>>>
>>>>>> On Tue, Jan 27, 2015 at 1:51 PM, Jan Lehnardt <ja...@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.
>>>>>
>>>>> 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: 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 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 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 (:
>>>
>>> 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 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.
>>>>>
>>>>> 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 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.
>>>>
>>>> --
>>>> ,,,^..^,,,
>>>
>

Re: Nano and Futon CLI

[Garren Smith <ga...@apache.org>]

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 <kx...@gmail.com> 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 <ja...@apache.org> wrote:
>> 
>>> On 27 Jan 2015, at 14:21 , Alexander Shorin <kx...@gmail.com> wrote:
>>> 
>>> On Tue, Jan 27, 2015 at 3:43 PM, Jan Lehnardt <ja...@apache.org> wrote:
>>>> 
>>>>> On 27 Jan 2015, at 12:44 , Alexander Shorin <kx...@gmail.com> wrote:
>>>>> 
>>>>> On Tue, Jan 27, 2015 at 1:51 PM, Jan Lehnardt <ja...@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.
>>>> 
>>>> 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: 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 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 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 (:
>> 
>> 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 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.
>>>> 
>>>> 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 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.
>>> 
>>> --
>>> ,,,^..^,,,
>> 

Re: Nano and Futon CLI

[Alexander Shorin <kx...@gmail.com>]

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 <ja...@apache.org> wrote:
>
>> On 27 Jan 2015, at 14:21 , Alexander Shorin <kx...@gmail.com> wrote:
>>
>> On Tue, Jan 27, 2015 at 3:43 PM, Jan Lehnardt <ja...@apache.org> wrote:
>>>
>>>> On 27 Jan 2015, at 12:44 , Alexander Shorin <kx...@gmail.com> wrote:
>>>>
>>>> On Tue, Jan 27, 2015 at 1:51 PM, Jan Lehnardt <ja...@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.
>>>
>>> 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: 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 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 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 (:
>
> 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 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.
>>>
>>> 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 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.
>>
>> --
>> ,,,^..^,,,
>

Re: Nano and Futon CLI

[Jan Lehnardt <ja...@apache.org>]

> On 27 Jan 2015, at 14:21 , Alexander Shorin <kx...@gmail.com> wrote:
> 
> On Tue, Jan 27, 2015 at 3:43 PM, Jan Lehnardt <ja...@apache.org> wrote:
>> 
>>> On 27 Jan 2015, at 12:44 , Alexander Shorin <kx...@gmail.com> wrote:
>>> 
>>> On Tue, Jan 27, 2015 at 1:51 PM, Jan Lehnardt <ja...@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.
>> 
>> 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: 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 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 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 (:

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 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.
>> 
>> 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 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.
> 
> --
> ,,,^..^,,,

Re: Nano and Futon CLI

[Alexander Shorin <kx...@gmail.com>]

On Tue, Jan 27, 2015 at 3:43 PM, Jan Lehnardt <ja...@apache.org> wrote:
>
>> On 27 Jan 2015, at 12:44 , Alexander Shorin <kx...@gmail.com> wrote:
>>
>> On Tue, Jan 27, 2015 at 1:51 PM, Jan Lehnardt <ja...@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.
>
> 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: 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.
>
> 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 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?
>
> 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.

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

Re: Nano and Futon CLI

[Jan Lehnardt <ja...@apache.org>]

> On 27 Jan 2015, at 12:44 , Alexander Shorin <kx...@gmail.com> wrote:
> 
> On Tue, Jan 27, 2015 at 1:51 PM, Jan Lehnardt <ja...@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.

That’s why I like the idea of using proven libraries from the field.


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

> 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 :)

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


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

I don’t think unifying clients is a good idea.


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

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.

Best
Jan
--

Re: Nano and Futon CLI

[Alexander Shorin <kx...@gmail.com>]

On Tue, Jan 27, 2015 at 1:51 PM, Jan Lehnardt <ja...@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?

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

Re: Nano and Futon CLI

[Jan Lehnardt <ja...@apache.org>]

> On 26 Jan 2015, at 22:42 , Dirkjan Ochtman <di...@ochtman.nl> wrote:
> 
> On Mon, Jan 26, 2015 at 8:18 PM, Jan Lehnardt <ja...@apache.org> wrote:
>> I’m also in favour of getting Nano into the Apache CouchDB fold.
> 
> I'm curious; would you like to bring more CouchDB libraries into the
> Apache project proper?

I’m in favour of this.


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

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.


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

Best
Jan
--



> 
> Cheers,
> 
> Dirkjan

Re: Nano and Futon CLI

[Dirkjan Ochtman <di...@ochtman.nl>]

On Mon, Jan 26, 2015 at 8:18 PM, Jan Lehnardt <ja...@apache.org> wrote:
> I’m also in favour of getting Nano into the Apache CouchDB fold.

I'm curious; would you like to bring more CouchDB libraries into the
Apache project proper? Why do you think that would be an improvement?
What are the advantages to both the CouchDB project and a random
library project?

Cheers,

Dirkjan

Re: Nano and Futon CLI

[Jan Lehnardt <ja...@apache.org>]

Heya,

thank you Nuno, this is very generous!

I’m also in favour of getting Nano into the Apache CouchDB fold.

I’ve started a thread on general@incubator.a.o to discuss some of the legal challenges, since this is not a single entity holding the copyright to the whole source, but a collaborative project with lots of small contributions and I’m not sure there is a precedent for this with the ASF.

Once we know this, we can start the regular import procedure (that starts with a vote here that establishes whether the community is interested at all).

Best
Jan
--


> On 23 Jan 2015, at 21:56 , Johannes Jörg Schmidt <sc...@netzmerk.com> wrote:
> 
> Signed PGP part
> Hi Nuno, hi Robert,
> 
> I think this is a very good idea and I want to support this. As a
> contributor and regular user of nano I am familar with the project and
> its code base. I would love to continue to be part of the nano
> maintaining team and I am willing to continue development under the ASF.
> 
> Yeah,
> Johannes
> 
> On 23.01.2015 15:44, Robert Kowalski wrote:
> > Hi Nuno,
> >
> > wow that sounds great! For me nano is _the_ Node.js library
> > regarding CouchDB.
> >
> > I really like the idea of nano being a part of the CouchDB project
> > for several reasons:
> >
> > - the projects would cross-pollinate each other more than they do
> > currently - the CouchDB project would eat more of their own dog
> > food - more people working on CouchDB related topics in the ASF -
> > even more JS folks in #couchdb-dev and the project
> >
> > I would suggest to offer nano separate from our database releases
> > as the current release cycle is ~2 releases / year.
> >
> > I also have a concern:
> >
> > We already have a jquery client library
> > (https://github.com/apache/couchdb-jquery-couch - this got
> > extracted from the old futon in 1.x), sadly we are currently quite
> > limited in our resources and don't have time to properly maintain
> > it. I am afraid this could happen also to nano because you
> > mentioned that you don't have time for the nano project. One way to
> > avoid this is that we search for new maintainers.
> >
> > Does nano currently have other maintainers next to you? What do you
> > think regarding our limited resources? Do you have ideas for
> > building a nano team already?
> >
> > Best, Robert
> >
> >
> >
> > On Thu, Jan 22, 2015 at 4:20 PM, Robert Keizer <ro...@keizer.ca>
> > wrote:
> >> I use nano and CouchDB every day, both for work and personal
> >> projects.
> >>
> >> I would love to see nano become part of the ASF under the CouchDB
> >> flag. I think standardizing libraries for various languages would
> >> be a great benefit to CouchDB itself.
> >>
> >> Just my two cents as a developer / sysadmin using both.
> >>
> >>
> >> On 2015-01-22 5:03 AM, Nuno Job wrote:
> >>> Hi Alexander,
> >>>
> >>> Responses inline:
> >>>
> >>> On Wed, Jan 21, 2015 at 7:35 PM, Alexander Shorin
> >>> <kx...@gmail.com> wrote:
> >>>
> >>>> - Why do you want to contribute these projects?
> >>>>
> >>> The main motivation is just to help CouchDB. When I started
> >>> these projects they were an hobby. These days there's enough
> >>> use in nano's part to justify a closer, more organized
> >>> attention. My lack of commitment to the project is not
> >>> helping.
> >>>
> >>> Personal reasons: None.
> >>>
> >>>
> >>>
> >>>
> >>>> - What's your expectation on their life under CouchDB flag?
> >>>>
> >>> None, anything is better than current. Just trying to help, but
> >>> as for the whole project I have no stakes in it. I love couchdb
> >>> as a user, and I think it will continue this way.
> >>>
> >>>
> >>>
> >>>> - How your contribution will improve CouchDB user
> >>>> experience?
> >>>>
> >>> I believe having a standard way to connect to CouchDB would be
> >>> extremely beneficial: WE have came far enough that the
> >>> requirements are well understood and libraries that have been
> >>> around for a while include most fixes that companies use in
> >>> production. The second reason is progress:
> >>>
> >>> (1) nano could natively support multiple versions of couch by
> >>> defining the version of the compatible api you want to connect
> >>> (2) nano could easily support extensions for apis like
> >>> cloudant (3) nano could easily support the browser
> >>>
> >>> however this requires effort and dedication to maintence. Both
> >>> things I can't do in my free time and the project would be much
> >>> more suited to do.
> >>>
> >>> As for futoncli, it just seems like a nice feature to deliver
> >>> for folks that use couch. It's pretty complete and has `raw`
> >>> mode, hence people can even script with it. If it was delivered
> >>> by default, people could easily create easier shell scripts
> >>> with couch on any installation.
> >>>
> >>>
> >>>> - Don't your fear that this will hurt them? ASF has more
> >>>> strict rules on contributions and commit bits and also in
> >>>> CouchDB team there are not much nano/futoncli active
> >>>> contributors (anyone?) to continue their maintaining.
> >>>>
> >>> It's a valid point, but I'm completely out of it and I have no
> >>> opinion. To the best of my knowledge no contributor of nano is
> >>> a apache member.
> >>>
> >>
> >>
> 

Re: Nano and Futon CLI

[Johannes Jörg Schmidt <sc...@netzmerk.com>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hi Nuno, hi Robert,

I think this is a very good idea and I want to support this. As a
contributor and regular user of nano I am familar with the project and
its code base. I would love to continue to be part of the nano
maintaining team and I am willing to continue development under the ASF.

Yeah,
Johannes

On 23.01.2015 15:44, Robert Kowalski wrote:
> Hi Nuno,
> 
> wow that sounds great! For me nano is _the_ Node.js library
> regarding CouchDB.
> 
> I really like the idea of nano being a part of the CouchDB project
> for several reasons:
> 
> - the projects would cross-pollinate each other more than they do
> currently - the CouchDB project would eat more of their own dog
> food - more people working on CouchDB related topics in the ASF -
> even more JS folks in #couchdb-dev and the project
> 
> I would suggest to offer nano separate from our database releases
> as the current release cycle is ~2 releases / year.
> 
> I also have a concern:
> 
> We already have a jquery client library 
> (https://github.com/apache/couchdb-jquery-couch - this got
> extracted from the old futon in 1.x), sadly we are currently quite
> limited in our resources and don't have time to properly maintain
> it. I am afraid this could happen also to nano because you
> mentioned that you don't have time for the nano project. One way to
> avoid this is that we search for new maintainers.
> 
> Does nano currently have other maintainers next to you? What do you
> think regarding our limited resources? Do you have ideas for
> building a nano team already?
> 
> Best, Robert
> 
> 
> 
> On Thu, Jan 22, 2015 at 4:20 PM, Robert Keizer <ro...@keizer.ca>
> wrote:
>> I use nano and CouchDB every day, both for work and personal
>> projects.
>> 
>> I would love to see nano become part of the ASF under the CouchDB
>> flag. I think standardizing libraries for various languages would
>> be a great benefit to CouchDB itself.
>> 
>> Just my two cents as a developer / sysadmin using both.
>> 
>> 
>> On 2015-01-22 5:03 AM, Nuno Job wrote:
>>> Hi Alexander,
>>> 
>>> Responses inline:
>>> 
>>> On Wed, Jan 21, 2015 at 7:35 PM, Alexander Shorin
>>> <kx...@gmail.com> wrote:
>>> 
>>>> - Why do you want to contribute these projects?
>>>> 
>>> The main motivation is just to help CouchDB. When I started
>>> these projects they were an hobby. These days there's enough
>>> use in nano's part to justify a closer, more organized
>>> attention. My lack of commitment to the project is not
>>> helping.
>>> 
>>> Personal reasons: None.
>>> 
>>> 
>>> 
>>> 
>>>> - What's your expectation on their life under CouchDB flag?
>>>> 
>>> None, anything is better than current. Just trying to help, but
>>> as for the whole project I have no stakes in it. I love couchdb
>>> as a user, and I think it will continue this way.
>>> 
>>> 
>>> 
>>>> - How your contribution will improve CouchDB user
>>>> experience?
>>>> 
>>> I believe having a standard way to connect to CouchDB would be
>>> extremely beneficial: WE have came far enough that the
>>> requirements are well understood and libraries that have been
>>> around for a while include most fixes that companies use in
>>> production. The second reason is progress:
>>> 
>>> (1) nano could natively support multiple versions of couch by
>>> defining the version of the compatible api you want to connect 
>>> (2) nano could easily support extensions for apis like
>>> cloudant (3) nano could easily support the browser
>>> 
>>> however this requires effort and dedication to maintence. Both
>>> things I can't do in my free time and the project would be much
>>> more suited to do.
>>> 
>>> As for futoncli, it just seems like a nice feature to deliver
>>> for folks that use couch. It's pretty complete and has `raw`
>>> mode, hence people can even script with it. If it was delivered
>>> by default, people could easily create easier shell scripts
>>> with couch on any installation.
>>> 
>>> 
>>>> - Don't your fear that this will hurt them? ASF has more
>>>> strict rules on contributions and commit bits and also in
>>>> CouchDB team there are not much nano/futoncli active
>>>> contributors (anyone?) to continue their maintaining.
>>>> 
>>> It's a valid point, but I'm completely out of it and I have no
>>> opinion. To the best of my knowledge no contributor of nano is
>>> a apache member.
>>> 
>> 
>> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJUwrWPAAoJED+W7gN+c0gc8e4IAIdYKk5V6D2fZp8HsruBQoUV
uaRz6LSPDBcPIT4dS+eUtOjmq8oI1098KoBE3MANIfjMGCU4yjBSFEaaX9j+B/Du
oSUV3kTF97P3FpIeZB0GbsRdlHK+nqBBAmurtNNAoWebDLINmMvPiFfLx7TiyZPo
R4oRlS9jEOUNk81Tw6oiVzJi+E54ozY0eXibRQoNtEXRGJ/t2VGcMf58DK29Mu5c
qMnqUyiwOcO9aTLSpBU87o2u3+AoAhAel1nce6+iAFp0ApBkQI7D9A28LC5Za4Vs
TJe7dPWVb4OlciuNWYajka6bA39L3Ei3JQOTMx40vR19LSJuW04x7C9OsNGwKng=
=Cjs4
-----END PGP SIGNATURE-----

Re: Nano and Futon CLI

[Andy Wenk <an...@apache.org>]

Hi all,

I would like to leave the technical bits discussion for Robert, Alex and
others. But what I do want to say is a very big thank you. This is a great
donation and I for sure would love to see a useful way to transfer nano to
the CouchDB project. We have to sort out if that will work. Nevertheless -
let alone that fact that you want to donate nano is simply awesome. Thank
you!

:)

Cheers

Andy

On 23 January 2015 at 15:44, Robert Kowalski <ro...@kowalski.gd> wrote:

> Hi Nuno,
>
> wow that sounds great! For me nano is _the_ Node.js library regarding
> CouchDB.
>
> I really like the idea of nano being a part of the CouchDB project for
> several reasons:
>
>  - the projects would cross-pollinate each other more than they do
> currently
>  - the CouchDB project would eat more of their own dog food
>  - more people working on CouchDB related topics in the ASF
>  - even more JS folks in #couchdb-dev and the project
>
> I would suggest to offer nano separate from our database releases as
> the current release cycle is ~2 releases / year.
>
> I also have a concern:
>
> We already have a jquery client library
> (https://github.com/apache/couchdb-jquery-couch - this got extracted
> from the old futon in 1.x), sadly we are currently quite limited in
> our resources and don't have time to properly maintain it. I am afraid
> this could happen also to nano because you mentioned that you don't
> have time for the nano project. One way to avoid this is that we
> search for new maintainers.
>
> Does nano currently have other maintainers next to you?
> What do you think regarding our limited resources? Do you have ideas
> for building a nano team already?
>
> Best,
> Robert
>
>
>
> On Thu, Jan 22, 2015 at 4:20 PM, Robert Keizer <ro...@keizer.ca> wrote:
> > I use nano and CouchDB every day, both for work and personal projects.
> >
> > I would love to see nano become part of the ASF under the CouchDB flag.
> > I think standardizing libraries for various languages would be a great
> > benefit to CouchDB itself.
> >
> > Just my two cents as a developer / sysadmin using both.
> >
> >
> > On 2015-01-22 5:03 AM, Nuno Job wrote:
> >> Hi Alexander,
> >>
> >> Responses inline:
> >>
> >> On Wed, Jan 21, 2015 at 7:35 PM, Alexander Shorin <kx...@gmail.com>
> wrote:
> >>
> >>> - Why do you want to contribute these projects?
> >>>
> >> The main motivation is just to help CouchDB. When I started these
> projects
> >> they were an hobby. These days there's enough use in nano's part to
> justify
> >> a closer, more organized attention. My lack of commitment to the
> project is
> >> not helping.
> >>
> >> Personal reasons: None.
> >>
> >>
> >>
> >>
> >>> - What's your expectation on their life under CouchDB flag?
> >>>
> >> None, anything is better than current. Just trying to help, but as for
> the
> >> whole project I have no stakes in it. I love couchdb as a user, and I
> think
> >> it will continue this way.
> >>
> >>
> >>
> >>> - How your contribution will improve CouchDB user experience?
> >>>
> >> I believe having a standard way to connect to CouchDB would be extremely
> >> beneficial: WE have came far enough that the requirements are well
> >> understood and libraries that have been around for a while include most
> >> fixes that companies use in production. The second reason is progress:
> >>
> >> (1) nano could natively support multiple versions of couch by defining
> the
> >> version of the compatible api you want to connect
> >> (2) nano could easily support extensions for apis like cloudant
> >> (3) nano could easily support the browser
> >>
> >> however this requires effort and dedication to maintence. Both things I
> >> can't do in my free time and the project would be much more suited to
> do.
> >>
> >> As for futoncli, it just seems like a nice feature to deliver for folks
> >> that use couch. It's pretty complete and has `raw` mode, hence people
> can
> >> even script with it. If it was delivered by default, people could easily
> >> create easier shell scripts with couch on any installation.
> >>
> >>
> >>> - Don't your fear that this will hurt them? ASF has more strict rules
> >>> on contributions and commit bits and also in CouchDB team there are
> >>> not much nano/futoncli active contributors (anyone?) to continue their
> >>> maintaining.
> >>>
> >> It's a valid point, but I'm completely out of it and I have no opinion.
> To
> >> the best of my knowledge no contributor of nano is a apache member.
> >>
> >
> >
>



-- 
Andy Wenk
Hamburg - Germany
RockIt!

GPG fingerprint: C044 8322 9E12 1483 4FEC 9452 B65D 6BE3 9ED3 9588

 https://people.apache.org/keys/committer/andywenk.asc

Re: Nano and Futon CLI

[Robert Kowalski <ro...@kowalski.gd>]

Hi Nuno,

wow that sounds great! For me nano is _the_ Node.js library regarding CouchDB.

I really like the idea of nano being a part of the CouchDB project for
several reasons:

 - the projects would cross-pollinate each other more than they do currently
 - the CouchDB project would eat more of their own dog food
 - more people working on CouchDB related topics in the ASF
 - even more JS folks in #couchdb-dev and the project

I would suggest to offer nano separate from our database releases as
the current release cycle is ~2 releases / year.

I also have a concern:

We already have a jquery client library
(https://github.com/apache/couchdb-jquery-couch - this got extracted
from the old futon in 1.x), sadly we are currently quite limited in
our resources and don't have time to properly maintain it. I am afraid
this could happen also to nano because you mentioned that you don't
have time for the nano project. One way to avoid this is that we
search for new maintainers.

Does nano currently have other maintainers next to you?
What do you think regarding our limited resources? Do you have ideas
for building a nano team already?

Best,
Robert



On Thu, Jan 22, 2015 at 4:20 PM, Robert Keizer <ro...@keizer.ca> wrote:
> I use nano and CouchDB every day, both for work and personal projects.
>
> I would love to see nano become part of the ASF under the CouchDB flag.
> I think standardizing libraries for various languages would be a great
> benefit to CouchDB itself.
>
> Just my two cents as a developer / sysadmin using both.
>
>
> On 2015-01-22 5:03 AM, Nuno Job wrote:
>> Hi Alexander,
>>
>> Responses inline:
>>
>> On Wed, Jan 21, 2015 at 7:35 PM, Alexander Shorin <kx...@gmail.com> wrote:
>>
>>> - Why do you want to contribute these projects?
>>>
>> The main motivation is just to help CouchDB. When I started these projects
>> they were an hobby. These days there's enough use in nano's part to justify
>> a closer, more organized attention. My lack of commitment to the project is
>> not helping.
>>
>> Personal reasons: None.
>>
>>
>>
>>
>>> - What's your expectation on their life under CouchDB flag?
>>>
>> None, anything is better than current. Just trying to help, but as for the
>> whole project I have no stakes in it. I love couchdb as a user, and I think
>> it will continue this way.
>>
>>
>>
>>> - How your contribution will improve CouchDB user experience?
>>>
>> I believe having a standard way to connect to CouchDB would be extremely
>> beneficial: WE have came far enough that the requirements are well
>> understood and libraries that have been around for a while include most
>> fixes that companies use in production. The second reason is progress:
>>
>> (1) nano could natively support multiple versions of couch by defining the
>> version of the compatible api you want to connect
>> (2) nano could easily support extensions for apis like cloudant
>> (3) nano could easily support the browser
>>
>> however this requires effort and dedication to maintence. Both things I
>> can't do in my free time and the project would be much more suited to do.
>>
>> As for futoncli, it just seems like a nice feature to deliver for folks
>> that use couch. It's pretty complete and has `raw` mode, hence people can
>> even script with it. If it was delivered by default, people could easily
>> create easier shell scripts with couch on any installation.
>>
>>
>>> - Don't your fear that this will hurt them? ASF has more strict rules
>>> on contributions and commit bits and also in CouchDB team there are
>>> not much nano/futoncli active contributors (anyone?) to continue their
>>> maintaining.
>>>
>> It's a valid point, but I'm completely out of it and I have no opinion. To
>> the best of my knowledge no contributor of nano is a apache member.
>>
>
>

Re: Nano and Futon CLI

[Robert Keizer <ro...@keizer.ca>]

I use nano and CouchDB every day, both for work and personal projects.

I would love to see nano become part of the ASF under the CouchDB flag.
I think standardizing libraries for various languages would be a great
benefit to CouchDB itself.

Just my two cents as a developer / sysadmin using both.


On 2015-01-22 5:03 AM, Nuno Job wrote:
> Hi Alexander,
>
> Responses inline:
>
> On Wed, Jan 21, 2015 at 7:35 PM, Alexander Shorin <kx...@gmail.com> wrote:
>
>> - Why do you want to contribute these projects?
>>
> The main motivation is just to help CouchDB. When I started these projects
> they were an hobby. These days there's enough use in nano's part to justify
> a closer, more organized attention. My lack of commitment to the project is
> not helping.
>
> Personal reasons: None.
>
>
>
>
>> - What's your expectation on their life under CouchDB flag?
>>
> None, anything is better than current. Just trying to help, but as for the
> whole project I have no stakes in it. I love couchdb as a user, and I think
> it will continue this way.
>
>
>
>> - How your contribution will improve CouchDB user experience?
>>
> I believe having a standard way to connect to CouchDB would be extremely
> beneficial: WE have came far enough that the requirements are well
> understood and libraries that have been around for a while include most
> fixes that companies use in production. The second reason is progress:
>
> (1) nano could natively support multiple versions of couch by defining the
> version of the compatible api you want to connect
> (2) nano could easily support extensions for apis like cloudant
> (3) nano could easily support the browser
>
> however this requires effort and dedication to maintence. Both things I
> can't do in my free time and the project would be much more suited to do.
>
> As for futoncli, it just seems like a nice feature to deliver for folks
> that use couch. It's pretty complete and has `raw` mode, hence people can
> even script with it. If it was delivered by default, people could easily
> create easier shell scripts with couch on any installation.
>
>
>> - Don't your fear that this will hurt them? ASF has more strict rules
>> on contributions and commit bits and also in CouchDB team there are
>> not much nano/futoncli active contributors (anyone?) to continue their
>> maintaining.
>>
> It's a valid point, but I'm completely out of it and I have no opinion. To
> the best of my knowledge no contributor of nano is a apache member.
>

Re: Nano and Futon CLI

[Nuno Job <nu...@gmail.com>]

Hi Alexander,

Responses inline:

On Wed, Jan 21, 2015 at 7:35 PM, Alexander Shorin <kx...@gmail.com> wrote:

> - Why do you want to contribute these projects?
>

The main motivation is just to help CouchDB. When I started these projects
they were an hobby. These days there's enough use in nano's part to justify
a closer, more organized attention. My lack of commitment to the project is
not helping.

Personal reasons: None.




> - What's your expectation on their life under CouchDB flag?
>

None, anything is better than current. Just trying to help, but as for the
whole project I have no stakes in it. I love couchdb as a user, and I think
it will continue this way.



> - How your contribution will improve CouchDB user experience?
>

I believe having a standard way to connect to CouchDB would be extremely
beneficial: WE have came far enough that the requirements are well
understood and libraries that have been around for a while include most
fixes that companies use in production. The second reason is progress:

(1) nano could natively support multiple versions of couch by defining the
version of the compatible api you want to connect
(2) nano could easily support extensions for apis like cloudant
(3) nano could easily support the browser

however this requires effort and dedication to maintence. Both things I
can't do in my free time and the project would be much more suited to do.

As for futoncli, it just seems like a nice feature to deliver for folks
that use couch. It's pretty complete and has `raw` mode, hence people can
even script with it. If it was delivered by default, people could easily
create easier shell scripts with couch on any installation.


> - Don't your fear that this will hurt them? ASF has more strict rules
> on contributions and commit bits and also in CouchDB team there are
> not much nano/futoncli active contributors (anyone?) to continue their
> maintaining.
>

It's a valid point, but I'm completely out of it and I have no opinion. To
the best of my knowledge no contributor of nano is a apache member.

Re: Nano and Futon CLI

[Alexander Shorin <kx...@gmail.com>]

Hi,

Few questions:
- Why do you want to contribute these projects?
- What's your expectation on their life under CouchDB flag?
- How your contribution will improve CouchDB user experience?
- Don't your fear that this will hurt them? ASF has more strict rules
on contributions and commit bits and also in CouchDB team there are
not much nano/futoncli active contributors (anyone?) to continue their
maintaining.

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


On Wed, Jan 21, 2015 at 3:42 PM, Nuno Job <nu...@yld.io> wrote:
> Folks,
>
> I would love to donate the `nano` library and `futon` command line client.
>
> * https://github.com/dscape/nano
> * https://github.com/dscape/futoncli
>
> `nano` is incredibly popular in the nodejs community and could easily
> become the standard way to access couchdb. It gets lots of issues every
> week, and it would be better if part of the apache project itself.
>
> `futon` is less used but incredibly useful. I use it all the time to work
> with couchdb directly from the terminal.
>
> Both are nodejs programs.
>
> All the best,
> Nuno