> > Unfortunately, just changing the CMakeFiles.txt to
> >          ${PROJECT_SOURCE_DIR}/node_modules/qpid-proton/lib/
> > doesn't work. I get an error since the directory doesn't exist.
> Shame it doesn't work, though I guess not surprising. I'm torn between
> having the trailing slash or not, though you say that with it you get an
> error. Perhaps getting an error is preferable? In your case you had a
> silent issue originally, would an error have helped you track things
> down more quickly?
It probably would have. I would have seen that the build didn't complete 
instead of looking into possible environment problems with NODE_PATH. However, 
once I found the file package.json and saw that it referenced 
"./lib/proton.js", the work-around was clear. However, this isn't really the 
class of problem that you'd normally guard against.

> >
> > When I create the "lib" dir before the build, everything works as expected.
> > The real solution is to create the empty "lib" dir in the Red Hat
> > repository. I'll look into doing that.
> > When I pull the source from the public svn link, everything builds just
> > fine.
> I'm glad that the public svn link works, yay!!
> >
> > Thanks for looking into this.
> > -Ernie Allen
> >
> No probs, it's been my personal little baby for a while now, so it's a
> good thing that others are starting to take a peek. I think that quality
> wise it's pretty decent and pretty well commented and I think that the
> functional behaviour is largely all in place, but I haven't really
> looked at optimisation/profiling yet.
> What do you think of the approach that I've taken? My rationale for
> compiling proton-c to JavaScript and using a thin (ish) binding layer
> rather than doing a ground-up "native" JavaScript rewrite was primarily
> about support. I figured that there was a lot of effort being put into
> maintaining proton-c and that was what might be considered the
> "canonical" or reference implementation, so tracking improvements would
> end up being a pain with a separate code-base, whereas the binding to a
> compiled library just needs to cover the public API and ultimately I
> should pick up improvements to the core code "transparently". If you
> look at what I've done you'll hopefully see a startling similarity with
> the SWIG bindings particularly the Python one. I spent some effort
> contributing to emscripten too, putting things in place so that proton-c
> compiles cleanly (if you look in
> fadams-javascript-binding/bld/proton-c/bindings/javascript/examples you
> will see recv-async.js and send-async.js, which are actually the results
> of directly compiling recv-async.c and send-async.c. Those were the
> first things I got working before I started on the binding stuff - I
> figured that JavaScript programmers probably wouldn't enjoy using a C
> API ;->)
IANAOPS (I am not an official Proton spokesperson) but I personally agree with 
your approach. I doubt there is much of a downside to using a binding as 
opposed to a "native" JavaScript implementation. And the upside is huge, 
especially for bug fixes and enhancements.
> I did a bit of work on the qpid-config port yesterday and it now does
> everything the python one does (well except the xml binding support at
> the moment as that loads a file). I'm currently trying to get it to work
> with the Java Broker (see my Java Broker AMQP 1.0 support - is it by
> default? post to the users list).
You've done some very impressive work here. I'm looking forward to trying it 


Reply via email to