On May 8, 02014, at 0:08, Tomasz Janczuk <[email protected]> wrote:
> I am fully supportive of officially enabling the scenario of hosting Node.js > in other processes. There is a hole slew of applications that would be > enabled by the ability to embed and script Node.js. > > Based on my experience building Edge.js (http://tjanczuk.github.io/edge) I > think many of these scenarios can be easily enabled with a change to node.js > that is much smaller in scope to the one proposed above. Enabling scripting > Node.js within .NET applications > (https://twitter.com/tjanczuk/status/464117898630295552) in Edge.js required > the following: > > 1. Compiling node.js to a shared library rather than executable (one line > change in node's node.gyp). > 2. Loading the node shared library into a .NET executable. > 3. Invoking the node::Start entry point manually and providing JavaScript > bootstrapping code to be executed on entry. > 4. The bootstrapping code turns around and loads a native extension of > Node.js. At this point we have the primary .NET application code (CLR), > Node.js runtime (V8) and the native Node.js extension running within a single > process. > 5. The native Node.js extension provides the programming model and behavior > for interoperability between Node.js and the hosting application, which is a > moral equivalent of domain specific embedding APIs. > > Out of the list above, only step #1 required "hacking", the rest was > naturally enabled by having a shared node.js library. > > Consequently, the minimal change to Node.js that would enable embedding is to > have a supported build of Node.js as a shared library. This is almost exactly what I discovered as well — most of the heavier lifting can be done as a normal node module, and only the compiling as a shared library was needed to get things rolling.
signature.asc
Description: Message signed with OpenPGP using GPGMail
