> On 05 Feb 2015, at 20:13, Robert Kowalski <[email protected]> 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 [email protected] — It might be a bit of an involved process. > > On Thu, Jan 29, 2015 at 10:18 AM, Garren Smith <[email protected]> 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 <[email protected]> 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 <[email protected]> wrote: >>>> >>>>> On 27 Jan 2015, at 14:21 , Alexander Shorin <[email protected]> wrote: >>>>> >>>>> On Tue, Jan 27, 2015 at 3:43 PM, Jan Lehnardt <[email protected]> wrote: >>>>>> >>>>>>> On 27 Jan 2015, at 12:44 , Alexander Shorin <[email protected]> wrote: >>>>>>> >>>>>>> On Tue, Jan 27, 2015 at 1:51 PM, Jan Lehnardt <[email protected]> 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. >>>>> >>>>> -- >>>>> ,,,^..^,,, >>>> >>
signature.asc
Description: Message signed with OpenPGP using GPGMail
