Re: write-up of interaction patterns

Hi Amy,

> My second comment is that the event pattern introduced here is
underspecified.
> Until and unless it can be made less ambiguous, more interoperable, I
would
> resist including it.

I wasn't writing it in spec-speak .. but point well taken. So let's make
it less ambiguous, and more interoperable so that you can support it
instead!

> Specifically:
>
> 1. the number of notifications to be received for a subscription is
underspecified
> 2. there is no termination syntax
> 3. termination conditions are unspecified
> 4. status investigation is unspecified
>
> I believe that the model on which the 'event' pattern is based is event
notifications in Java and similar languages.  It is worth noting that, in
Java, an XyzzyEventSource exposes addXyzzyListener *and* removeXyzzyListener
(and may supply more than one event, for that matter).  Status investigation
is insignificant for this case; in Java, a listener thread isn't going to
fail and later be restored, and when the JVM quits, all the loose ends are
cleaned up.  Similar ease of implementation is simply not found in network
communications.

Agreed.

> 1. the number of notifications to be received for a subscription is
underspecified:
>
> It is possible that this pattern is intended to be "send me the next
notification" and stop; basically a request/response with delay.  I don't
believe that that is the case, since it's modelled on the event models in
Java etc.  If it is intended to be single-shot, then the following
criticisms don't apply.  But if it's intended to only deliver a single event
notification, I don't think that it's very useful, either.

My intent was to have the Java/JavaScript style >= 0 deliveries pattern.
If and when this becomes accepted, we'll make sure that the spec clarifies
this clearly.

> 2. there is no termination syntax:
>
> addXyzzyListener() without removeXyzzyListener().  <subscription> without
<unsubscription>.  How do I *stop* getting messages from this service?  I do
not think that this can be left unspecified.  Shutting down the JVM won't do
it, because there isn't a JVM over the scope of the network.  I can, of
course, just stop listening, but that raises the next issue.

Oops, I'll add that .. forgot ;-).

> 3. termination conditions are unspecified
>
> When a service is sending notifications, and begins to receive errors
(network unreachable, host unreachable, port unreachable, connection
refused), is it allowed to terminate the subscription?  Is it allowed to do
so the first time?  The thousandth time?  At a percentage?  When?  If my
router dies, and the network folks work furiously for two hours to get us
back up and reachable, am I subscribed or not?  Which leads to the next
issue.

Again, we'll write this down if and we put this in. My preference is to
follow the Java style rules and pick as simple as possible semantics
for the distributed issues you bring up (all good ones!). If we get
this far I'll be happy to propose a set of answers to these and related
questions.

> 4. status investigation is unspecified:
>
> Am I subscribed or not?  As the event syntax is given, were I to build a
client that expects to subscribe, I would have that client subscribe every
[duration], where duration represents the average time between
notifications.  I don't want to miss one.  I would also design the client to
send the most brutal error message possible when I want to unsubscribe (a
TCP RESET, for instance, when I receive a notification from a service that I
can't unsubscribe from).  Probably, though, since this looks like a fire
hose I can open, but never close, I just wouldn't use it.  If I had to use
it, since I can't find out if I'm not getting messages because there are no
messages or because the network happens to be down, I'd use the subscription
message as a keep-alive.  As a result, I'd probably be sending nearly as
many subscription requests as I receive notifications.  Not good.

My proposal would be to not support any status investigation capability in
this simple event pattern syntax. If such complexity is desired, the
general interaction pattern approach can be used to give clear and
precise semantics and also as the basis to provide custom syntax.

Sanjiva.

Received on Wednesday, 15 January 2003 19:37:25 UTC