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