couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Randall Leeds <randall.le...@gmail.com>
Subject Re: Branch to switch from SpiderMonkey to Node.js
Date Thu, 31 Jan 2013 13:51:19 GMT
On Thu, Jan 31, 2013 at 5:23 AM, Jason Smith <jhs@iriscouch.com> wrote:
> On Thu, Jan 31, 2013 at 12:55 PM, Paul Davis <paul.joseph.davis@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?

Mime
View raw message