On Tue, 21 Jan 2020 at 14:28, Rob Godfrey <rob.j.godf...@gmail.com> wrote: > > On Tue, 21 Jan 2020 at 14:24, Robbie Gemmell <robbie.gemm...@gmail.com> > wrote: > > > On Tue, 21 Jan 2020 at 11:21, Rob Godfrey <rob.j.godf...@gmail.com> wrote: > > > > > > 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? > > > > Areas still to look at, as Justin said towards the end of his mail > > this is early stuff and he specifically noted these bits as examples > > of outstanding areas. > > > > fair - I'd bookmarked this as something to "review when I have 15 minutes > of spare time" - I didn't go back and check the other context in the mail > :-) > > > > > > > 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 > > > > Fair. I wouldnt read much into the grouping names on the page though, > > its the only place it occurs quite like that. > > > > The other part to this is the various place that "host" can be provided - > SNI, Sasl and connection.open - not sure exactly how we want to open up all > those parts > > > > > > > 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). > > > > I dont think having user/pass options for the basic simple case, still > > widely used, like all our existing clients do would prevent having > > other stuff for additional cases. > > > > > Yeah - it's more we shouldn't bake this as the *only* way. A simplified > API for just username/password is fine, but I think the general case is > "bag of *stuff* for credentials" > > > > > 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... > > > > I think that mainly a case of the page being incomplete, partly as we > > hadnt got there yet, and it being based on and relating to existing > > bits, e.g the C++ client it refers to, that such bits would likely > > build on existing bits. > > > > I'm sort of seeing this as an opportunity to think how things should work > rather than solely being based on what's there already (which I believe has > gaps) :-) > > > > > > Certain code allows for configuring various such things via a set of > > connection ssl options currently. > > > > > 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? > > > > This is only to be client related. > > > > OK - I was going by the (obviously very sketchy) container.listen which > also takes a connection-options parameter. I think it needs to be clear at > the outset if we are looking at a API which aims to over both the connect / > accept case or just connect. >
This is client/connect based. I think that bit is just previous content describing the existing reactive 'container' bits, which in some impl cases this might be built upon or beside (while in others it doesnt/wont exist). > > > > > > 3. I don't see a provision for using protocols other than AMQP directly > > > over TCP (e.g. how about websockets?) > > > > Early stuff, still stuff to consider. Certain code does allow for > > using websockets via a set of connection transport options currently. > > > > Really just checking that this is in scope. > > > > > > > 4. After connection establishment, does the connection provide a way of > > > accessing information that was exchanged at the TLS or SASL layers > > > > Not yet, as many of the existing clients dont, and as ever just havent > > got to lots of things yet. > > > > > 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? > > > > The clients values are handled via the options given at connect, the > > ones on the connection are those recieved from the peer. > > > > OK - so the description should be changed there then (I'd be tempted to > actually make clear through the names that these are remote-* rather than > local or implicitly agreed values) > > > > > > > 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? > > > > For receive calls it would be when received. > > > If there was a listener > > (TBD) it would be after that returned. Much the same as existing > > clients auto ack essentially. > > > > So... looking through the API design... the only way I see to receive a > message is through messaging-handler.on-message. So the idea is the > auto-accept means that upon the return from on-message, if the outcome has > not been set to accepted, and the message has not already been settled (by > either side) then the outcome of the delivery will be set to accepted. > There are recieve calls on the reciever, see the bottom of https://www.ssorj.net/pumpjack/client/receiver/index.html. The messaging-handler stuff is again mostly part of the existing reactive bits (in some cases), which indeed work essentially as you describe. The idea would be something similar (but obviously narrower in operation scope) for the handler configurable in the reciever options. > > > > > > 7. receiver-options - how do auto-settle and delivery-mode interact? > > > > That auto-settle shouldnt be on reciever options, only senders. > > > > > 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. > > > > Page doesnt, not yet complete, but certain code does already allow for > > doing both things. > > > > > 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. > > > > Not as yet, areas still to consider, but certain code does allow at > > least inspecting it currently. > > > > > > > > -- Rob > > > > -- 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. > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org > > For additional commands, e-mail: users-h...@qpid.apache.org > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
