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. > > > 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. > > > 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 > >
