fadams wrote > What do you think of the approach that I've taken? My rationale for > compiling proton-c to JavaScript and using a thin (ish) binding layer > rather than doing a ground-up "native" JavaScript rewrite was primarily > about support. I figured that there was a lot of effort being put into > maintaining proton-c and that was what might be considered the > "canonical" or reference implementation, so tracking improvements would > end up being a pain with a separate code-base, whereas the binding to a > compiled library just needs to cover the public API and ultimately I > should pick up improvements to the core code "transparently". If you > look at what I've done you'll hopefully see a startling similarity with > the SWIG bindings particularly the Python one.
Hi Fraser, For the first version of our Node.js client, we ended up writing our light C++ module to access the bits of proton-c that we needed and bridge to Javascript. At the time I wasn't aware of your javascript branch, else we would have looked at using that first. However, I did recently also notice that SWIG-3.0.1 has now added a Javascript module for generating Node.js and Javascript bindings in the same way as is currently done for Python, Ruby etc. I wonder how that would compare to your emscripten approach? http://www.swig.org/Release/RELEASENOTES Cheers, Dom -- View this message in context: http://qpid.2158936.n2.nabble.com/proton-javascript-binding-problem-question-tp7612394p7613505.html Sent from the Apache Qpid Proton mailing list archive at Nabble.com.