On Thu, Jan 31, 2013 at 1:51 PM, 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. > Quite right. This branch answers half that question: what do you get? So far, this is my list of good things I've seen: 1. Better code. 1a. Cut almost 3,000 lines of code 1b. Exchanged SM build dependency for Node runtime dependency. This right here--this summarizes the whole exercise. 2. Very encouraging degree of compatibility. Consider, the 1,500 lines of view server JS code: none of it was ever intended for Node.js. But the test suite shows, the two are virtually identical. 3. Apparently this is already easier to use than homebrew. Homebrew pins SM apparently to support Mongo (unsure if the latter is true). 4. Got a lot of enthusiasm. (A lot of people tested it and emailed to ask "why isn't it faster?"). This thread got a lot of feedback about new protocols, and async APIs, and app-building features. Why? I think when you say Node.js and CouchDB everybody says "Yes!" 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 you want API stability, then you'll like Node.js. The whole principle of the project is to be "finished" one day. Node.js is less likely than Python, say, to break a simple, 300-line repl program. (My point is: not likely.) But yes, you've put your finger on it. This is a runtime dependency. 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 JS code is already engine-agnostic. My couchjs implementation runs all that code. I can also test couchjs directly with a couchjs client I wrote: https://github.com/iriscouch/couchjs-client. That tool can read log files and play them against any couchjs-compatible program. I log the interactions messages during the test suite. And then I play them back to both C and Node.js couchjs. They are identical. I did some work on an async API. 1. https://github.com/apache/couchdb/commit/a614678c 2. https://github.com/apache/couchdb/commit/e0278596 I tried this. But the problem is, list functions provide basically a blocking getRow() function. Once I realized that, I backed it out. 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? The word "sandbox" is vague. There is no clear definition. (There is a mundane historical reason for that: the "sandbox" was whatever the C program did.) Prediction: as quickly as we identify sandbox features, somebody can build a Node.js implementation to reasonable satisfaction. But we'll see. -- Iris Couch
