Comments inline
Patil, Sanjay wrote:
Message
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.
Given that the both your reply and Dave's offer perfectly good but
different definitions of a message stream, I'd say the term is pretty
clearly overloaded. Alas.
What I have in mind is one end of a stream -- in the case of
subscription, the incoming end: an endpoint which may receive zero or
more messages on no particular schedule (kind of like our draft
documents :-). Focusing on just one endpoint, and leaving it entirely
open where messages may come from is crucial to subscription. I intend
to say more on this in a bit.
More precisely, we're looking at the interface(s) for establishing and
controlling the endpoint end of a stream (in the sense I gave above).
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?
Pub/Sub is essentially about decoupling publishers and subscribers --
sources and sinks -- from each other. So two different subscriptions
could have arbitrarily different properties. E.g., I could view a
stream of stock quotes through email, IM or SMS, each independent of
the other and completely unknown to the publisher of the quotes.
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?
Under pub/sub semantics, the delivery of messages to the Consumer is
halted. Published messages will still be sent to other Consumers.
Whether messages on the halted stream are buffered are dropped on the
floor is a matter of policy.
c> Can I move an active MessageStream from
one source to another?
I'm not sure what that means.
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 ...
That's exactly what I would like to do. I'm in much the same place.
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.
|