On Wed, Oct 31, 2012 at 7:45 PM, Justin Ross <jr...@redhat.com> wrote:

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

This is a bit of a tangent, but I think conceptually all the verbs on
messenger are actually acting on deliveries. I know it looks syntactically
like put and get operate on a message, but that is really incidental as the
message object is purely a mutable holder/authoring tool for message
content. What put and get are really doing is creating/accessing a delivery
(i.e. stuffing your letter into an envelope, or opening up the envelope and
giving you the letter).

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.

It should be trivial to wrap the handle in an object that holds a reference
to both the messenger and the tracker. That's not quite what I did in
python (see my other post), however I think what I did has a similarly
small footprint. I think which style makes more sense depends somewhat on
the extent to which these things are used individually or in aggregate,
i.e. if aggregate is the common case, then the tracker as an entity is less
of a fit.

As an aside, I would avoid thinking of an entity wrapping up a reference to
the messenger and a handle as a Delivery, both because that is a distinct
and formally defined concept, and because there are subtle but important
differences. It's really a reference to a delivery that may no longer
exist, and it also has the property of identifying a point in a sequence of
deliveries allowing for identifying ranges of deliveries for aggregate


Reply via email to