On Jan 31, 2013, at 14:51 , Randall Leeds <randall.le...@gmail.com> wrote:
> 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). I’m pretty sure this is an ASF legal no-go because of the MPL. > 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 The argument against allowing multiple engines are subtle differences. You don’t want two servers to not be able to replicate because your validation function behaves differently on V8 and SpiderMonkey. I’m strongly in favour of only supporting a single JS Engine at a time. (this falls apart for different versions of CouchDB that didn’t have SM, of course, but with the new release schedule I hope we can leave them behind quickly. I just don’t want this to be an ongoing point of potential trouble, a transition time is tolerable though, IMHO). Cheers Jan --
