On Tue, Jan 27, 2015 at 2:38 PM, Fraser Adams <[email protected] > 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). > At the risk of putting words in dominic's mouth, he indicated on IRC that this part is TBD. My encouragement to bring it in is precisely because it's small, isolated, and very quick to review. In general I think it is harder to keep up with reviews when too much stuff accumulates on a single feature branch. > 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. > FWIW, I'd also like to see consistency between the two bindings. I think we'll always need a pure javascript version for browser support, but I can see why people might like the native option for node, and I want to be able to run the same code in both places unchanged. --Rafael
