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

[Johan Wilfer]

2012-03-12 14:45, Tilghman Lesher skrev:
> 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.

Agreed. I only wanted to bring this up in case someone felt otherwise.

The patch is tested with 1.8 and it's working. I think it should be
applied to 1.8 and forward



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