Atom Shell's "node library".

[Kevin Ingwersen]

Now, there it is.

Atom Shell was open sourced a while ago and I roamed around in its code. Apearently it directly targets a node_lib target within node.gyp. I have not checked the current version of Node’s gyp file, but I think now its actually time to offer an embedding API. Why? Because even Atom had to hack its way around…

Currently, nodejs does not offer access to node::Environment by default, which holds a variety of objects. It also has no option of directly setting up an environment, by passing a v8::Context, or just a v8::Object.

What I would suggest:
- A header called like: node_embed.h
- It should define a small set of functions that:
- Add a nodejs environment to a v8::Object or v8::Scope
- Provide version information
- That do NOT include v8, for the case that somebody already selected a v8 header of their choice.
- Nodejs module structures must be forced to be added. Flags like -all_load and —whole-archive are easily to forget. But due to the current structure, modules are not always linked in by the linker, due to them not having a strong reference from anywhere. A test build without either of the flags resulted in only four of all modules ot be added inside.
- A short info on how the javascript in lib/*.js is converted in a nodejs friendly header.

It would help other applications that intend to use nodejs for other tasks and to add purpose-specific nodejs extensions.

Kind regards, Ingwie.

[Cheng Zhao]

I tried to merge one of our patches to upstream, but it seems that node is not ready for embedding interface yet: https://github.com/joyent/node/pull/6744#issuecomment-31033455.

Cheng

On Thu, May 8, 2014 at 4:36 AM, Kevin Ingwersen <ingwi...@googlemail.com> wrote:

Now, there it is.

Atom Shell was open sourced a while ago and I roamed around in its code. Apearently it directly targets a node_lib target within node.gyp. I have not checked the current version of Node's gyp file, but I think now its actually time to offer an embedding API. Why? Because even Atom had to hack its way around...

Currently, nodejs does not offer access to node::Environment by default, which holds a variety of objects. It also has no option of directly setting up an environment, by passing a v8::Context, or just a v8::Object.

What I would suggest:
        - A header called like: node_embed.h
        - It should define a small set of functions that:
                - Add a nodejs environment to a v8::Object or v8::Scope
                - Provide version information
                - That do NOT include v8, for the case that somebody already selected a v8 header of their choice.

        - Nodejs module structures must be forced to be added. Flags like -all_load and --whole-archive are easily to forget. But due to the current structure, modules are not always linked in by the linker, due to them not having a strong reference from anywhere. A test build without either of the flags resulted in only four of all modules ot be added inside.

        - A short info on how the javascript in lib/*.js is converted in a nodejs friendly header.

It would help other applications that intend to use nodejs for other tasks and to add purpose-specific nodejs extensions.

Kind regards, Ingwie.

--
Job board: http://jobs.nodejs.org/
New group rules: https://gist.github.com/othiym23/9886289#file-moderation-policy-md
Old group rules: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
---
You received this message because you are subscribed to the Google Groups "nodejs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to nodejs+un...@googlegroups.com.
To post to this group, send email to nod...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/nodejs/D8EFEA78-C2BA-4E0D-97A0-0E14327C11DA%40googlemail.com.
For more options, visit https://groups.google.com/d/optout.

[Tomasz Janczuk]

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. 

Thanks,

Tomasz Janczuk

[Aria Stewart]

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.