Hi Justin, Thanks for sharing the results of you work on a new API.
I briefly looked through the suggested design and POC and the following questions sprang into my mind: * the suggest API does not have any notion of transactions yet. I suppose it is still work in progress and transaction support will be added later. Do you plan to add transaction support? * the suggested API defines a message class which can be instantiated by calling constructor and passing a body. I assume that passing List/Map/Dictionary/bytes would result in creation of corresponding body section suitable for the type. I assume custom message body types will not be supported by the API. Otherwise, some body decoder/encoder would need to be provided via API. * the message settling is delegated to Tracker class in case of sender and Delivery class in case of receiver. I suppose it is done to encapsulate delivery state, tag and id. Why settling functionality cannot be implemented on a message class? That might make API simpler and eliminate the need for Tracker and Delivery classes... * Would it be possible to specify the message settling modes (for sender and receiver) via suggested API? * What about receiver credit management? How session and receiver credits can be specified by the end user? Kind Regards, Alex On Mon, 13 Jan 2020 at 12:40, 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. >
