Subject: Re: Washington Issue 5 - Signals

From: Brian Rosen <[email-masked]>
Date: Wed, 17 Nov 1999 10:45:47 -0500

> I definately think that Brief signals should be able to be stopped by
> sending another signal. Having only an event is not sufficient. Ie.
> announcements: you should be able to interrupt one. There should be no
> special rule for brief signals.
The problem arises only if you take Brief signals as any
length you want them to be.  Announcements make terrible Brief Signals
because they aren't brief.  They should be TO,
with or without the completion event.  I actually argue there should be at
least a guideline.  Brief means less than 1/2 second, or maybe less!!

You are stuck between two goals:
        Allowing a Brief signal to not require complex
                handling by the MGC - it sends it, and then
                it need not take any special precautions to
                make sure it plays out, an in particular, only
                one message to do it
        Allowing a variety of responses to longer messages,
                ones that actually do need to be interrupted.
                For these, you are willing to have multiple
                messages and/or completion events.
If you use BR for really short signals, and TO when you have
a longer one, you meet both goals.

If you are stuck on Brief means one cycle, I'd be okay with
having a fourth type - ONCE, which was play one cycle,
which was interruptible, and otherwise followed the normal
rules.  That is equivalent to TO with the timer equal to one
cycle.

> Another problem is the rules for continue, replace and stop.
> What happens if you have a brief signal (S1) and want to add another
> signal (S2) to the signal descriptor(SD). S1 has just
> finished when you
> send an ADD or MODIFY with SD=S1,S2 (you haven't received the
> SignalComplete event yet) because you want S1 to continue
> playing. What
> will happen is that you order S1 again and S2. You've played S1 twice
> which is an error.
With BR as defined, you simply send S2.

The case you want is where you have a TO, you want to complete
it and play another one when it finishes.  If you didn't
ask for the completion event, you are hosed, because if you
mention the original TO in the replacement SD, if it arrives after the MG
has completed playing it, it will play
twice, if it has not, it will keep going.

Moral - use the completion event, or just delay the TO value
before sending a new signal.

> I would suggest coming back to a higher level for the
> replacement rules.
> ie. the signal descriptor. I think having multiple descriptor
> each with
> an ID would solve this.
>
> ie.
> Each group of related signals would be under a single signal
> descriptor
> ID.
> SD(x)=S1,s2,s3     would play s1 then s2 then s3

> Each group of unrelated signals would be under different signals
> descriptor ID.
> SD(y)=s4
> SD(z)=s5  would play s4 and s5 at the same timout.
>
> To stop signal/s the appropriate SD(ID) would be given.
>
> Type of signal rule is the same as your list proposal. ie. ON in the
> middle of SD doesn't make sense. No special rules are needed depending
> on type of signal. The repeating of signals isn't a problem.
Interesting, but not enough methinks.  If I send SD=1{BR1} and
then want to have BR2 play, I would send SD=1{BR1,BR2}, right?
Presumably if I modify SD=1, if the MG has finished BR1
it will play BR2 right away, if it hasn't finished it will finish
it and play BR2 after it, right?

Okay, how do I EVER know when I can send SD=2{BR2}?  Do I have
to keep modifying SD=1 forever?  If I have to track time,
your solution doesn't help - I just use time as the mechanism
to control sequential signals.

Brian

---

From: Christian Groves <[email-masked]>
Date: Thu, 18 Nov 1999 12:38:55 +0100

G'Day Brian,

Please see my comments marked [CHG]

Cheers, Christian

> a longer one, you meet both goals.

[CHG] The definition of the length of brief is purely subjective. It
depends on the actual signal itself, processing times in the MGC and MG,
transport delays. How do we decide what it is?

> rules.  That is equivalent to TO with the timer equal to one

[CHG] I'm happy to rename 'brief' to 'once' if that helps understanding.
I don't think we should have a special signal that can't be interrupted.

> before sending a new signal.

[CHG] Yes completion events are valid. The scenario I presented is when
you play a second signal (s2) at the same time, no queuing is involved.
There's no dependance on S1 but according to your proposal you have to
specify S1 if you want to keep it playing. A completion event wouldn't
be helpful as it pertains to S1 which has no dependencies on S2.

> then want to have BR2 play, I would send SD=1{BR1,BR2}, right?

[CHG] Depends on what you want:
         o BR1 and then BR2 at the same time then Yes
         o BR1 finishes then BR2 starts then No.
           I've mentioned nothing in my proposal about queueing.
           I didn't think people wanted to support it.
           You would wait for a signalcomplete event. Before sending
           the next. Alternatively the embedded event descriptor.

> it and play BR2 after it, right?

[CHG] Yes. I assume you want to play SD=1{BR2}. A single
SignalDescriptor instance will contain signals that have dependencies to
each other. SignalDescriptors have no dependencies between them.

> to control sequential signals.

[CHG] OK. You've made a considerable leap in using SD=2{BR2}.
      You can send SD=2(BR2) when ever you like because its not
dependant on SD=1.