So there would finally be an asynchronous API, which would use async/await (Python 3.5+?) ?
Ivan On Mon, Jan 13, 2020 at 2:40 PM Justin Ross <[email protected]> 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. >
