Subject: RE: [Megaco] Package Dependencies

From: "Tom-PT Taylor" <[email-masked]>
Date: Fri, 27 Jul 2001 11:45:17 -0400

The problem isn't with a specific implementation -- it's how to allow the
people the flexibility to create different implementations by packaging
different sets of features together.  If I have Basic Syntax, A Syntax, B
Syntax: there are four possible combinations (since Basic must be in all of
them).  The number of possible combinations does grow exponentially, because
this is a one-level tree, with all the other features extending Basic rather
than creating a chain of dependencies from Basic through A through B.  

I'm proposing the use of packages to indicate support for specific syntax
features rather than define properties.  If I understand Christian, he
suggests making things more conventional by defining nominal properties
(e.g. Booleans) which simply say "I support this syntax feature".  The
problem comes in the interaction between this syntax part and the different
functional packages.  We could put those Booleans in each of the functional
packages, and maybe that's the way I should go.  It does mean that every
time a new syntactic feature is added, we have to update all of the
functional packages to add a new Boolean.

Thinking more about it, I believe I will do exactly this.

-----Original Message-----
From: Troy Cauble [mailto:[email-masked]]
Sent: Friday, July 27, 2001 11:25 AM
To: Taylor, Tom-PT [NORSE:B881:EXCH]
Cc: megaco
Subject: Re: [Megaco] Package Dependencies

Tom-PT Taylor wrote:
> 
> I have an interesting situation with the Advanced Audio Server packages
> (H.248 Annex M.1), and I wanted to check out my proposed solution with the
> list.
> 
> The "basic" package currently consists of three functions: play, play and
> collect digits, and play and collect a recording.  It also includes an
> extensive description of a syntax for specifying individual announcements,
> including variable elements.  This syntax appears to the Megaco/H.248
> grammar as a parameter VALUE in quotedString form.
> 
> One "advanced" package defined in the current draft Annex doesn't change
any
> of the functions, but extends the announcement-specifying syntax.  Using
> past practice as a guide, the package was modelled as an extension of the
> basic one.  However, note that the new functionality is actually hidden
> below the level that would normally distinguish an extension -- no new
> signals or events are added, and no new parameters are added.  (That last
> wouldn't be legal in any event.)
> 
> However, this approach doesn't really work.  The first sign of trouble was
> when I thought to split up the play, play-and-collect, and play-and-record
> functions, both to clarify the functional definitions and because it would
> provide more flexibility for product implementation.  How would I
introduce
> the "advanced" syntax for each function?  Do I need to define an
"advanced"
> package for each, so that the two packages become six?
> 
> It becomes worse now that more than one advanced syntax feature has been
> proposed.  I now need a package for the basic announcement syntax, one for
> that plus feature A, one for that plus feature B, and a fourth one for all
> three features together.  You get the idea: an exponential explosion,
> multiplied by the number of functions if we decide to split them.

I don't understand your requirement of a fourth package.
If an impl. supports Basic, A, & B, wouldn't it have to
support all three "together"?

Do you need your formalization if it's not exponential?

> 
> I have an answer to this, but I thought it might be a good idea to
> legitimize it.  It could even lead to a v2 formalization of the process if
> accepted (with no change in what goes out over the wire!).  My proposal is
> this:
> 
> 1) We define the announcement specification syntax itself in a package of
> its own.  Note that this package will have none of the usual content -- no
> properties, signals, events, or statistics.
> 
> 2) We define each additional feature of the announcement specification
> syntax in another package which is an extension of the basic syntax
package.
> 
> 3) Within the functional packages (play, play-and-collect, etc.) we say
> first that the package USES the syntax of the basic syntax package and
> secondly that if any extension of the basic syntax package is supported
the
> functional package also USES that extension.  An implication is that if a
> device supports an advanced syntactical feature (e.g. sets) for one
function
> it MUST support that feature for all of the functions it implements.
> 
> Comments?  Is this a legitimate use of packaging?  Should we add the USES
> relationship to our section 12 package description requirements in v2?

I don't really have a problem with this concept.
But I'll point out that it didn't address the
exponential nature of your problem, just the
muliplicative nature.

-troy