I like to think of the message as a pure value object. As a result, it can have whatever lifecycle the API user chooses. For me, that's a reason to isolate it from the delivery and tracker, because they do have more tightly defined lifecycles.
If there was a substantial win in convenience, I wouldn't be too bothered to have them combined, but in practice, I don't think it does make a big difference in convenience terms. For me, the separation of concerns is a bigger win. On Wed, Jan 22, 2020 at 6:04 AM Robbie Gemmell <robbie.gemm...@gmail.com> wrote: > 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 > >
