Subject: Re: Statistics

From: Brian Rosen <[email-masked]>
Date: Wed, 8 Sep 1999 15:54:30 -0400

There is no reason not to use RequestedInfo, rather than
invent a new mechanism.  As you point out, it can't be
two commands because you could get erroneous statistics.
I like the generality of RequestedInfo.

I think the only argument for the flag was that if
the MGC wanted EVERY subtract (and/or EVERY move) to
generate statistics we could, for convenience, define
a state variable that simple worked as if a
RequestedInfo{Statistics} was included in every
subtract/move.  That doesn't seem to be a big deal,
but if it offends you we can drop it.  Statistics are
very operator dependent -- some will like lots,
some will like few.  Offering controls on statistics
seems, to me, to be appropriate.

We are in feature creep, I know, I know.

Brian

> -----Original Message-----
> From: Abdallah Rayhan [mailto:[email-masked]]
> Sent: Wednesday, September 08, 1999 11:28 AM
> To: [email-masked]
> Subject: Re: Statistics
>
>
> Should we allow global flags that we could set on and off for
> particular commands ? Is this a MEGACO way of doing things ?
> I dont think so. Otherwise, why would we have all these commands
> and descriptors !
>
> Should we allow stats request in certain commands ? We started
> with specialized commands to perform exclusive functionality and
> now we are making them inclusive. Are we going ever to draw the
> line on this version ?
>
> I believe that the real problem is not the stats but we have
> not defined
> how changes are committed within an action, e.g., when the commands
> are processed, are they executed at the same instant similar
> to banking
> transactions ? This does not change the commands order because we
> can always time it as action execution time. If that is the
> case, then we obtain
>
> stats by issuing an AuditValue command before
> Add/Move/Modify/Substract.
>
> The syntax issue could be nothing but semantics in this case !
>
> If we dont put any constraints on commands execution, this could
> introduce chaos, e.g., long delay between two commands results
> in command failure !
>
> In either case, if a decision is made to request certain
> audit values with
> some commands, then we need something like auditDescriptor
> that specifies
> which values should be returned. requestedInfoDescriptor is
> very general
> and we dont need all but stats only.
>
> Abdallah Rayhan
>
>
> Brian Rosen wrote:
>
> > Does anyone object to this?
> >         RequestedInfo is allowed in Add/Subtract/Move/Modify
> >         If it occurs, the requested descriptor is
> >                 returned with the command as with AuditValue
> >
> > As an aside.  AuditValue can now be considered a No-Op
> > which permits RequestedInfo.  If we need a no-op for other
> > reasons, this can be it.
> >
> > Can I hear opinions on whether:
> >         Subtract does NOT automatically return statistics,
> >                 RequestedInfo is used to ask for them
> > or, my personal favorite
> >         There is a property of root which turns on or off
> >                 the automatic generation of statistics from
> >                 subtract and another for move
> >
> > Brian
>