On Fri, Jan 25, 2013 at 3:36 PM, Paul Davis <paul.joseph.da...@gmail.com>wrote:
>
>
>
> On Fri, Jan 25, 2013 at 8:51 AM, Jason Smith <j...@iriscouch.com> wrote:
>
>> I agree with Benoit, *however* those are out-of-scope for my branch. The
>> experiment is to explore *build* dependencies, nothing else. The Node.js
>> component is simply 100% compatible with couchjs, providing the same API
>> for all the code in share/server/*.js.
>>
>> I am intrigued about hybrid Node/Couchapps, or new ways to do views and
>> build apps, but that's not related to this branch. This branch is to
>> improve building, not running.
>>
>>
> Definitely agree here. We should focus on the view engine and leave the
> other bits until a later time. Definitely agree that we should look into
> feasibility before we rush from one tar pit to another (if that's how it
> turns out).
>
>
Not that node is necessarily a tar pit. It could definitely turn out to be
a rocket ship. We just want to look before we hurtle ourselves off this
particular cliff.
> Paul,
>>
>> Even today people have more success installing Node.js version 0.8 than
>> libmozjs version anything. Node.js ships binaries for every platform. The
>> situation will only improve. Node.js is a rocket ship.
>>
>>
> This is definitely possible but I'm not sure I'm going to take it as a
> matter of fact. We never hear from the people that don't have issues
> installing things so there could be a bit of a confirmation bias on which
> is more easily installed. That said, even though spidermonkey does have
> packages I agree that its definitely not turn key. And if Node provides
> binaries for a huge swath of platforms that may be more than enough for us
> to stop caring on the ease of installation issue.
>
>
>> My suspicion is Node.js simply moves so fast as a general-purpose tool
>> that
>> it can or will provide everything needed for a replacement view server.
>> Should we even replace the view server? Change the protocol? Embed JS as a
>> NIF? All good questions. This branch will (slightly) inform those larger
>> discussions.
>>
>> Will you permit a prediction with no prior research: Node.js has a very
>> good sandboxing story. Some package out there has already exposed the V8
>> API in a convenient way. Perhaps more people need Node.js sandboxing than
>> the size of the entire CouchDB community. The npm registry serves 100
>> million requests per month and that number doubles every five months.
>>
>> I would like to see a clear definition of "sandboxing." I proposed a
>> definition in JIRA. Without clearly defining what it means to be "secure"
>> or "sandboxed" it is hard to give a good answer.
>>
>>
> Easy: code stored in a design doc is executed in an environment that has
> access limited to a specific set of white listed APIs in its execution
> context.
>
> My personal feeling? CouchDB has had AFAIK zero security issues with the
>> JavaScript VM. Over how many years? That is huge. Nobody comes home from
>> work and tells their spouse, "CouchDB protected my data today. Again." No
>> office has a chalkboard saying "952 days without a CouchDB security
>> breach." But they should. If Node.js cannot provide the same guarantees,
>> that is a deal breaker.
>>
>>
> +1
>
>
>> Finally, IMO, the anonymous function issue is not CouchDB's problem. That
>> is the view server's problem. In the 1.x API, a view server must support
>> "function() {}" full-stop. Personally, I think JavaScript is a better
>> place
>> to provide compatibility. Couch sends you a string. Parse the string, wrap
>> it in parens, wave a chicken, whatever. My implementation (optimized for
>> shipping date), creates a Function() with a body of "return (" + the_code
>> +
>> ")". So it is a metafunction or something. I run that function and now I
>> have the map, reduce, filter, etc. function the user expects to run.
>> Instead, one might use Esprima to parse the source code and from there
>> anything can happen. My point (and opinion) is, the code that handles the
>> anonymous function problem should be JavaScript, not C or Autotools.
>>
>>
>>
> +1 in general. I agree with your sentiment but not on some of the
> specifics. While I think you're quite right that the place to deal with
> this issue is inside the view server itself and its not "CouchDB the
> Erlang/C/Autotools project" that should be managing this. That said it very
> much is "CouchDB the project"'s problem in that we need to provide clear
> coherent directions on exactly what works where and how to fix things.
>
> I could see this direction being a very clear "In 1.x/2.x you have to make
> minor modifications too all of your JS code" on one end of the spectrum vs
> a "We should be able to transparently upgrade your code" on the other end
> with the most likely "your code will just work if you don't use external
> helper functions". Just so long as we have a concise statement on the
> expected behavior for all of our users.
>
>
>>
>> On Fri, Jan 25, 2013 at 6:40 PM, Paul Davis <paul.joseph.da...@gmail.com
>> >wrote:
>>
>> > I preface this with the fact that I'm fairly interested in exploring
>> this.
>> > I think Jason's sentiments are right on in that SpiderMonkey has proven
>> to
>> > be a bit of a burden for us to depend on especially from the point of
>> view
>> > of instructing new users on how to satisfy that dependency.
>> >
>> > That said, the biggest hurdles that come to mind:
>> >
>> > How much better is the node.js package story? A random node I just
>> logged
>> > into doesn't have it immediately available. Are there
>> debs/rpms/whatevers
>> > available from the node project?
>> >
>> > I've only semi sorta investigated sandboxing. This I think is going to
>> be
>> > the biggest issue. With spidermonkey we were able to be very specific on
>> > what enters the JS VM's world. With node we're going to be in the
>> "remove
>> > all the things" territory which is always more worrisome. I know there's
>> > some code/module/thing in node for this but I'm under the impression
>> that
>> > its not fully fleshed out. And the example project I saw that used it
>> > spawned a subprocess for every call which is untenable (though that
>> could
>> > be something we change obviously).
>> >
>> > I'm not at all concerned about dropping E4X support but are there any
>> other
>> > issues we'll have to deal with? How about the anonymous function issues
>> we
>> > have with spidermonkey trunk? Not that !node will save us from dealing
>> with
>> > that particular nugget of awesomeness.
>> >
>> > Node has a history of API breakage though it appears to have been
>> > stabilizing in that respect. How much do we have to worry about that
>> these
>> > days?
>> >
>> > When do I get a unicorn?
>> >
>> > Most of those are serious questions.
>> >
>> >
>> > On Fri, Jan 25, 2013 at 5:18 AM, Jason Smith <j...@iriscouch.com> wrote:
>> >
>> > > This whole branch is an experiment. That is the main point.
>> > >
>> > > My **tentative** position is that V8 is a waste of time. We should use
>> > > Node.js, not V8. In other words, we should not change couchjs to link
>> > > against libv8.so instead of libmozjs.so. Instead, we should **remove**
>> > the
>> > > couchjs binary and build a 100% compatible node version. Again, this
>> is
>> > my
>> > > *suspicion* but I want to explore it more.
>> > >
>> > > Embedding V8 is, roughly, the same work as embedding SpiderMonkey. It
>> > does
>> > > not change much. We still depend on an obscure VM with a quirky build
>> > > system.
>> > >
>> > > Maybe we should not embed JavaScript anymore. Maybe we should just
>> depend
>> > > on Node.js being installed. Compare these two statements to a new
>> user:
>> > >
>> > > Option A: "To build CouchDB, you must have the the SpiderMonkey libjs
>> > > library installed, version x.y.z"
>> > > Option B: "To build CouchDB, you must have the V8 libraries installed,
>> > > version x.y.z"
>> > > Option C: "To run CouchDB, you must have Python on your system"
>> > >
>> > > Everybody has Python installed! Yay!
>> > >
>> > > So now, just substitute "Node.js" for "Python" and it is a similar
>> > > situation. IMO in a couple years Node.js will be nearly as ubiquitous.
>> > >
>> > >
>> > > On Fri, Jan 25, 2013 at 11:10 AM, Dirkjan Ochtman <dirk...@ochtman.nl
>> > > >wrote:
>> > >
>> > > > On Fri, Jan 25, 2013 at 12:06 PM, Jason Smith <j...@apache.org>
>> wrote:
>> > > > > This is an experiment just to see how things feel. I want to see
>> how
>> > it
>> > > > > feels to stop saying "CouchDB requires
>> > > > > libjs185/xulrunner/spidermonkey/whatever" and start saying
>> "CouchDB
>> > > > > requires Node.js."
>> > > >
>> > > > What do we need Node.js for, over just v8?
>> > > >
>> > > > Cheers,
>> > > >
>> > > > Dirkjan
>> > > >
>> > >
>> > >
>> > >
>> > > --
>> > > Iris Couch
>> > >
>> >
>>
>>
>>
>> --
>> Iris Couch
>>
>
>
