[asterisk-users] Originate with label?

[Antony Stone]

On Monday 29 August 2022 at 17:00:23, Mark Murawski wrote:

> On 8/29/22 09:30, Antony Stone wrote:
> > It is, although there are ways I think it can be improved - I'm wondering
> > how best to go about proposing these.
> > 
> > The most obvious for now are:
> >   - please can "a=1;" be converted to use Set() instead of MSet()
> >   (especially since MSet is officially deprecated)?
> 
> Currently being discussed!  We can definitely continue talking about the
> pros and cons of adding an option for this or maybe finding another way
> altogether.

Yes, it would useful to implement "backward compatibility" options for AEL, 
just as exist for whatever "non-AEL" is called.

Some equivalent of [general] in extensions.conf might be good?

> >   - same thing for for (;;)
> 
> I see that for (;;) produces an empty MSet().

No, no - I didn't literally mean "(;;)", I meant this as an abbreviation for 
the generic format of the for() syntax.

> Definitely this can be cleaned up.  Thanks for bringing this up.  In the
> meantime you can use while (1)

True; that works for literally "for(;;)", but I think I've never bothered to 
use that :)

I meant it wouod be good to use Set() instead of MSet() for the first and third 
parts of "for (one; two; three);"

> >   - please can gosub be added, to convert into Gosub() (matching goto
> > converting to Goto())?

> I agree that AEL keyword 'gosub' should exist.  That's been one of my
> todo items.  From not only a consistency perspective, but from a syntax
> checking perspective it would benefit from reporting whether or not your
> gosub destination exists or not, just like goto will complain that the
> destination doesn't exist when the context/extension/priority used is
> not valid.

Sounds good.

> The '&' syntax does use GoSub under the hood, and not the deprecated
> Macro().

Yes, agreed.

> And I'm not sure what you mean by redundant parameters?  When you use AEL
> 'macro' to define a '& destination', it uses the positional parameters that
> are passed in as ARG1/ARG2/etc that are inherent in using GoSub and converts
> them to more friendly named-parameters (as defined in the macro definition).

That's precisely what I mean :)

If you use Gosub(), you can reference your parameters as ARG1/2/3/etc, but if 
you use &, you end up with several "MSet(xxx=${ARG1});" etc at the start of 
your subroutine.

These, in my opinion, are redundant,

> This is why there's always a group of MSet's generated when using AEL
> 'macro'.

See above :)

> If you don't want these extra MSets, then feel free to define a straight up
> context to GoSub into and you can do your own parameter processing using
> ARG1/ARG2/etc

I do.

I just wish there were a gosub in AEL mapping to Gosub() to match goto mapping 
to Goto().

> >   - it would be great if the redundant NoOp()s which get created by if ..
> > else, while ... and for(;;) could be (maybe optionally?) removed from
> > the resultant dialplan code - otherwise you end up with lots of added
> > commands such as NoOp(Finish if_if_fromTrunk_208_209); in the output.
> 
> They aren't redundant specifically, they were left in there (not by me)
> for debugging/tracing purposes.

Hence my "maybe optionally" suggestion.

> But for the casual user, I agree they are mysterious and not very useful. My
> idea to address this is to instead report on the actual if condition to
> assist with tracing/troubleshooting.

I'd prefer to see an option in extensions.ael to say whether you want them at 
all or not.

> This is a mockup of what the new-style if/else processor would output
> 
>                      26. NoOp(AEL IF("\${DIALSTATUS}" == "BUSY") --
> extensions.ael:1405)
>                      27. GotoIf($["${DIALSTATUS}" == "BUSY"]?28:30)
>                      28. Set(voiceMailOptions=b)
>                      29. Goto(32)
>                      30. NoOp(AEL ELSE -- extensions.ael:1409)
>                      31. Set(voiceMailOptions=u)
>                      31. NoOp(AEL END ELSE -- extensions.ael:1410)
>                      32. NoOp(AEL END IF("\${DIALSTATUS}" == "BUSY") --
> extensions.ael:1411)
>                      33. NoOp(DoStuff)

I would disagree with *any* extra NoOp()s being included in the resultant 
output unless the user has asked for them.

Let the code simply express what the user wrote and not add anything 
(especially stuff which will end up in a verbose log) which doesn't correspond 
to the original input (unless necessary for the logic to work).

> My idea is that the 'if' block would be preceded by outputting the
> logical condition we're about to check, along with the original ael line
> number, and then at the end of the if block, we would get an associated
> END IF with the original ael line number.  This would enable the ability
> to quickly locate the code where conditions are being used and also be
> able to look at the logs and see why your code is doing what it's doing
> without a lot of extra verbosity and without needing a lot of work to
> find which ael-lines are running.

Nice as a debugging tool, please make it optional, dependent on a configuration 
setting.

> > - finally, it would be good if the documentation could be clear about
> > whether the extensions.conf [general] section can be substituted using
> > AEL.  I haven't yet worked out whether this is possible or not.
> 
> [general] section options are not available in ael... currently there's
> no mechanism to support that sort of thing.

Maybe for the things that would make sense for AEL (see above), this would be 
a useful addition?

> bracket items like [general] aren't supported in the AEL parser. and
> some of the options don't even make sense and/or apply to AEL like
> static/writeprotect

Agreed, would be nice to find this clearly documented.


Antony.

-- 
Never write it in Perl if you can do it in Awk.
Never do it in Awk if sed can handle it.
Never use sed when tr can do the job.
Never invoke tr when cat is sufficient.
Avoid using cat whenever possible.

                                                   Please reply to the list;
                                                         please *don't* CC me.