So... a few initial thoughts / queries from a brief look through. I'll try to do a more detailed review later
1. I don't see any mechanism for connection retry / alternate hosts in the connect operation / connection-options parameter ; further I presume there is no mechanism for attempted automated failover on connection error - is this something that would be in a later scope? 2. In connection options i) it seems weird for virtual-host to be thought of as part of "identity" when it is really an instruction about the remote server ii) The modelling of SASL is very tied to the "username/password" model. Identity defines a "user" property - what does this represent if not part of the SASL exchange? In the SASL section there is password section - which only applies to traditional username/password mechanisms. From a protocol point of view the client gets to choose from the mechanisms offered by the server, and the form of the credentials for each mechanism may differ. For maximum flexibility I would think we would want something like a credentials "bag", and an ordered list of mechanisms. Each mechanism would define what properties it needs to retrieve from the credentials bag (e.g. an oauth token, or maybe a tls-client-certificate). iii) The tls options seem inadequate - how would the client express that it wanted to send a particular client certificate, for instance, also which certificates to trust (individual certs or CAs), CRLs, etc... iv) Given the very directional notion of TCP connections / SASL - I'm not sure the same data structure should/can be used for both establishing outgoing connections and incoming connections. TLS (at least) would be expected to treat "client" and "server" in the same sense as the TCP connection I assume. Would the same also be true of SASL? 3. I don't see a provision for using protocols other than AMQP directly over TCP (e.g. how about websockets?) 4. After connection establishment, does the connection provide a way of accessing information that was exchanged at the TLS or SASL layers 5. In the connection object we have properties, offered-capabilities and desired-capabilities - are these referring to the values that were sent by the client to the remote container or the values sent by the remote to the client? (Given the default value is "discovered I presume these are supposed to be the values sent from the remote side, in which case the description "Extensions the endpoint can use" is incorrect - they are capabilities the remote side would like to use. Similarly the virtual-host and container-id - are these representing the virtual-host the remote container desires to attach to, and the container-id by which the remote side identifies itself? 6. receiver-options - "auto-accept : Automatically accept deliveries that are not explicitly acknowledged"... what does this mean - when does the accept happen, when the message is initially received, or only if the delivery somehow goes out of scope? 7. receiver-options - how do auto-settle and delivery-mode interact? 8. There appears to be no way in delivery.reject to provide additional information. There also does not seem to be a way of setting the modified outcome. Also, is there a way for the client to be informed where the remote side has spontaneously set the outcome? The messaging handler only seems to allow for being informed of outcome changes for sent messages (via trackers) not received messages. -- Rob On Mon, 13 Jan 2020 at 13: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. >
