Making the compiling of native module independent of vm environment about abi-stable-node HOT 5 CLOSED

Thanks @Xuyv - this is an interesting idea. One downside of doing this is that every NAPI call becomes an indirect call, which has perf implications. Can you describe a concrete scenario where the current NAPI approach does not work for you? Note that at Node-Interactive, @aruneshchandra demoed a single NAPI-enabled module, compiled once, and then executed with node v0.10, v0.12, v6, and node-chakracore

from abi-stable-node.

@digitalinfinity I think it has no problem for NAPI module compiling once and then being executed on different versions of node now. The thing that concerns me is that once the api changes( like, add one more function argument in napi_set_return_value) in new NAPI, the old compiled modules will not work.

If function pointers are stored in env, we may control api changes more elegantly and easily. For example, (just an idea)store different functions in env for new versions of NAPI when native module are loaded. And it's opaque to developers.

from abi-stable-node.

Ah, I understand now- so in this world, the add-on would query node for the environment and ask for a particular version of the API, and then proceed to call it? Interesting. In that case, would node need to preserve all the old versions of the APIs, so that the modules could still call this?

One other way this can be solved is, NAPI APIs can never be removed - it's a purely an additive interface- so new APIs being added would not break modules coded against the old API since those APIs would continue to ship. Thoughts? @mhdawson was the plan for the NAPI interface planned to be additive?

from abi-stable-node.

I have also thought that using a function table could make migration easier and have raised it with the overall team in the past. Other platforms like Java use one and it makes it possible to support multiple versions of the API, and have modules request the version that they were compiled against.

The downside as mentioned is the performance overhead due to indirect calls. If we had lots of free cycles I'd have us build with/without a function table and do some performance comparisons but I don't think we'll have the cycles in the short term. We should discuss this one of our upcoming weekly meetings to get more input/discussion so that we can document our decision/rational on this point.

In terms of the specific questions, in general I do see it as being additive. We'll still need some
sort of versioning so that a module can figure out what version its being compiled against so that
it can figure out which function are available.

from abi-stable-node.

This was discussed at several VM summits and we decided to stick to our current approach

from abi-stable-node.