Return-Path: X-Original-To: apmail-couchdb-dev-archive@www.apache.org Delivered-To: apmail-couchdb-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 2E85E10283 for ; Tue, 10 Feb 2015 10:10:13 +0000 (UTC) Received: (qmail 37396 invoked by uid 500); 10 Feb 2015 10:10:12 -0000 Delivered-To: apmail-couchdb-dev-archive@couchdb.apache.org Received: (qmail 37333 invoked by uid 500); 10 Feb 2015 10:10:12 -0000 Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@couchdb.apache.org Delivered-To: mailing list dev@couchdb.apache.org Received: (qmail 37312 invoked by uid 99); 10 Feb 2015 10:10:12 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 10 Feb 2015 10:10:12 +0000 X-ASF-Spam-Status: No, hits=0.0 required=5.0 tests= X-Spam-Check-By: apache.org Received-SPF: error (athena.apache.org: local policy) Received: from [95.143.172.184] (HELO monoceres.uberspace.de) (95.143.172.184) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 10 Feb 2015 10:10:08 +0000 Received: (qmail 32459 invoked from network); 10 Feb 2015 10:08:26 -0000 Received: from localhost (HELO ?192.168.2.48?) (127.0.0.1) by monoceres.uberspace.de with SMTP; 10 Feb 2015 10:08:26 -0000 Content-Type: multipart/signed; boundary="Apple-Mail=_CDBDC38D-6E1F-4E4E-8090-30E530C0E812"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Subject: Re: Nano and Futon CLI X-Pgp-Agent: GPGMail 2.5b5 From: Jan Lehnardt In-Reply-To: Date: Tue, 10 Feb 2015 11:08:25 +0100 Message-Id: <8E724F63-9C13-4BDD-9988-E5426173E760@apache.org> References: <54C11531.8000206@keizer.ca> <54C2B596.20408@netzmerk.com> <1244A02F-D267-4808-A445-96D93E04AECA@apache.org> <18938844-1D43-4D0E-ABA2-004ECFF9E86F@apache.org> To: dev@couchdb.apache.org X-Mailer: Apple Mail (2.1993) X-Virus-Checked: Checked by ClamAV on apache.org --Apple-Mail=_CDBDC38D-6E1F-4E4E-8090-30E530C0E812 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 05 Feb 2015, at 20:13, Robert Kowalski wrote: >=20 > Wow that's great! >=20 > Seems we would have two initial contributors who would take care of > nano - that's great! >=20 > I know that Jan asked regarding GitHub contributions and donating to > the ASF: = http://couchdb.markmail.org/search/?q=3D%5BQUESTION%5D+Importing+a+project= +from+GitHub#query:%5BQUESTION%5D%20Importing%20a%20project%20from%20GitHu= b%20list%3Aorg.apache.couchdb.dev%20order%3Adate-backward+page:1+mid:lnbsc= zj5qdfgredq+state:results >=20 > 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 legal-discuss@.a.o =E2=80=94 It might = be a bit of an involved process. >=20 > On Thu, Jan 29, 2015 at 10:18 AM, Garren Smith = 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. >>=20 >> Another positive is that Nano.js should bring more contributors to = the CouchDB community which is a always a good thing. >>=20 >> I would be interested in contributing to Nano.js to make sure it = stays up to date. I don=E2=80=99t have a lot of free time but I would be = keen to help where I can. >> Thanks Nuno for starting this. >>=20 >> Cheers >> Garren >>=20 >>> On 27 Jan 2015, at 4:09 PM, Alexander Shorin = wrote: >>>=20 >>> Ok, fair enough. I got your point. Let's try and see how it goes. >>>=20 >>> -- >>> ,,,^..^,,, >>>=20 >>>=20 >>> On Tue, Jan 27, 2015 at 4:48 PM, Jan Lehnardt = wrote: >>>>=20 >>>>> On 27 Jan 2015, at 14:21 , Alexander Shorin = wrote: >>>>>=20 >>>>> On Tue, Jan 27, 2015 at 3:43 PM, Jan Lehnardt = wrote: >>>>>>=20 >>>>>>> On 27 Jan 2015, at 12:44 , Alexander Shorin = wrote: >>>>>>>=20 >>>>>>> On Tue, Jan 27, 2015 at 1:51 PM, Jan Lehnardt = wrote: >>>>>>>>> Why do you think that would be an improvement? >>>>>>>>=20 >>>>>>>> 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. >>>>>>>=20 >>>>>>> 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. >>>>>>=20 >>>>>> That=E2=80=99s why I like the idea of using proven libraries from = the field. >>>>>=20 >>>>> 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!"). >>>>=20 >>>> As I mentioned in the last mail, I don=E2=80=99t want to open a new = stream of activity, >>>> let=E2=80=99s focus on the proposal at hand. >>>>=20 >>>>>=20 >>>>>=20 >>>>>>> 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. >>>>>>=20 >>>>>> In addition, I don=E2=80=99t 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. >>>>>=20 >>>>> 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. >>>>>=20 >>>>>=20 >>>>>>> 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. >>>>>>=20 >>>>>> That=E2=80=99s the status quo, it is not working out so well :) >>>>>=20 >>>>> 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. >>>>=20 >>>> I wasn=E2=80=99t part of that discussion but it sounds misguided to = me. >>>>=20 >>>> 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=E2=80= =99d be >>>> easier to just have a primary client and focus on keeping that = relevant. >>>>=20 >>>>>=20 >>>>>=20 >>>>>>>> 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. >>>>>>>>=20 >>>>>>>> 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=E2=80=99t= mind stealing that from their run book. >>>>>>>=20 >>>>>>> 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. >>>>>>=20 >>>>>> This is correct, but that=E2=80=99s not really relevant to what = the end users >>>>>> see: I use PHP, what should I use to talk to MongoDB? Oh right, = there. >>>>>>=20 >>>>>> This has been consistent good feedback for them and bad feedback = for us >>>>>> since the very early days. I=E2=80=99d be very happy to address = that. >>>>>=20 >>>>> 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 (: >>>>=20 >>>> We used to have a long list of =E2=80=9CHow to get started with = X=E2=80=9D wiki pages, >>>> we should revive that, if it is stale. >>>>=20 >>>>>=20 >>>>>=20 >>>>>>> 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. >>>>>>=20 >>>>>> I don=E2=80=99t think unifying clients is a good idea. >>>>>=20 >>>>> This is what makes official clients different from group of = various >>>>> projects that called official clients. >>>>=20 >>>> I=E2=80=99d 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=E2=80=99s API surface is rather small, we = don=E2=80=99t have a big spread anyway. Libraries should use whatever is = most natural in their environment. >>>>=20 >>>>=20 >>>>>=20 >>>>>=20 >>>>>>>>> What are the advantages to both the CouchDB project and a = random library project? >>>>>>>>=20 >>>>>>>> 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 :) >>>>>>>>=20 >>>>>>>> I=E2=80=99d be happy to make it work for everyone, though. >>>>>>>>=20 >>>>>>>> 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. >>>>>>>=20 >>>>>>> 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? >>>>>>=20 >>>>>> I don=E2=80=99t 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=E2=80=99s start with that and see how it goes. If = nothing else, we can >>>>>> always spin it out into GitHub again. >>>>>=20 >>>>> Agreed. Let's make this experiment and see how it goes. In case of >>>>> success we could expand it for more. >>>>>=20 >>>>> -- >>>>> ,,,^..^,,, >>>>=20 >>=20 --Apple-Mail=_CDBDC38D-6E1F-4E4E-8090-30E530C0E812 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJU2diZAAoJENnuAeR4Uq7kj+AP/j0hK7sysVLkE6CEs7xqv2q4 lEvQ9B3Y13DRXR5x6YjZ8xBML22HX5fq6SjRzJmJ6DI8VGAP72xKxyUaGyOTTdoR K/FTuQPD96GdUfCJzfoNT9MtU8zU2xFbUJ3vvCpiwww8cJ9x9OHF6hBAilagYABY cJuenEFuCfrI226Kygiqm0KUT5ULwvMU5l3Y9wefYYtrjuJ+6kjTgE5n36cJIUQq hBR7KhzKapgbEg8clv0yNXAgBGLLfYMpwwIiksNBuh6eQdf0tA2+cIDwIHhIztAg 8MW+wNUDzcSHTrKFoBaXqT2z3EIqwJ+hczRp7DQ9iLwt3RZa390Mr2ryz1heDPMQ wxndrmWjQXHmOZIMW/ib0JqpBvGduEegnvUWElt2oVDd7T3cK2t+alJGOrTA3ifq pY4p4iHATMGIgd5CmoL7UvfoRZgnuJ0jxstFhrLzqbqIY+RPkB7HBrbr/xKlfhJX Hzn7BoBt992qlJz9v3N4tINeN169CWfvcejuVSyalZnl/peRfh7mUbmFaMwRP+1l CeJVNrX/Ei+8tJ33FfIa5nN5XylhaLG0rOHu4if8fd9gWoQM4XcOFAT6eMqXZymJ e0jbLMoQqbZjClr041cjgDX4mbaLvaE+N/piRmvQtD/yWffp7TsSpYdGU52qsKkU uz5BmKvd1VdP2XtAcj8P =ma9h -----END PGP SIGNATURE----- --Apple-Mail=_CDBDC38D-6E1F-4E4E-8090-30E530C0E812--