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.