Hi Gabriel, Last week Doug Hudson and I threw together a NodeJS wrapper for IoTivity to take to the 1st build hackathon last weekend, you can check it out here: https://github.com/dwarburt/iotivity_wrapper
Instead of trying to expose the IoTivity functions one-to-one to NodeJS we took the approach of wrapping the csdk and making a new Api for node. My idea was to eventually have an API for IoTivity that works like connect/express with a request callback middleware chain like they have, but this is not likely to materialize any time soon. Now that the hackathon is over, it?s back to regularly scheduled work for me and I won?t have much time to contribute code. In our iotivity_wrapper we took the approach of requiring the user to have IoTivity installed and built already before running the npm install. Like you said, this is against the npm way and having the npm install download and build IoTivity is better. I?d like to see what you?ve done in that respect. Have you got it somewhere it can be shared? I can?t answer your question directly about which APIs are public and which are internal, but I think that if you move towards the direction we took, choosing what functionality you want to have at the NodeJS layer and exposing it with a C wrapper, then it?s a less relevant question, or at least it?s not a question that is going to block you until you have the answer.? Cheers, David > On Apr 10, 2015, at 11:33 AM, Schulhof, Gabriel <gabriel.schulhof at > intel.com> wrote: > > Hi! > > I am making progress on my node.js bindings for iotivity: > > - I'm downloading the 0.9.0 C API using bower. This means I'm grabbing > the followings: > - resource/csdk > - resource/oc_logger/c > - resource/oc_logger/include > - extlibs/cjson > - I'm building it using node-gyp and linking it statically to the C++ > files containing the bindings > > I've separately cloned the iotivity repo and doxygenerated the C API > from master. I'm going through it, binding one function at a time, > manually for now, though I have some plans to look at node-libclang > for parsing the headers. > > I've run into an unexpected hurdle though: It seems some of the > functions included in the generated API documentation are actually > internal functions. For example, CreateNewOptionNode() is marked as > internal in the header file: > ``` > // Internal function to create an option node for coap pdu > ``` > > Unless I've failed to notice an existing way of distinguishing what is > public from what is private I guess it would be real nice like if > public API could be wrapped in macros like IOTIVITY_EXTERN() or > something. > > So, how do I distinguish the public API from the internal functions? > > Another confusing issue: > > Both resource/csdk and resource/csdk/connectivity/lib claim to contain > libcoap-4.1.1, yet the code inside the two libcoap-4.1.1 > subdirectories differs. This makes it kinda hard to compile it all > into one big fat static library, so I've skipped the connectivity > stuff for now. > > Please let me know, and thanks for all your help so far, > > > > Gabriel > _______________________________________________ > iotivity-dev mailing list > iotivity-dev at lists.iotivity.org > https://lists.iotivity.org/mailman/listinfo/iotivity-dev
