Re: [wsn] Roles vs. Port Names

[David Hull <dmh@tibco.com>]

 

> I've been thinking for a while about what might be better, but given that different
> people process information differently, there is no objectively clear choice.  
Indeed. No objectively clear choice on a different naming convention, so lets stick
with the convention we have, warts and all.

I don't think that follows at all.  The current NotificationProducer does not produce notifications and the current SubscriptionManager does not manage subscriptions, at least not in the common sense of managing a collection of subscriptions.  There may be no objective best name, but that doesn't mean that the current names can't be improved.

The current names have been a stumbling block for several people, myself included, trying to understand the architecture.  This may not seem to be such an issue since everyone here is presumably now familiar with the architecture, but I believe they are continuing to be a stumbling block in discussing the architecture.  In any case, it is liable to be an issue again when the documents are published to a wider audience.

FWIW, I've manage to re-align my mental image of "producer" more along the lines of a movie or music producer, in the sense of "party who makes things happen but doesn't necessarily have a direct hand in proceedings," but that's clearly a crutch.  No such luck on "SubscriptionManager" (maybe it should get 10% of every Notification? :-)

In any case, "SubscriptionFactory" and "Subscription" are not just a little clearer to me, they're night-and-day clearer.  Part of this is surely subjective, but there is also a well established convention of calling "thing you use to create X" an XFactory, and calling the entity you use to access notification streams a "Subscription."

Indeed, operation names such as "ResumeSubscription" and text such as "if the Subscription is not in the paused state" suggest that the standards authors see the object as a subscription.  If I understand correctly, the whole point of using the IRP is that you're addressing messages to the managed resource directly, and not to some intermediate object.  One does not send "GetResouceProperty" to a "NotificationProducerManager" to find out about a NotificationProducer.  Why is SubscriptionManager different?