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.

Reply via email to