+2 :-) > -----Original Message----- > From: Ted Ross [mailto:tr...@redhat.com] > Sent: Tuesday, November 19, 2013 3:38 PM > To: users@qpid.apache.org > Subject: Re: Proof of Concept JavaScript Proton implementation. > > +1 > > I'd be very interested in seeing this checked in on a branch. > > -Ted > > On 11/19/2013 03:33 PM, Robbie Gemmell wrote: > > I think its worth mentioning that branches are ideally suited to this > > sort of work....whether it actually ends up on trunk or not in the > > end, theres no need to keep things local until it is actually ready > > for landing on trunk... > > > > Robbie > > > > On 19 November 2013 19:56, Fraser Adams > <fraser.ad...@blueyonder.co.uk>wrote: > > > >> Hey all, > >> For the last couple of weekends I've been working on a Proof of > >> Concept JavaScript implementation of Proton. > >> > >> The approach that I've taken is (I think) quite interesting/unusual > >> but it's an approach that offers a high level of synergy with > >> implementations for other languages that are essentially bindings to > proton-c. > >> > >> The "magic elixir" in this is the downright amazing emscripten > >> https://github.com/kripken/emscripten/wiki which (believe it or not) > >> is essentially a cross-compiler that can compile C/C++ to JavaScript. > >> Moreover the JavaScript that it compiles to is a particular subset > >> called asm.js http://asmjs.org/ which can be extremely aggressively > >> optimised and is subject to a lot of research by Mozilla in > >> particular (the main emscripten maintainer is actually a Mozilla > >> researcher, though I believe emscripten is something of a side project). > >> > >> It's well worth visiting the emscripten page with a modern browser, > >> the Epic Citadel demo is awesome :-) > >> > >> So in a nutshell what I've done is to compile proton-c into > >> JavaScript > >> > >> So I'm underselling it a bit :-) I had to do a fair bit of work to > >> make it that simple, in particular I had to add/fix a number of > >> emscripten's library functions (Proton used a few things that weren't > >> implemented) but the cool thing is that those are now in emscripten for > everyone's benefit. > >> > >> A really nice thing is that I've not actually had to modify any of > >> the engine/messenger code at all - one I started to figure out what I > >> was doing wrong that is :-) all I've really needed to to was to > >> modify send.c/recv.c so that they behave in a non-blocking manner > >> (you may have seen my mail at the weekend before I finally figured it > >> out :-)) > >> > >> I've got CMake able to cross-compile in a repeatable fashion so the > >> only change to any existing Proton stuff that is required is an > >> addition to the top-level CMakeLists.txt that detects the presence of > >> emscripten and its dependencies and if present fires off > "add_subdirectory(bindings/javascript)" > >> e.g. > >> > >> > >> # Build the JavaScript language binding. > >> # This is somewhat different to the other language bindings in that > >> it does not use swig. It uses a C/C++ to # JavaScript cross-compiler > >> called emscripten (https://github.com/kripken/ emscripten). > >> Emscripten takes C/C++ # and "compiles" it into a highly optimisable > >> subset of JavaScript called asm.js (http://asmjs.org/) that can # be > >> aggressively optimised and run at near-native speed (usually between > >> 1.5 to 10 times slower than native C/C++). > >> option("BUILD_JAVASCRIPT" "Build JavaScript language binding" ON) if > >> (BUILD_JAVASCRIPT) > >> # First check that Node.js is installed as that is needed by emscripten. > >> find_program(NODE node) > >> if (NOT NODE) > >> message(STATUS "Node.js (http://nodejs.org) is not installed: > >> can't build JavaScript binding") > >> else (NOT NODE) > >> # Check that the emscripten C/C++ to JavaScript cross-compiler > >> is installed. > >> find_program(EMCC emcc) > >> if (NOT EMCC) > >> message(STATUS "Emscripten > >> (https://github.com/kripken/emscripten) > >> is not installed: can't build JavaScript binding") > >> else (NOT EMCC) > >> add_subdirectory(bindings/javascript) > >> endif (NOT EMCC) > >> endif (NOT NODE) > >> endif (BUILD_JAVASCRIPT) > >> > >> > >> So the main purpose of this mail is to give a heads up of it and to > >> ask if it'd be OK to start commiting it and give others some visibility of > >> it. > >> > >> At this stage it's something of a Proof of Concept, in particular: > >> * I haven't exported any actual JavaScript bindings so although it's > >> JavaScript actual JavaScript clients would find it awkward to call > >> the API as yet. > >> * As alluded above and at the weekend the demo code I've got calling > >> messenger isn't especially elegant, I think I know how to get things > >> behaving more asynchronously, but haven't tried it yet (and my hunch > >> may be wrong). > >> * Transport is entirely over WebSockets :-) so I've actually got send > >> and recv running on Node.js (and also send on a browser) but it'd be > >> useful to have them communicate via TCP sockets too - though that'd > need a proxy. > >> * I still (perhaps amusingly given this) don't know that much about > >> Proton, so I've only really got send and recv to play with I'm not > >> really sure where there may be other messenger examples to exercise > >> it a bit better (in particular message type interoperability would be good > to test). > >> I'd be grateful for pointers - is the object.c test the best place to > >> look for this? And I couldn't see any tests for the "tracker" > >> capabilities?? > >> * In case it wasn't clear from the WebSockets it'll only work in a > >> relatively modern browser at the moment both for the WebSocket stuff > >> and for the fact that it relies on ArrayBuffers (though there's an > >> emscripten compile option to allow the use of native JavaScript > >> Arrays instead) > >> > >> > >> Finally it's probably worth pointing out some pros and cons for this > >> approach to creating a JavaScript Proton > >> Pro: > >> * It's using the existing proton-c code base with the posix driver.c > >> completely unchanged (with the simple test I've done to date) so from > >> a broad maintenance/"Total cost of Ownership" perspective it means > >> essentially very little extra maintenance costs. > >> * It follows the same "pattern" as Python/Perl/PHP/Ruby/Java JNI > >> albeit it's cross-compiled rather than a pure binding. > >> * It should be somewhat faster than "handwritten" JavaScript. This > >> might seem counter-intuitive but it's worth looking at the > >> emscripten/asm.js documentation. From my own experience I've ported > >> zlib to JavaScript for another project I'm working on and inflate was > >> *significantly* faster than the literal port of tinflate that I had > >> previously used - and that was on a relatively old Firefox without asm.js > optimisations. > >> > >> Con: > >> * The compiled code is likely to be somewhat larger than hand written > >> JavaScript. I haven't done an optimised & minified build yet so I > >> can't say for sure how big it will actually be. The unoptimised > >> send.js/recv.js are 1.5MB each so at a guess they'll probably come > >> out at arounf the ~500K mark (though they should also gzip quite well). > >> * The compiled code isn't necessarily hugely readable. It's "OK" when > >> not optimised but.... (to be fair I used it to figure out how to get > >> the missing library calls working so it's not *totally* impenetrable > >> :-)) > >> > >> > >> I hope that this is something that'll be useful/interesting please do > >> let me know if you're all happy for me to get it kicked off into the > >> Proton code base. > >> > >> Best regards, > >> Frase > >> > >> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For > >> additional commands, e-mail: users-h...@qpid.apache.org > >> > >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional > commands, e-mail: users-h...@qpid.apache.org
--------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
