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 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 7198 bytes Desc: not available URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20150413/143394f6/attachment.p7s>
