What is the progress of the Native API？

[jinderek]

I note the last meeting is April 5 and 6 but the last wg-meetings record is 2015-11-19.

Our group is really interested in the Native API. Node/V8 versions change much, so native module developers need to rewrite their code once the Node/v8 apis change. And multi-vms is also a question.

Can I know more about the progress? particularly about Native API.
Thanks very much.

[mhdawson]

This is a timely questions. Over the last 2 days there was a face-to-face in SF where a number of the Node collaborators discussed these issues. There should be a summary/overview posted in the next few days. Once its available I'll post a link to it here.

[mhdawson]

Don't have the summary yet but as an fyi see #16 which is scheduling a meeting of the api WG were we will go over some of the discussions/direction.

[jinderek]

Thanks for the information. I'll follow you up online if your meeting video will be online broadcasting.^_^

[mhdawson]

I've not seen an overall summary yet @jasnell are we still planning one or is the original google doc updated to capture the info that's available ? (https://docs.google.com/document/d/1lTYV31RLQd0Rr8tZUbmH0qy3JRLFwJvAh44uFhffw5c)

The first pass of the eps in the module API plan is now here: nodejs/node-eps#20

[jasnell]

I wrote the initial summary here: https://github.com/nodejs/vm

the next steps documented there are still pending. I've been looking into the node.green project to see if there's something we can use there as far as compliance testing is concerned.

[ianwjhalliday]

We had a WG meeting today discussing progress and are now looking for feedback and interest.
See #22 for a link to the recording of the meeting. Meeting notes to follow soon.

[jinderek]

I've a look at node_jsvmapi.*. Have a question: Every method seems need to have an "napi_env ". What is the consideration for it?
As I know, in JNI env is thread local and JNI methods pointers stores in env. Did node_jsvmapi.h pass napi_env for thread local data (like reference management)?
But I think we can get current_thread() in vm, so we can get thread local data without env. Or we can even use current_thread() to get env.

Another question:) V8 seems to pass Local(Context) in API, like v8.h:2015:

/** JS == */
V8_DEPRECATE_SOON("Use maybe version", bool Equals(Local that) const);
V8_WARN_UNUSED_RESULT Maybe Equals(Local context,
Local that) const;

Or trend to use Local Context instead of Isolate*, like

V8_WARN_UNUSED_RESULT MaybeLocal ToBoolean(
Local context) const;
V8_DEPRECATE_SOON("Use maybe version",
Local ToBoolean(Isolate* isolate) const);

But Chakra core do not. It just uses JsrtContext::GetCurrent(), in jsrt:1684

STDAPI_(JsErrorCode) JsEquals(In JsValueRef object1, In JsValueRef object2, Out bool *result)

So what is the consideration each?

The last question: In node_jsvmapi.cc env is Isolate* now. Why not Local(Context)?

[ianwjhalliday]

@Xuyv we were sure at the beginning that we'd need some context to pass around since we're going for a flat C API. However we haven't figured out yet what exactly it should be. v8::Isolate seemed to make most sense for the v8 implementation, however recently I have been wondering about Context, e.g. getting the current global object, you want to know from which context, not just which isolate.

This is something that needs to be nailed down. I imagine once we start implementing on top of NodeChakra or SpiderNode we'll start to get a better idea about it. I suspect we need both concepts of a runtime instance and a context.

I am definitely open to hearing more thoughts and ideas about this design.

[bnoordhuis]

As long as it is an opaque pointer, it doesn't really matter if it is the isolate, the context, or both - it will be an implementation detail that can be updated without breaking API or ABI.

[mhdawson]

I think this question has been answered. If not please feel free to reopen or open an issue in this repo: https://github.com/nodejs/abi-stable-node/