Giters

jerryscript-project / iotjs

Platform for Internet of Things with JavaScript http://www.iotjs.net

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

How to improve the way to write external modules

daeyeon opened this issue · comments

commented

We're guiding how to scaffold a native module with the handy tool, iotjs-create-module.py, but it has missing parts regarding how to easily make binding APIs between javascript and native.

So far, our current strategy is for users to directly learn the followings:

  • iot.js APIs
    • apis like iotjs_jhelper_call and macros like JS_GET_ARG.
    • the structure patterns like iotjs_bufferwrap_t .
    • coding patterns such as iotjs_bufferwrap_create and so on for stateful module.
  • jerryscript APIs
  • libuv APIs for asynchronous call

Along with the well-defined C APIs discussed in #1476, I think we need to think about how to reduce such the user's learning curve regarding writing external modules.

  • #1756 can be one of the candidates.
  • Generating a module using Interface Definition Language (IDL) can be an alternative. It's like what browser projects are doing with WebIDL. (It's once suggested during the last jerryscript summit.)
  • Using N-API is also worth considering.

What else could be a candidate? Do you have anything in mind to consider for this matter? Please share your opinion.

commented

In my opinion the first and most important part should be the well-defined C API. We should continue the discussion we started in #1476. I think we should create a iotjs-api.h and module developers must use that header and functions/types which are defined defined in it.

About the module generation. Both solutions sounds good. #1756 is in a good shape is it is definitely worth to merge into the master when it is done. I am too familiar with the N-API and sure how the development is going on. As far as I know Gabriel at Intel is working on it. Module generating from IDL was mentioned by Timothy (from TI). I do not know much about it since then.

If we have to implement one of them from scratch then I vote for the IDL. I think implementing N-API is a much difficult task.

commented

@daeyeon @LaszloLango In my opinion, N-API should be the only answer to write native module for JavaScript engines(v8, jerryscript, duktype). Using N-API means that any developer could use one addon(.node) which could be ran in any engine that supported N-API, and developers could use node-gyp to build addons for any engine, either.

You could take a look at this implementation, ShadowNode(a fork of IoT.js) has completed the 80% N-API, that covers the 80% test suites that pulls from Node.js directly.

commented

Closing since N-API implementations is finished.