On Mon, Jan 27, 2020 at 7:44 AM Justin Ross <justin.r...@gmail.com> wrote:
> 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. > Big +1 - you don't acknowledge a message, you acknowledge a delivery. It's important because messages aren't just received, they also be sent, copied, stored etc. It is meaningless to "acknowledge" a message you just read from a database or took from an in-memory queue, or a new message you created in order to send it. So acknowledge is a method on a Delivery, not a Message. Same for trackers - they don't even exist until a message is sent, and they expire when the message is acknowledged, data in the message can exist (or be destroyed) independently. > 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 > > > > >
