On 11/09/14 15:25, Dominic Evans wrote:
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
Hi Dominic,
Yeah I noticed the SWIG thing too recently, though can't recall where -
ISTR it was done as part of Google Summer of Code or something.
I can't say for sure, but my "guess" is that the approach is a bit
different.
At a guess (and I've not really looked at it yet much less played) the
SWIG bindings are about being able to integrate/bind with native C/C++
to JavaScript - pretty much analogous to how similar things work with
say Python/Perl etc. I suspect that the result is that the JavaScript
will only be functional from a node.js environment and not a browser.
With the emscripten based approach I'm essentially cross-compiling (or
transpiling or whatever you might want to call it) to pure JavaScript,
in practice to a subset of JavaScript called asm.js that is optimised
for ahead of time compilation in the execution engine (recent versions
of Firefox and I think V8 have optimisations for asm.js).
There are relative pros and cons to each.
I think using SWIG will be closer to the approach that you've already
taken - though it's not free and it'll need a wrapper somewhat similar
to what I've done in order to make it "friendly" JavaScript. The
advantages are
1 - it'll *probably* perform better because it's a thin wrapper to
native code, though by how much I couldn't say yet, with the most recent
JavaScript engines the margin likely erodes but I'd suspect it'd perform
better whatever.
2 - you are wrapping the C library and you'll be using TCP sockets (The
emscripten version is pure JavaScript and uses WebSockets by default,
though on my TODO list is to look at configurably using the node net
library to use native TCP sockets).
Conversely
The emscripten based approach is pure JavaScript so runs happily in a
browser or node.js. It supports WebSockets and WebRTC (though I've not
tried the latter yet) though not (currently) TCP Sockets (though I've
written a simple WS->TCP proxy that works pretty well).
I've still got a bit of tinkering and tidying up of the emscripten based
JavaScript binding, but I'd quite like to get it moved to proton trunk
before too long. Once it's settled then I'll move on to my TODO list.
FWIW I'm not averse to looking at the SWIG binding too, as I say unless
my interpretation is wrong there are relative pros and cons to each and
I suspect that they are complementary and not competing approaches.
As I say I suspect that the SWIG approach would need Binding code
similar to what I've done with emscripten in order to be any fun to use
and if a complementary SWIG based binding was contemplated I'd really
want to be using the same patterns/API as for the emscripten based one.
I'd hope that this wouldn't end up being a whole duplicate as that would
be a bit tedious, so I'd expect some relatively non-trivial refactoring
to try and have as much shared as possible (take a look at the
binding.js, none of it's necessarily rocket science but there was a lot
of effort in the proton.Data part to try and make things as nicely
idiomatically JavaScript as possible).
What I discovered was that compiling the C to JavaScript using
emscripten was easy and took me a few weekends of hacking, doing all the
binding stuff has taken the best part of a year of spare time (OK not
solid effort, but you get the picture)
Does that answer your question?
Are you the same Dominic Evans who's just filled up my in-box with Jira
messages? I got home from work and opened my emails and OMG!!!! :-D
Cheers, and thanks for taking an interest in the JavaScript bindings.
Frase
