On Thu, Jan 31, 2013 at 5:23 AM, Jason Smith <j...@iriscouch.com> wrote: > On Thu, Jan 31, 2013 at 12:55 PM, Paul Davis > <paul.joseph.da...@gmail.com>wrote: > >> >> That whole process sounds like not a lot of fun. >> > > Right. That is kind of my point. CouchDB is a JavaScript thing, and > nowadays people have a very well-adopted and well-understood JavaScript > engine on their computers. Maybe it should just use that.
(Some) developers have node installed (or can install it easily). End users are a totally different story. They may be able to install it, but we're talking about adding a runtime dependency unless we bundle node. Imagine you have CouchDB installed and then a future node version breaks compatibility for some API used by the node-couchjs. You now have to decide whether to upgrade node or try to have multiple node versions so couchjs can continue to work. In short I think this is my issue: we're pushing problems down from maintainers and packagers to users. If we're just trying to make the building/packaging/maintaining process easier, I would rather bundle spidermonkey than bundle node (or bundle v8 and rewrite couchjs against v8). Thinking about this all a bit more, maybe this is a viable option: 1) Figure out how to refactor the JS code in couchjs to be engine agnostic. It likely mostly is already, but we may want to make the I/O a bit more abstracted and certainly give it an async API 2) Make couchjs an optional configure flag, which builds a couchjs that wraps step (1) 3) Have node-couchjs included, as pure JS code that also wraps (1), but don't bundle any dependency like node or v8 I think this would be a good solution unless we can demonstrate confidently that we can sandbox node appropriately for a view server. It lets your average developer get by without the spidermonkey hassle, but a maintainer of a downstream package can decide whether they want a sandboxed view server and don't mind dealing with spidermonkey packaging or to punt and add a runtime dependency on node. We could also run the JS test suite from the CLI using node-couchjs. Is there anyone who isn't served by this path, or whose problems are worsened by it?