On Thu, Jan 31, 2013 at 4:35 PM, Jason Smith <[email protected]> wrote:
> 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. > I wish i had time to play with that. The point is that javascript or nodejs don't change anything. What are advantages of nodejs on a pure technical aspect: - v8 for javascript - libuv for everything else if you do it in python then you have python and pyuv. Doing the things you did was the same. Though I don't see the point of having fibers. I think what you want here is a TCP or UNix socket to allows request to wait and handle them in a parallel way. It would also remove the number of OS processes. > 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. > > ok
