On Wed, 2017-06-21 at 20:50 +0200, Rick van Rein wrote: > Hello, > > I have been exploring options of using AMQP in connection with various > languages. I strongly prefer 1.0 because it can allow cross-domain > messaging, so users could push MIME-typed content after passing > authentication & authorisation. > > Proton C seems to hold good cards in terms of language support. But to > me, Erlang is a great amiss in the list. Are people still working on > its integration? > > This is not a pet language (I hope). Erlang offers a platform for > building rock-solid solutions, which has always had a clear niche of > applications. These rock-solid solutions are clear casses to benefit > from AMQP. > > I'm wondering if we'll have to go for < 1.0 by adopting RabbitMQ as that > is integrated with many more languages, especially with Erlang of course > (it's written in it). Or whether to believe that Qpid has the advantage > of the newcomer that can jump ahead. The thing is... > > 1. Qpid Dispatch Router is an attractive and novel use of 1.0 > 2. RabbitMQ could serve as a gateway 1.0 server but AFAIK not in the > role of a 1.0 client to Qpid Dispatch Router > 3. Java is not acceptable to all who are running a server (and we'd > like to avoid it for that reason) > > ...that it does not seem to be possible to enter the 1.0 World from > Erlang's robustness-supporting platform -- and entering 1.0 is just what > the Qpid aims to support. > > I've had a look at how difficult making the integration would be, of > course. The Erlang side seems doable, given the Port concept to > communicate with C nodes, and the ei interface for sequencing Erlang > binary data. On the Qpid side, the Electron approach matches well with > the Erlang concept of many small processes (as in Go). But I did not > find API specifications on the Qpid side, only examples -- and that's > insufficient to build a translation for anyone but the original designers...
I wrote the electron API for Go, and I'd be happy to discuss it further with you and offer thoughts on API design, but I don't know any Erlang (although I gather Go borrows some ideas from it) I first wrote the qpid.apache.org/proton package which is a very thin layer over the C API - in fact it's mostly code-generated. It is an inversion-of-control API, like the other proton language bindings. Inversion does not suit Go (or Erlang I suspect) so I wrote the qpid.apache.org/electron API to be coroutine-friendly, asynchronous, but "imperative". It aims to stay close to the AMQP protocol concepts (which keeps it fairly close to the other proton APIs) but it introduces some new asynchronous tactics to replace the upside-down event loop. I wrote the qpid.apache.org/proton package while learning Go and following the model of the other bindings, but if I was doing it again I would write electron directly in terms of proton-C - all the Go developer interest is in electron. I think it is worth wrapping the proton-C library, it hides a lot of AMQP complexity. I wouldn't mind writing a pure Go package someday but so far people seem happy with the hybrid. I have a strong interest in extending the "imperative" or "uninverted" API approach to other languages - it is ideal for coroutine languages, but even with traditional threads I think it is much easier to code "moderately concurrent" apps this way. I'm planning to try to migrate some of the ideas to Ruby to solve problems I've had with the inverted approach when integrating AMQP into threaded Ruby applications. > Seeing the earlier attention to this link to Erlang, I would assume that > more people are interested in it being supported, probably following a > similar strand of reasoning as I am above. What can we do to get that > into motion? > I can't write any Erlang but I'd be very happy discuss/review API proposals, donate my experience from Go and Ruby, and give pointers on the C side of things. Once there is some code I can help with getting it set up as part of the Qpid project. Cheers, Alan. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
