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