On Sep 21, 2013, at 11:48 , Benoit Chesneau <[email protected]> wrote:
> On Fri, Sep 20, 2013 at 4:56 PM, Jan Lehnardt <[email protected]> wrote: > >> >> 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 >> -- >> >> > We can disapprove or not about the the popularity of Javascript neither if > it's really understood by most or if it is the best programming language. > It really depends in which branch you are working in computer industry: > web, game, science, ... or which kind of company. Each have their winner, > and for example in the game industry, javascript is only starting to come > in, some are using different scripting languages... It is also depends on > what you consider programming is, if you value the readability or not, such > things. Only the future will tell us, which kind of programming will win, > even if some are trying hard to remove the choice these days by imposing a > language in their UI or their devices. > > Anyway I don't really care if Apache CouchDB has to be shipped with > Javascript support or not. The point here is more here to have a way to > disable it, to make it optional so people can deploy and upgrade it more > easily according their needs. And I don't see any reason for now to not > ship Apache CouchDB with javascript until it can be made optional during > the build. Yeah, that’s exactly what I thought you mean. I just wanted to make sure we don’t end up in a situation where we start arguing for the removal of JavaScript :) Best Jan -- > > - benoit > > > >> >>> 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
