On Thu, Jan 31, 2013 at 3:06 PM, Benoit Chesneau <[email protected]>wrote:
> Here are some notes following your *enthousiast* mail. There is not > intention to diminish the work or things like it. It is intended to temper > a little this enthousiast and trying to find the right approach on the > problems we are trying to solve. > Totally! Like I said, I would never use this code in production. It is a highly experimental branch. I have a roadmap for this branch; but the real goal is conversation. > > > On Thu, Jan 31, 2013 at 3:46 PM, Jason Smith <[email protected]> wrote: > > > 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!" > > > > > I say "maybe". nodejs is quite trendy. but also quite new and didn't really > prove anything right now. It is quite surpassed by a pure C thing like > nginx/uwsgi when it's about http, and when it's about stability by erlang > or some. I also never had any need of nodejs when it was about doing things > with couchdb. Differerent approach I guess. Not saying the nodejs is a bad > one. If it solves your problems or at least is easier for you to handle > then that's perfectly fine. One true thing is that javascript is really > user friendly and this thing is the one that count. > I agree about the "trendy" concern. That is part of the cost, for sure. I am not sure what point you are making, about the http stack and stability. I believe a pure-node view server can meet your performance and stability requirements. > About the number of lines. Well you don't count all the lines in nodejs+v8 > as well ... but the number of loc isn't really an argument I guess. > > > > 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. > > > > This has nothing with the langage. Considering that a lot of big system are > running under python. You can also write a view server in python in one day > as fast as the nodejs server using libuv for example. or other eventloops > that didn't wait nodejs to exist. > Awesome. Please show us a view server written in Python with libuv, completed within one day. That will be very informative to this discussion. We can look at all the working, real-world view server implementations, and we can compare them. > > 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.) > > > > There have been in previous mails that you ignored. Sandboxing in couchdb > is about not sharing anything between view and not allowing external I/O > meaning access to disk or the net. This is why the erlang view engine is > disabled by default btw. > No, I am not ignoring them. I am collecting them. I feel like my list I've built is a good start but not yet comprehensive. -- Iris Couch
