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

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