Hello, We (Murex) are very excited about this new imperative API project. We are using proton C++ on the client side for some years now and we experienced the difficulties this model has, as Justin described in his first mail. On our side, we began implementing the new API in the C++ language and we will share it with you as soon as we have something presentable.
I would like to thank all the contributors for there efforts on this project. Best regards, Rabih On Mon, Jan 13, 2020 at 1:40 PM Justin Ross <justin.r...@gmail.com> wrote: > Hi, everyone. For a while now, some members of the Qpid community have > been working on a new style of messaging API. It now has a reasonable > shape, and we want to share it and get your feedback. > > We currently offer either JMS or Proton's reactive API. These certainly > aren't going anywhere - they're important - but for some use cases, the > absence of a high-level command-oriented API for AMQP messaging is a source > of inconvenience. > > This inconvenience comes in two forms. First, JMS is helpfully imperative > (in part - it contains multitudes), but it doesn't expose some of the > things you can do with AMQP. And it can't reasonably expose those things, > because that would break the contract of the JMS API. Second, the Proton > APIs, since they are reactive, make it harder to handle cases where you > need to sequence the processing of events. > > The imperative client API we are talking about here uses modern language > support for futures or coroutines. Most of the API's operation is > asynchronous, but you can easily introduce blocking where you need to. > > It's a client API only. We think a comparably high-level server API would > be its own dedicated thing, functioning more like Python Flask or JAX-RS. > In any case, the Proton reactive API is already a good fit for writing > servers. > > We have the outline of the API and some proof-of-concept implementations, > but much remains to be done. We anticipate that this work will ultimately > become a sub-module of Proton, such as proton/client. > > The API spec: > http://www.ssorj.net/pumpjack/client/index.html > > I've worked on the Python prototypes, so I'll share them here. I did these > some time ago, so they need updating for the latest API spec changes, but > they serve to show how the API can use futures or coroutines. (For Python, > coroutines are the preferred approach.) > > Python prototype (future-based): > https://github.com/ssorj/gambit/blob/futures/python/demo.py > https://github.com/ssorj/gambit/blob/futures/python/gambit.py > > Python prototype (coroutine-based): > https://github.com/ssorj/gambit/blob/asyncio2/python/demo.py > https://github.com/ssorj/gambit/blob/asyncio2/python/gambit.py > > Some of the other folks who have done exploratory work will follow up on > this thread to show what they've done. > > Some caveats: this is in early stages, and the API will change as we > discuss it more. There are also big outstanding pieces to look at, such as > reconnect and failover, to name just one. > > Thanks for your time, and please let us know what you think. >
