The idea of MessageStream sounds great (and more implementation
friendly, IMO), but I suspect that renaming Subscription to
MessageStream might not be a straight forward issue after all
...
To
me, MessageStream sounds more like a physical entity with two ends -- a
source and a sink. NotificationProducer would be the source and
NotificationConsumer would be the sink in our current model. Further more,
any policies associated with the MessageStream would govern the
flow, security, lifetime, etc. of the message stream between the source
and the sink.
While I think that semantically the Subscription in
our current model can be considered equivalent to MessageStream,
there may be some additional semantics unique to
MessageStream, which may not necessarily be well
reflected by our current model. For example
--
a> Can I have two MessageStreams each with different sets of
polices associated with the same source. What is the programming model
here - should I first create the different MessageStreams and then pass them
as parameters to a single Subscribe operation?
b> What happens when a MessageStream is paused? Is
just the delivery of messages to the Consumer is halted while the
stream continues to grow, or source of the stream is shut off?
c> Can I move an active MessageStream from one source to
another?
I
guess the above kind of issues also apply to the current model of
Subscription. But the breakup of concerns and thereby the
design of the solution would be different based on
whether MessageStream is a first class notion or not,
IMHO.
Basically, I am not quite sure about the overall
effect of changing Subscription to MessageStream ... Could we
may be first talk about the use cases that would benefit from such
a change ...
Thanks,
Sanjay
I'll offer two candidates, but there may
be better:
- Subscription entails attaching a consumer endpoint to a stream of
messages.
- Subscription entails associating a consumer endpoint with a topic or
set of topics.
A message stream is understood to be asynchronous
in the sense that there is generally no a priori way to know how many
messages (if any) will arrive or when they will arrive.
The first
definition is at least as broad as the second, since a set of topics
implies a stream of messages published on those topics. The question
I'm currently puzzling over is this: Are there any practical cases
where one would want to control a message stream -- e.g., pause it, resume
it, change its properties, terminate it -- which wasn't created through a
WSN Subscribe call? Similarly, is there a standard set of (small p)
policies which may be applicable when creating a stream, whether or not
the stream were created through WSN? This might include QoS,
security, 1-of-N delivery, double opt-in for DDOS mitigation, and whatever
else floats by in discussion.
In short, is a WSN subscribe request
the only meaningful way to create a message stream?
If not, then we
have candidate 1 above: Subscription is one particular way of creating a
message stream. If so, then the two candidates are equivalent and we
can safely view all message streams as subscriptions to some
topic.
I can certainly see cases where "topic" degenerates to
essentially nothing. The canonical case is a dumb device that just
outputs (say) status messages from time to time, without tagging them with
any particular topic. Another possibility would be an essentially
request-response situation where a client makes some arbitrary query and
results come back over the response channel in dribs and drabs. This
might include discovery protocols, where the client shouldn't have to wait
for all responses to be gathered before getting any of them.
Either
of these could be presented according to the IRP view of
notification. For example in the discovery case, we could define a
notional resource representing all responses heard so far, but this seems
like the resource tail wagging the message stream dog -- really all that's
there is a stream of responses. We could also define a resource
representing all available parties to be discovered, but the "events" in
the response message stream are not changes to the state of this resource
(i.e., servers coming up and going down).
My instinct is that what
we currently call SubscriptionManager (and I've proposed just calling
Subscription) might better be called a MessageStream, leaving open the
possibility that MessageStreams could be created through means other than
WSN. In this view, a sizable chunk of the work we've been doing is
generic to message streams and should be clearly noted as such.
I
currently have no strong opinion as to whether this means a separate
document or just a well-marked section, or some other means of
demarcation. This seems very much secondary to the issue of whether
there is a distinction to be made at
all.