For the record, I also like option (2), for the reasons that Justin articulated.


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.


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

 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.


Reply via email to