> -----Original Message----- > From: Warburton, David > Sent: Monday, April 13, 2015 9:27 AM > To: Lankswert, Patrick > Cc: Schulhof, Gabriel; Hudson, Douglas; iotivity-dev at lists.iotivity.org > Subject: Re: [dev] node.js bindings: How to distinguish public API from > private API > > > > 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).
Cool. -------------- 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/b277f484/attachment.p7s>
