On Tue, Jan 27, 2015 at 4:03 PM, Gordon Sim <[email protected]> wrote: > 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). >
+1 I think the reactive API is actually quite a natural fit for javascript as pretty much everything else in javascript works that way already. This is one of the reasons I have been working on building out a proper reactor in C. I believe that whether via swig or via emscripten, the C reactor will provide a very nice option for using proton from javascript. --Rafael
