Subject: Open Issue: When Side Effects Of Events Are Executed

From: Tom-PT Taylor <[email-masked]>
Date: Thu, 13 Apr 2000 12:46:56 -0500

We have an open issue on when the side effects of events happen.  Here are
the possibilities:

(a) when an event is detected.  Problem: "detection" in my mental model, at
least, is something that happens at the hardware level possibly
independently of the current content of the eventsDescriptor.  Thus the MGC
would have no control over which events cause signals to stop.

(b) when the event is recognized as being of interest because it is in the
eventsDescriptor (event buffering inactive) or is in the
eventBufferDescriptor (event buffering active).  Potential problems: events
may cause side effects but never get reported.  There are two cases: if the
event is processed against a digit map, is rejected as an "extra digit", but
gets thrown away because it is not in the eventsDescriptor activated by the
digit map completion event,  or if the event buffer is cleared by a change
of the control mode.

(c) This leaves the third possibility: events generate their side effects
when they are either notified or accepted into the current dial string of an
active digit map.

Comments?

---

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 14 Apr 2000 15:23:50 -0400

> would have no control over which events cause signals to stop.
I agree that there is a difference between detecting the event,
and some of the processing of it, in particular, notification.

The event buffer mechanism decouples detection from notification.
The question you are asking is, do side effects like stopping
signals happen on detection, or on notification?

> digit map completion event,  or if the event buffer is
If you are in "notify immediate" mode, then the event buffer
tells you what events to detect, and side effects should happen
on detection.  The only difference between detection and notification
is other pending activity and queuing.  I would want signal stopping,
for example, to happen "fast"

If you are in "lock step" mode, then you do have a complete decoupling
of detection from notification, but you do have a list of "potentially"
interesting events - eventBuffer descriptor.  The problem you are
worried about is an event in the eventBuffer descriptor (potentially
interesting) but not in eventsDescriptor (really interesting) when
that event is actually processed.

I would agree that it is not acceptable to have side effects without
the MGC being able to predict the state of the MG -- this is the
whole point of lock-step.  So, I would say side effects happen when
the event is processed out of the eventBuffer through the events
Descriptor.

> when they are either notified or accepted into the current
See above

Brian