+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 > > >
