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.