Hello, I will share our "work in progress" for the C++ implementation even if it is not ready yet: https://github.com/rabih-mourad/qpid-imperative-proton There is plenty of refactoring to do and API alignment to make...
Best regards, Rabih On Mon, Jan 27, 2020 at 4:35 PM Rabih M <[email protected]> wrote: > 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 <[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. >> >
