Hi Rafael,
Many thanks for that.
I've been thinking that it was getting close to a good time to get it
off the branch and into the main code base, so you've beaten me to it.
I've actually made a bunch of improvements recently, but I was in the
middle of some fairly subtle bug fixes that were caused by some quirks
of the ws WebSocket library when Proton moved from subversion to git, so
things rather built up a bit on my local copy whilst I procrastinated
over my move to git :-) .
You doing this gave me a much needed nudge and I've just got myself set
up to use git for Proton.
This morning I've migrated all of my latest updates into git (see
https://issues.apache.org/jira/browse/PROTON-760). I had a look in
https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=39cd8c5 and
it *looks* like my first git commit went OK =-O
One of the improvements I've added is JavaScript ports of msgr-send and
msgr-recv, which I added so I could do soak/performance tests, they work
more or less like the C/Python versions, that is to say:
./msgr-recv.js -c 100
./msgr-send.js -c 100 -b 64
would push one million 64 octet messages.
There are a couple of features missing from the tests, but they are more
or less there.
It's probably a good time to remind people who might be reading this
that one quirk of the JavaScript binding is that the network transport
is WebSocket based *not* TCP sockets. This means that it won't "just
work" with qpidd, the Java broker or the proton-c examples.
I've provided a simple WebSocket->TCP proxy though and it also works
fine with the Java Broker's WebSocket transport. I've mentioned this in
the README, but people don't always read those.
https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;a=blob;f=proton-c/bindings/javascript/README
It's on my TODO list to get emscripten's network library working with
the Node.js net module and chrome packaged apps so that it'll be
possible to use native TCP sockets where available, but I've just not
had the time yet.
I've included a JavaScript port of qpid-config for fun to illustrate how
to do some slightly fancier asynchronous request/response stuff, it's
actually a pretty complete port of qpid-config and it also works with
the Java Broker if you install the QMF plugin that I wrote for that (OK,
so I am a little bit OCD).
The JavaScript binding is fairly well documented and you can generate
jsdoc HTML docs via:
make docs
So far I've tried it out on Node.js and Firefox, but it should work on
any modern(ish) browser that supports binary WebSockets and ArrayBuffers.
Browser performance varies *a lot* I was originally trying it on FF 24
and I was a bit disappointed by the performance compared to Node.js but
I upgraded my laptop the other week and I'm now running FF 33 which
*totally rocks* the reason that FF 33 runs so well is that emscripten
(the C->JavaScript compiler I used) generates asm.js, see
http://asmjs.org/ and recent versions of FireFox are optimised for
asm.js and can do neat things such as ahead of time compilation.
As a heads up the JavaScript binding generates a node module called
qpid-proton containing a library called proton.js, I'm likely to change
that fairly soon to something like qpid-proton-messenger and
qpid-proton-messenger.js the reason for that is that it is really a
Messenger binding and with all the recent talk on the forums about
alternative reactive APIs based on Proton Engine that ought to be a
direction I should start looking into.
Hopefully this is useful to people, it's been something of a labour of
love over the last year.
Cheers,
Frase
On 28/11/14 16:18, Rafael Schloming wrote:
Hi Everyone,
I managed to take advantage of a bit of my thanksgiving downtime to give
fadams' javascript branch some attention. I'm happy to report that thanks
mostly to his excellent work, it was fairly straightforward to bring his
branch up to date with respect to trunk. I've done this and pushed the
result to a new branch called 'javascript'. I then added the javascript
tests to the main build and merged the javascript branch into trunk.
Most of you probably won't notice a difference since it is fairly self
contained and won't build without emscripten, but I would highly encourage
you to check it out. There is a little bit of a manual process to get
emscripten installed, but it is well documented and straightforward, and
once you've done that, it all seems to work quite smoothly.
As always, please let me know if I broke anything.
--Rafael
