About JS API abstract
magicfish2007 opened this issue · comments
Recently, I am interesting in abstracing JS API, and have some general idea after comparing APIs between v8, jsc, chakra and spidermonkey. Hence, I have some issues about JS API(not include node-api temporarily).
- c OR c++ form?
jsc, chakra and spidermonkey API are all written in C, while v8.h is written in C++. Of cause, C++ maybe more friendly to C++ programme(include add-on developer) , but C would be less consume and more like JNI. - only one type OR many data types
I have see some data types's abstract to review:
(https://github.com/nodejs/api/blob/master/native/data_types.md)
Is this a final design? What about abstract many data types, such as JSObject JSFunction JSNumber ..., as what JNI did? - how to deal with persistent in v8(or global ref in else JS Engine)?
Is there any necessary to define a data type named "GlobalValue" to indicate a persistent data which is rooted? We all know that in JNI, there is no data type like above, so many developer with JNI would confuse about whether this data is local or not. - wrap c++ class
I find that JSC and Spidermonkey provide a API to wrap a c++ class written by developer , and map to a JS object, so that they can new a JS object in JS file, with a C++ construct. For example, in JSC, they define a class with JSClassDefinition, and define a class with JSClassCreate, so they can use it in JS. Should the JS API provide this feature? - argument check
Is there any necessary to provide a argument check just like check_jni.h in Dalvik/art in Android? - InternalField
InternalField in v8 ,external data in chakra or Private in spidermoneky can store a pointer to C++ object for native developer, but this is easy to lead to memory leak(i.e developer forget to release the object binding to a JS object). What can JS API do for this situation?
/cc @ianwjhalliday @stefanmb @mhdawson who are preparing a proposal for a JS native interface.
I'm also preparing a complementary analysis of the actual implemented interface between Node and V8. @magicfish2007 your bullets here are helpful in orienting my thinking, and I'm looking forward to more of your insights.
I plan to post my analysis once it's a bit more mature in either this repo or the nodejs/vm one - they have overlapping goals.
@joshgav thanks for your reply
About JS native APi, one more thing(in fact two more thing):
7. The Call Convention. The convention between API and developer's native code. When I try to implement some JS native interface, I found that a JS code calling a native code have to follow JS engine's Call Convention, so I cann't abstract a common Call Convention unless I make some compromise.
8. What's the relationship between JS native interface with v8.h in v8(or jsrt.h in charkra)? JS native interface is abstract from v8.h or abstract from v8 internal implemt? The former one would be Compatible while the second one would be more efficient.
@magicfish2007 are you interested in collaborating with Stefan/Ian in respect to the work discussed in the last WG meeting (recording/minutes available) ?
@magicfish2007 - eps nodejs/node-eps#20, if you would like to work with Stefan/Ian you can join in on the @node-api irc channel on freenode.
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.
@magicfish2007 please ping me if you would like to be added to the weekly meetings being help on on ABI stable work and/or follow progress in this repo: nodejs/abi-stable-node#2
Going to close issue, please feel free to reopen if more discussion is needed in this specific issue.