On 03/03/17 10:04, Fraser Adams wrote:
I think that when Gordon did rhea https://github.com/grs/rhea I got fairly confused about what the direction was going to be
From my perspective, I had a need to provide an AMQP 1.0 javascript library that gave full access to all aspects of the protocol. This needed to be something I could support.
I did not feel the messenger API met my needs. I did actually try out a more event driven API around the empscripten generated engine[1]. In the end though, I decided against that approach also.
One reason was that the emscripten tool was not packaged on any of the platforms I needed to support, and indeed - at that time at least - did not seem even to have actual project releases. I was not keen to assume responsibility for adding this to the build toolchain.
Another reason was that I felt the effort required for the binding would not be significantly less than writing a separate implementation, and would end up being more arcane for support purposes (requiring knowledge of proton-c and emscripten as well as javascript and node).
In short, I felt that my needs would be better met by a simpler, more direct approach independent of proton-c. I did this outside of the Qpid project to avoid more confusion and controversy.
In general, I think choice is a good thing. The choices I made, needn't deter others from different approaches. From a Qpid perspective, the key I think is simply to be clear about the level of support users can expect from any given API or component.
[1] http://qpid.2158936.n2.nabble.com/node-js-api-poc-td7622739.html --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
