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.
Regards,
Frase
On 27/01/15 19:07, dnwe wrote:
GitHub user dnwe reopened a pull request:
https://github.com/apache/qpid-proton/pull/5
Initial draft of a node binding via swig 3.x
As an alternative to the emscripten-based javascript bindings, swig 3.x
now has native support for generating node wrappers, so it makes sense to offer
them as a further alternative entry point (alongside the emscripten one) that
is closer to the existing swig bindings for the other languages.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/dnwe/qpid-proton swig-for-nodejs
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/qpid-proton/pull/5.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #5
----
commit 3062005a42337a3fbb2cc727714bc63183ae985d
Author: Dominic Evans <[email protected]>
Date: 2014-12-18T16:38:12Z
Initial draft of a node binding via swig 3.x
----
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at [email protected] or file a JIRA ticket
with INFRA.
---
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
