> On Apr 13, 2015, at 9:15 AM, Lankswert, Patrick <patrick.lankswert at > intel.com> wrote: > > David, > >> -----Original Message----- >> From: iotivity-dev-bounces at lists.iotivity.org [mailto:iotivity-dev- >> bounces at lists.iotivity.org] On Behalf Of Warburton, David >> Sent: Monday, April 13, 2015 9:09 AM >> To: Schulhof, Gabriel; Hudson, Douglas >> Cc: iotivity-dev at lists.iotivity.org >> Subject: Re: [dev] node.js bindings: How to distinguish public API from >> private API >> >> 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, > > Did you take a look at node-coap? I wonder how close the two API are? > > Pat
Yes, briefly I looked at this, and WigWagCo has even done an IoTivity implementation for NodeJS based on node-coap, which is here https://github.com/WigWagCo/node-iotivity We chose to wrap the CSDK to eliminate any concerns about compatibility, and in the end I think it was less code to write (the wrapper).
