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

[Tilghman Lesher]

On Mon, Mar 12, 2012 at 4:51 AM, Johan Wilfer <lists at jttech.se> wrote:
> 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?

I would prefer not to mess with it.  The problem is that some of these
extensions work differently (have different defaults) when the
extension does not exist.  So the bubble-up implementation of the "h"
extension would significantly interfere with those defaults, should
those extensions not exist at the top level.

With a lack of people needing the functionality, it simply isn't worth
the risk of introducing greater bugs.

-Tilghman