Re: proton javascript binding problem/question

[Dominic Evans <do...@uk.ibm.com>]

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.

Re: proton javascript binding problem/question

[Fraser Adams <fr...@blueyonder.co.uk>]

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