On Wed, 31 Oct 2012, Darryl L. Pierce wrote:

On Tue, Oct 30, 2012 at 08:15:42AM -0400, Rafael Schloming wrote:
My inclination is to persue option 2 for the following reasons:

  - Option 1 introduces more burden since users need to explicitly
    manage the lifecycle of the returned objects. While this burden
    might be mitigated in a garbage collected language, it would quite
    likely significantly impact performance to let the GC manage
    retiring these delivery objects. (The engine underneath messenger
    is quite capable of cycling through hundreds of thousands of
    deliveries per second, and this would most likely put a
    significant burden on any GC subsystem.)

  - Option 1 introduces additional action objects, the user model is
    simpler if all the actions stay with messenger.

  - Option 1 requires coming up with a name for something that is like
    a delivery but not quite.

  - Option 2 potentially offers more capabilities in terms of
    persisting delivery state outside a messenger.

  - Option 2 maps pretty naturally to the protocol notion of
    delivery-tag and lends itself to a pretty easy name/analogy. One
    option is pn_tracking_id_t, however I prefer the slightly more
    abstract pn_tracker_t as it suggests a bit less about how it
    might be implemented under the covers.

+1 on option 2, since it appears to be much more flexible and, as you
indicate, keeps the actions in Messenger. This is much more logical IMO.

I personally prefer option 1. Forgetting for a moment the quite legit concerns that Rafi mentions, it produces the better api, imo.

I said before that I liked how users only had to engage delivery when they were ready. From that standpoint, keeping #acknowledge() and #settle() on delivery is better. That way, all the verbs on messenger act conceptually on messages. For some people, that will be the furthest they need to go. Then, only if you opt to handle deliveries do you discover the verbs to handle delivery state.

That said, I buy the concern about lots of handle objects. For me, this refocuses the question on how we might support such objects in at least some of the bindings. I would argue that we want that option.


Reply via email to