On Jan 31, 2013, at 15:00 , Jan Lehnardt <[email protected]> wrote: > > On Jan 31, 2013, at 14:51 , Randall Leeds <[email protected]> wrote: > >> On Thu, Jan 31, 2013 at 5:23 AM, Jason Smith <[email protected]> wrote: >>> On Thu, Jan 31, 2013 at 12:55 PM, Paul Davis >>> <[email protected]>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 ^^---V8 of course.
> 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 > -- >
