qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gordon Sim <g...@redhat.com>
Subject Re: JavaScript version of Proton?
Date Mon, 06 Mar 2017 15:46:12 GMT
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: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org

View raw message