Re: acks for messenger
For the record, I also like option (2), for the reasons that Justin articulated. -Ted On 10/26/2012 11:24 AM, Justin Ross wrote: 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
Re: acks for messenger
Am 29.10.2012 um 18:03 schrieb Rafael Schloming: think controlling whether or not the application is required to ack atthe subscription level might be a bit weird since you might or might notneed to ack a message depending on where it has come from and that could beerror prone/confusing.SwiftMQ is doing it this way:More here:http://www.swiftmq.com/products/router/swiftlets/sys_amqp/client/index.html-- Andreas MuellerIIT Software GmbH, Bremen/Germanyhttp://www.swiftmq.com IIT Software GmbH Fahrenheitstr. 1, D28359 Bremen, Germany Tel: +49 421 2208-166, Fax: +49 421 2208-167 Amtsgericht Bremen, HRB 18624, Geschaeftsfuehrer: Andreas Mueller Steuernummer: 71/572/04100, VAT: DE199945912
Re: acks for messenger
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 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 it
Re: acks for messenger
+1 to Option 2, with Rob's Messenger.ack() capability. -K - Original Message - > 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 >
Re: acks for messenger
I like Option 2 with the addendum. 1. Keeping "Message" purely as a value object without any coupling to any state is very desirable. 2. As Justin mentioned, option 2 allows a clear and more importantly a common approach for handling reliability for both sender and receiver. 3. Messenger.ack() to ack all messages received upto that point is a good compromise for people looking for the more familiar JMS like approach. Regards, Rajith On Sun, Oct 28, 2012 at 2:58 AM, David Ingham 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
RE: acks for messenger
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, &g
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
Re: acks for messenger
On Fri, Oct 26, 2012 at 11:07:38AM -0400, Rafael Schloming wrote: > 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. +1 to option 2 as well for me. Since Messenger is the type that performs communications, then it should be the means by which acknowledgements are sent. It's a more logical place to look for that sort of functionality. -- Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc. Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ pgp28IN7Ycz89.pgp Description: PGP signature
Re: acks for messenger
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
Re: acks for messenger
On 26 October 2012 17:14, Rob Godfrey wrote: > So, for me I probably started out being biased to Option 1) from a > "simplicity" standpoint, but I'm now leaning towards option 2), though > I'm not quite sure what form the DTW should take, nor how it would be > best presented in the Java API. > > One other issue that makes me uncomfortable with Option 1) it is that > by adding .ack() or even (per a previous JIRA) .getSubscription() to > Message we're potentially tying Message directly into Messenger which > is not a dependency I really want to introduce. If we stick with > Messenger as a value object then we don't have any such coupling Clearly I meant *Message* as a value object (really shouldn't try to e-mail, IM and have a conf call at the same time :-) )... -- Rob > (Messenger depends on Message, but not vice versa). > > -- Rob > > On 26 October 2012 17:07, 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 suffici
Re: acks for messenger
So, for me I probably started out being biased to Option 1) from a "simplicity" standpoint, but I'm now leaning towards option 2), though I'm not quite sure what form the DTW should take, nor how it would be best presented in the Java API. One other issue that makes me uncomfortable with Option 1) it is that by adding .ack() or even (per a previous JIRA) .getSubscription() to Message we're potentially tying Message directly into Messenger which is not a dependency I really want to introduce. If we stick with Messenger as a value object then we don't have any such coupling (Messenger depends on Message, but not vice versa). -- Rob On 26 October 2012 17:07, 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 techn
