So for configuring this capability I was thinking of something along the lines of two messenger level settings for reliability, e.g. something for incoming messages controlling at-most-once vs at-least-once vs exactly-once, and likewise for outgoing messages.
I think controlling whether or not the application is required to ack at the subscription level might be a bit weird since you might or might not need to ack a message depending on where it has come from and that could be error prone/confusing. I think we could have a separate control at the subscription level that would influence what acking happens on the wire, but I think we should think of the responsibilities of the programmer and his interaction the outgoing/incoming queues as distinct from what acking may or may not happen on the wire. --Rafael On Sun, Oct 28, 2012 at 2:58 AM, David Ingham <david.ing...@microsoft.com>wrote: > I like option 2 too for the concept separation reasons that have already > been stated. > > The next question is how would an app select which receive mode it's > interested in (auto ack vs. explicit ack). Would this be an option on > Messenger.subscribe()? > > Dave. > > -----Original Message----- > From: William Henry [mailto:whe...@redhat.com] > Sent: Friday, October 26, 2012 12:27 PM > To: proton@qpid.apache.org > Subject: Re: acks for messenger > > +1 I like the separation. And the analogy to tracking is not only > palatable but also kinda proves out the idea. > > William > > ----- Original Message ----- > > I like option 2) for two reasons. One, it produces very > > straightforward semantics for the various levels of delivery > > guarantee. Two, it's easy to ignore if you'd like: if you just want > > fire-and-forget messaging, you don't have to engage delivery as an api > > concept; if you later change your mind, it's not hard to level up. > > > > Justin > > > > On Fri, 26 Oct 2012, Rafael Schloming wrote: > > > > > I'm taking a look at expanding the messenger API to support > > > reliability and so far there seem to be two directions to explore > > > which I'll attempt to describe below: > > > > > > Option 1) > > > > > > Messenger.ack(Message) or possibly Message.ack() > > > > > > I'll describe this as the simple/expected/conservative option, and > > > those really are its strong points. Some less desirable points are > > > that it takes the Message concept in a bit of a different direction > > > from where it is now. Message is no longer simply a holder of > > > content, but it is also now (at least internally) tracking some > > > kind of delivery state. This is undesirable from a design > > > perspective since you're really merging two separate concepts here, > > > delivery state and message content, e.g. you now end up holding > > > onto the message content to track the delivery state when arguablly > > > the common case is that an app will be done processing the content > > > quickly but may care about the delivery state for longer. Another > > > implication of this merging is that it makes messages harder to > > > reuse, e.g. imagine if you want to receive a message, mutate it a > > > bit, and then resend it or send a number of similar messages. > > > > > > It's also potentially more work from an implementation perspective > > > as the underlying model treats Message as pure content and has > > > delivery factored out as a separate concept, so this would be the > > > start of a bit of an impedence missmatch between layers. It's > > > certainly doable, but might result in more overall code since we'd > > > be expressing similar concepts in two different ways. > > > > > > Option 2) > > > > > > Introduce/surface the notion of a delivery/tracking number through > > > the Messenger API, e.g.: > > > > > > Messenger.put(Message) -> Delivery/Tracking-Number/Whatever > > > Messenger.get(Message) -> Delivery/Tracking-Number/Whatever > > > > > > (I'll abbreviate Delivery/Tracking-Number/Whatever as DTW for > > > now.) > > > > > > There are a couple of choices with this option, DTW could be a > > > value object (i.e. similar to a handle), with actions on the > > > messenger itself, e.g. Messenger.ack(DTW), Messenger.status(DTW). > > > This kind of takes the tracking number analogy and runs with it, > > > you ask your messenger about the status of a given delivery via its > > > tracking number. Alternatively, DTW itself could be a more action > > > oriented interface with its own methods for acking/status/etc. This > > > isn't necessarily an either/or as there are reasons the C API might > > > want to use a handle approach even if we wish to > > > conceptualize/surface DTW as more of an independent thing in the > > > object oriented interfaces. > > > > > > On the negative side this is less traditional/expected relative to > > > Option (1), and it does in total add more surface area to the API. > > > On the positive side however it does provide a lot more capability > > > since the same concept extends quite easily to track the state of > > > outgoing deliveries. > > > > > > From a design perspective this is nicer for a couple of reasons, > > > unlike Option (1) by keeping Message as a pure holder of content > > > you have more flexibility with how you use the API, e.g. you can > > > discard/reuse the Message but still track the status of your > > > deliveries. Also, it seems likely that once the Option 1) path > > > includes the ability to track the status of outgoing deliveries, > > > the total surface area balance might fall more in favor of Option > > > (2). > > > > > > A possible addendum to Option (2) suggested by Rob in order to > > > deal with the surface area concerns is adding some kind of > > > Messenger.ack() that would acknowledge all unacked deliveries > > > pulled from the incoming queue. This would enable you to do basic > > > acking without ever needing to bother with DTWs if you don't care > > > about them. This could in fact be a nice place to start as it > > > doesn't necessarily commit us to either path initially. > > > > > > FWIW, my bias right now is towards exploring Option (2). I think the > > > fact that it is less expected is sufficiently mitigated by the fact > > > that with the addendum there is a very gentle learning curve, and > > > even if you explain all the concepts up front, the whole tracking > > > number analogy makes it fairly intuitive. I can even imagine playing > > > up the difference as a selling point from a technical marketing > > > perspective. > > > > > > --Rafael > > > > > >
