On 01/27/2015 07:38 PM, Fraser Adams wrote:
Hi Dominic,
I guess that my main concern is the potential for confusion :-)
I'm actually a bit curious/confused - when I took a peek at the patch
there wasn't much in there and looked mostly makefile related, I was
aware that swig 3.x had node/JavaScript support but how exactly are the
binding working - i.e what do they *look* like.
With the emscripten stuff the real effort wasn't actually so much about
getting proton-c compiled and usable *as a C API* the actual
send-async.c and recv-async.c were the first things I actually did and
that only took a couple of weekends getting to know emscripten and
Proton, but the main effort was getting a binding that was more
idiomatically JavaScript (I hope I achieved that) - so that included all
the stuff for serialising JavaScript Obects into the AMQP type system etc.
If you look at the emscripten binding stuff that follows a "pattern"
that actually looks pretty close to the Python binding in terms of
trying to provide some higher level abstractions.
Another world of complication was trying to get things working in a
properly async. event driven way.
I couldn't see anything like that in your patch, is that something that
is just TBD, or have I just missed something (entirely possible).
Please don't take this as me being critical - it's not intended to come
across like that - it's just that I put a ton of effort into the
emscripten based approach and I'm fairly keen for there to be (or at
least for there to be an aspiration towards) some consistency.
As you probably know the emscripten binding runs perfectly happily on
Node.js albeit using a WebSocket transport hence scope for confusion.
To be fair the WebSocket restriction is probably the biggest down-side
of the emscripten approach with Node.js and it's on my TODO list. I
guess it'd be good to compare the relative performance - I'd expect the
Swig approach to run faster at present but that might change over time
and the margin may well decrease - V8 hasn't yet implemented the asm.js
optimisations and I noticed a huge performance difference on Firefox
between my old FF24 and my more recent FF35, the latter properly ahead
of time compiles asm.js and the performance seems to be creeping up on
the Python bindings, which clearly are using native code.
I'm sure that the emscripten stuff will always lag behind native and I
personally think the two approaches are complementary rather than
competing, but I'd definitely like to aspire to consistency (hope I'm
not coming over as a bit precious - email isn't great for conveying some
of this stuff).
I'll happily get involved too, I'm a bit distracted on some other stuff
at the mo. and I need to get my head around the Swig stuff so it
probably won't be for a few weeks though.
I agree that while both approaches are likely valuable and can both be
supported, consistency is important. I would like to have in javascript
something similar to the reactive engine api that is available in
python, and have that runnable in node or in a browser without having to
change code for different types of binding (other than at most the
import/require).
I also am busy at present with python, but hope to have some time soon
to take a look at javascript also.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
