[asterisk-dev] AEL macro backward compatibility for 1.6

[Dmitry Andrianov]

Steve,
Sorry I was not very clear really.

My idea was to change _runtime_ behavior of Macro application. So the order in which modules were loaded is not important anyway - since we about to execute Macro, the loading is complete already. This way you can put:

        exten => xxx,n,Macroq(ael-macro)

into dialplan as well as to use features like:

        myfeature => #,self,Macro,ael-macro2

In both cases [deprecated] Macro application actually gets executed but uses Gosub internally.

Regards,
Dmitry Andrianov


-----Original Message-----
From: asterisk-dev-bounces at lists.digium.com [mailto:asterisk-dev-bounces at lists.digium.com] On Behalf Of Steve Murphy
Sent: Monday, January 19, 2009 7:49 PM
To: Asterisk Developers Mailing List
Subject: Re: [asterisk-dev] AEL macro backward compatibility for 1.6

On Mon, 2009-01-19 at 14:03 +0300, Dmitry Andrianov wrote:
> Hello.
> Playing with AEL in 1.6 I discovered incompatibility with configs I
> used for 1.4. I filled issue for that
> (http://bugs.digium.com/view.php?id=14267) but it was closed because
> "bug tracker is not a discussion forum". So I'm mailing the same stuff
> here as it was suggested.
>
> In 1.4 AEL used to generate macro- prefix for all macro contexts and
> transform &m1() calls to Macro(m1). Now 1.6 Macro is deprecated and
> AEL generates Gosub instead and does NOT generate macro- prefix.
> The problem is that if you call AEL macros from regular dialplan - it
> will not work because AEL-generated macros do NOT have macro- prefix
> anymore while Macro application will add it. For the same reason
> features like
>
>         myfeature => #,self,Macro,feature1
>
> will not work either if feature1 is defined in the AEL. Even if you
> manually add "macro-" prefix to your AEL macro it will not work
> because Asterisk will complaint there is return without Gosub.
>
> This may break things for lots of people.
>
> My suggestion to fix the issue is:
> 1. When Macro(xxx) is called, it checks it can find "macro-xxx".
> 2. If macro-xxx exists, it is called in "traditional macro way"
> 3. If macro-xxx does not exist, the application checks if just "xxx"
> exist and if it does - application Gosubs there.
>
> Thoughts?
>
There are two different ways the ael compiler is called. One is via the pbx_ael module, which is loaded on Asterisk start-up; the other way is via aelparse, which is a standalone, and runs independently of Asterisk.

The tough part of your suggestion is where we are running internal to Asterisk; the order in which modules are loaded is not guaranteed. If AEL loads after extensions.conf has been loaded, we might be able to traverse the dialplan and see if a macro is defined; but if extensions.conf is not loaded, we cannot tell how these macros might be defined.

I haven't tried it yet, but another approach is just to hardcode the
Macro() call. I'm sure AEL will complain about these, but they should be warnings, and not errors. If they are errors, we can fix that.

So, instead of saying "&macname();', you say "Macro(macname);"
and that will probably work. Let me know if otherwise, as I've not tried this.

> Regards,
> Dmitry Andrianov
>
> PS: if you guys deprecate Macro stuff, it would be good idea to remove
> all macros from sample dialplans too. Currently - it is full of
> macros.
>

That is not a bad idea!

murf


--
Steve Murphy <murf at digium.com>
Digium