What's the difference between a distributor and a subscription manager?

[David Hull <dmh@tibco.com>]

The model we have now relies on a NotificationProducer which acts as a 
factory for SubscriptionManagers.  The factory method (Subscribe) may 
take an open-ended set of policy/parameter elements, and the SM itself 
may support arbitrary additional methods beyond the basics.

The model I am proposing shifts the variability onto the (optional) 
distributor role.  The syntax and semantics of the Subscribe operation 
are fixed, except for the extensibility point for filtering (or 
not-a-filtering).  Distributors are just consumers as far as the core is 
concerned.  We recognize a special case where distributor EPRs are 
produced and specially treated by the NP itself, but this is not 
required and, depending on the particular scenario, may co-exist 
peacefully with garden-variety consumers.

The SM itself would support only a minimal set of operations, perhaps as 
little as get* and destroy.  Similarly, the SM's properties are reduced, 
probably to as little as filtering parameters and consumer(distributor) 
endpoint.

The cost of this is an extra message exchange for creating a distributor 
(which may or may not be reused for multiple subscriptions) and an extra 
EPR to keep track of.  This would only be incurred if the base semantics 
are not enough.  In particular, the "dumb devices on an isolated 
network" case remains simple.