[asterisk-dev] (ASTERISK-19336) h exten is not run in the context that calls a AEL macro

[Johan Wilfer]

2012-03-06 18:59, Tilghman Lesher skrev:
> On Fri, Mar 2, 2012 at 10:11 AM, Johan Wilfer <lists at jttech.se> wrote:
>> 2012-02-29 21:47, Tilghman Lesher skrev:
>>> On Wed, Feb 29, 2012 at 4:21 AM, Johan Wilfer <lists at jttech.se> wrote:
>>>> 2012-02-29 02:59, Tilghman Lesher skrev:
>>>>>> This change in >1.6 makes it hard to actually use macros for anything
>>>>>> complex as I have to duplicate hangup-code in every macro, and even
>>>>>> duplicate the same macro for different contexts calling the macro!
>>>>>>
>>>>>> To add to that, in 1.4 there was channel variables to know the context
>>>>>> invoking the macro. This is also less functionality in newer versions.
>>>>>>
>>>>> I have created a function called STACK_PEEK() which would provide the
>>>>> equivalent values.  It is on reviewboard here:
>>>>> https://reviewboard.asterisk.org/r/1776/
>>>> Wow! Thank you!
>>>> It looks very thought through.
>>>>
>>>> This is a tool to create very powerful ael dialplans.
>>>>
>>>>> (from [asterisk-dev] [Code Review] Create STACK_PEEK to view calling context, extension, and priority):
>>>>>
>>>>> Whether this goes into a version of Asterisk earlier than 11 is a case for the bug reporter to make.
>>>> I would really like to have this included in a release-branch so I can
>>>> upgrade from 1.4 to 1.8/10 without applying patches.
>>>> It's a matter of view if this lost functionality is a bug or a feature I
>>>> guess.
>>> That's definitely the issue:  is this a bug or a new feature?
>> I've spent some more time thinking about this. My opinion is that it's a
>> bug, and we should fix it in 1.8 and 10.
>> Can someone open ASTERISK-19336 so I can upload a patch for the ael
>> parser later?
> The code is now there on reviewboard, with the AEL code generation.  It was
> bugging me over the weekend, so I sat down at 3am and figured out how to
> generate the code.  While the STACK_PEEK function has been tested to
> verify functionality, and while the code generates as designed, I have not
> otherwise tested the bubble-up functionality, so this part of it does need to
> be tested before I can commit it.

I've tested this during the weekend, and it works as expected. With this
patch ael in 1.8 behave like in 1.4 again.

One thought I had was if the same should apply to the other special
extensions like: i, t, T, o, a
Personally I rarely use macros to Dial and get input from the user, for
me it's more like a subroutine, and catching h like above is sufficient.

But maybe these other extensions should be treated the same to be
consistent?

Or maybe the T (absolute timeout) should be treated like h, as the
functionality is similar..

Maybe the user is supposed to implement i, t, o, a in the macro with
catch if he wants to catch these?
It could maybe cause more confusion to have the i-exten in another level
execute?

I think I would prefer to implement the same logic to T and not
implement the same logic to the i,t,o,a extensions.
Or to simply implement it the way it is now in the patch, for the h
exten only.

Thoughts?

>
>> Or speak out if this is not a bug, so I can drop this...
> Bueller?  Bueller?  Bueller?  Bueller?
>
> -Tilghman
>
> --
> _____________________________________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-dev


-- 
Johan Wilfer                 email: johan at jttech.se
JT Tech | Developer          webb: http://jttech.se