Subject: Re: digitMapDescriptor

From: Brian Rosen <[email-masked]>
Date: Mon, 16 Aug 1999 14:23:49 -0400

We have been through this before.

If you have a Put command, its operand must be a descriptor;
all commands have descriptors as their parameters.

If you have a descriptor (define) that describes the
name of the item, possibly its type, and its value,
then the Put command doesn't add anything; just use the
descriptor in any command.

We could define a form of one of them that was a no-op and call
that Put if you would like :)  I used to have fun thinking up
all the ways to specify a no-op.  How about Move null context
to null context?

Brian

> -----Original Message-----
> From: Fernando Cuervo [mailto:[email-masked]]
> Sent: Monday, August 16, 1999 1:27 PM
> To: [email-masked]
> Subject: Re: digitMapDescriptor
>
>
> So..
> the "operational" part of digit maps is handled through
> events..this is
> good.
> The "definitional" (?) part of  scripts, templates,
> digitmaps, etc is all
> handled in the same manner..this is good.
> However, we could define them in any command. I sort of liked
> the "old"
> Put/Delete commands. The transactional model of Megaco will allow
> Put/Deletes to go together with Add/subtract/move...etc. if
> required or on
> their own (a better way to handle things that are more
> permanent and broader
> in scope than the digit collection on a per call basis).
>
> Fernando Cuervo
>
>
> > ----------
> > From:         Brian Rosen[SMTP:[email-masked]]
> > Sent:         August 16, 1999 11:06 AM
> > To:   [email-masked]
> > Subject:      Re: digitMapDescriptor
> >
> > > Ok, I see this now - either a digitMapName OR a
> digtMapValue in the
> > > AccumulateDescriptor- and I assume if you just put a
> > > digitMapValue, it is a
> > > transient digit map, i.e. it will not stick around after the
> > > event(s) it is
> > > assigned to has(have) been detected.
> > Correct
> >
> >
> > > In order to simplify things for the MG, we could say that the
> > > digitMapDescriptor is ONLY used on Modify, and on Add. It
> > > should NOT be used
> > > on Move. If we allow it everywhere, then the errors that can
> > > occur on a
> > > command are increased - what if the actual move succeeds, but
> > > the storing of
> > > a digit map fails? You may still have wanted the Move to
> > > occur. So better to
> > > separate the two - do a Modify with a digitMapDescriptor, and
> > > then do a
> > > Move.
> > I don't understand this; there is no difference between Add and
> > Move in this respect, and it complicates the syntax, in that
> > at the moment, all the parameters to Add, Move and Modify
> > are the same.
> >
> > > Actually, we need to say on the Add and Modify, that if the
> > > storage of the
> > > digitMapDescriptor fails, the Add or Modify should still do
> > > the other things
> > > it is asked to. In other words, we need to send back a
> > > Warning msg that the
> > > storage of the digit map failed, and because this is the
> > > case, the Events
> > > Descriptor will act as if it had been asked to send back a
> > > Notify on every
> > > event detected. Same thing if a named digit map is not found.
> > I don't think this is right.  If you can't store the digitmap,
> > it's an error, and the transaction is in error (although
> > we are arguing about transaction syntax at the moment).
> > If the digitmap defined is used in the EventDescriptor of
> > the Add, it's definitely a problem.
> >
> > Brian
> >
>