On Sep 19, 2013, at 11:51 , Benoit Chesneau <[email protected]> wrote:
> Hi, > > I am thinking to make all this extra C optional in couchdb. By extra C I > mean: > > - snappy compression > - couch compare function using ICU > - JS views > - JSON encoding > > Basically anything that is not included in the erlang standard library or > not in Erlang. The reason for that is to allow a simple distribution on > different platforms or vms things like erlangonxen. Also it would improve a > lot the way we can upgrade a full release or change a module live. > > First one is easy, the second I don't know I guess we can have a more > simpler binary comparison is possible or maybe better providing a pure > erlang implementation of it using ux [1] wich is probably enough faster for > our need (we only require to compare ids or keys). > > We mostly have JS because it's easy to handle for an end-developer and also > trendy among some circles. I massively support moving to a tiny Erlang-only core for CouchDB with additional features on the side. We need to differentiate between what the core of CouchDB is and what the distribution we ship to end users includes. I would not feel comfortable shipping a major version of CouchDB in the future that doesn’t include JavaScript powered views. Instead, I think it should be very simple for us to ship, or for users to compile, a version of CouchDB that is just the core, or just the core and only the extensions they are interested in, not the ones that we think are a good default for everyone (someone might want to have a CouchDB distribution without a replicator and that should be totally easy to set up). (Not saying it was suggested that CouchDB-core should be the default distribution, I just want to point out that it is an important distinction to make) Why do I think we should not ship a CouchDB version without JavaScript? This is a direct reaction to “trendy among some circles”. JavaScript is by far the most deployed, the most programmed and the most understood programming language in the world and it is only gaining at this point. To pretend that it is a niche phenomenon is ignoring the massive advantages we gain from shipping JavaScript support by default. Nearly everyone knows at least enough JavaScript to get something done in CouchDB, that is a benefit that I don’t see go away any time soon and I think it is *very* important for us to keep this going. I am very eager to support JS alternatives, and I am #1 in longing for a neat DSL (hopefully done on top of Erlang or Elexir) that allows us to define views and other useful things in a neat declarative way. But we don’t have that yet, and for when we do, I still thing enough use cases that require a bona-fide programming language and the best one for that in today’s world and the near future is JavaScript. I’m not saying JavaScript is the best programming language, but given what we need a programming language for, JavaScript is the best option we have. That’s why I think Apache CouchDB should ship with a JavaScript interpreter by default for the foreseeable future. I also very much support the idea of a pure-Erlang core for the users that need that, but we need to make sure we do the right thing for most of our end users in a way that doesn’t disadvantage the rest and I think the scenario of a small core as suggested + addons that make up a default distribution with the possibility of making custom distributions easily gets us exactly that. Best Jan -- > But i think we could provide here another > default. That can be elixir [2] or lua using luerl module [3]. The second > one may be the easier since it is also provide for free the sandbox we are > supposed to have in JS. Not sure it is easy to do with elixir. > > > Thoughts? > > - benoit > > [1] https://github.com/erlang-unicode/ux > [2] http://elixir-lang.org/ > [3] https://github.com/rvirding/luerl
signature.asc
Description: Message signed with OpenPGP using GPGMail
