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. -- Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc. Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/
pgpVRUuADdLPq.pgp
Description: PGP signature
