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