[asterisk-users] Originate with label?

Mark Murawski
Mon, 29 Aug 2022 15:00:23 -0000

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.

>   - same thing for for (;;)

I see that for (;;) produces an empty MSet().  Definitely this can be
cleaned up.  Thanks for bringing this up.  In the meantime you can use
while (1)


>   - please can gosub be added, to convert into Gosub() (matching goto
> converting to Goto())?  The & syntax is completely different from the
rest of
> the language, and also creates redundant assignments at the start of the
> subroutine for parsing the parameters.  Now that macros are deprecated in
> favour of subroutines, it makes sense, I think, to make gosub a part of
AEL.

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.

The '&' syntax does use GoSub under the hood, and not the deprecated
Macro().  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).  This is why there's always a group of
MSet's generated when using AEL 'macro'.  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


>   - 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.  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.

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)


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.

>   - 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.

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