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

Reply via email to