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.