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