On Wed, 22 Jan 2020 at 09:39, Rob Godfrey <rob.j.godf...@gmail.com> wrote: > > On Tue, 21 Jan 2020 at 18:31, Robbie Gemmell <robbie.gemm...@gmail.com> > wrote: > > > On Tue, 21 Jan 2020 at 17:06, Rob Godfrey <rob.j.godf...@gmail.com> wrote: > > > > > > On Tue, 21 Jan 2020 at 16:38, Robbie Gemmell <robbie.gemm...@gmail.com> > > > wrote: > > > > > > > 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: > > > > > > > > > > > > > > > > > > [... snip ...] > > > > > > > > > > > > > > > > > > > 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. > > > > > > > > > > > How do you get from the delivery to the message? > > > > > > > In one case at least, currently delivery.message() > > > > Looping back to Alex's question then - does the separation of delivery and > message actually save us anything in terms of being "lightweight" then, if > the delivery always needs to refer to the message?
Not as it currently works but that wouldnt be hard to address, e.g saying reading the message from the delivery clears it going forward, which is actually what we do in existing separation of delivery and message bits elsewhere (though at a byte payload level). > I'm not intrinsically > against the separation, though in some ways it feels a bit odd to have > different object types for tracking inbound and outbound deliveries (the > tracker and delivery classes), but using a single type for both inbound and > outbound messages > > -- Rob > I actually suggested the same 'receive message' thing myself at points in discussion previously, so I'm not entirely against that either. Having the delivery there perhaps provides a nice split point to handle some more advanced cases though. One thing it does do is that using the message doesnt really impact the potentially-ongoing delivery handling (even though its retrieved from there), while combining them would mean it is tied start to finish and so threading and usage considerations could become more of an issue, e.g we might need to prevent that message being sent. One thing to perhaps note more clearly is that unlike the existing reactive APIs an intent here is to allow application thread usage of the clients APIs directly without needing to ensure use of the appropriate client thread(s). The message stuff as a whole has not yet been given all that much consideration. I wouldnt say it was settled there is only a single message type for example. I did mention potential for multiple message types in my reply to Alex, though I was admittedly meaning in a given direction at the time. > > > > > > With the recevier.receive call... I'm not sure how the second half of the > > > description "auto-accept : Automatically accept deliveries that are not > > > explicitly acknowledged" makes any sense. I don't see how "explicitly > > > ackowledg[ing]" is even possible. > > > > > > > It isnt, calling receive with auto-accept would be expected to > > acknowledge immediately at present (unless some other behaviour were > > defined). The latter bit can only apply to the handler style usage. > > > > The text is loosely covering the bases, and was perhaps even copied > > from previous reactive api bits where auto-accept is an option and no > > receive style use is possible. > > > > > -- Rob > > > > > > > > > > > > > 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. > > > > > > > > > > > > --------------------------------------------------------------------- > > 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
