[Home]

Summary:ASTERISK-04221: [patch][post 1.2] ALIAS
Reporter:Anthony Minessale (anthm)Labels:
Date Opened:2005-05-18 16:58:05Date Closed:2011-06-07 14:05:07
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Functions/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) app_dpmacro.c
Description:This function lets you take obscene dialplan logic and give it a name so you can call it like a macro

EXAMPLE:

{dpmacro.conf}:

[macros]
mymacro => ${IF( $[ (${ARG1}) = "hello" ] ? yay : "no way")}

{extensions.conf}:

exten => 1000,1,Verbose(OK ${DPMACRO(mymacro val1:val2:val3)})
This will evaluate to "no way"

exten => 1001,1,Verbose(OK ${DPMACRO(mymacro hello:val1:val2:val3)})
This will evaluate to "yay"


 -= Info about function 'DPMACRO' =-

[Syntax]
DPMACRO(<macro> arg1:arg2..argn)

[Synopsis]
Dial Plan Macro

[Description]
Cache expressions in dpmacro.conf and evaluate them by name from the dialplan.
e.g. mymacro => ${IF( $[ ${ARG1} = hello] ? yay : "no way")}






****** ADDITIONAL INFORMATION ******

Disclaimer on file:
anthmct@yahoo.com

Comments:By: Mark Spencer (markster) 2005-05-19 13:48:38

USERF or UF or USERFUNC?
By: Tilghman Lesher (tilghman) 2005-05-20 15:52:29

How about "ALIAS"?
By: Tilghman Lesher (tilghman) 2005-05-20 15:55:37

Also, I don't really see the point of having another file in which we store dialplan logic.  Why not just allow the definition anywhere in an included extensions config file, as tagged by "alias =>" ?  We might even separate aliases into different contexts and use the include logic to determine which
aliases are active at any one time.
By: Leif Madsen (lmadsen) 2005-05-20 16:51:36

I agree about not putting this in another configuration file. Why don't you keep it in a familiar format like the macro's. So maybe to take Corydon's suggestion and merge it with something like this...

[alias-dpmacro]
alias => ${IF( $[ (${ARG1}) = "hello" ] ? yay : "no way")}
include => alias-dpmacro2

...or something like that.
By: Tilghman Lesher (tilghman) 2005-05-20 17:15:25

No, no, I meant keeping them inline with normal contexts, not defining special contexts, like Macro does:

[default]
alias => whatever,${IF($[${ARG1}) = "hello"]?"yay":"no way")}

exten => s,1,Alias(whatever hello:foo:goo:moo)
By: Michael Jerris (mikej) 2005-05-21 08:53:18

I vote "script".
By: Leif Madsen (lmadsen) 2005-05-21 10:39:43

Corydon: yah, I do like that syntax. However, how do you use a dpmacro you've defined in one context, in another context?
By: Tilghman Lesher (tilghman) 2005-05-21 11:40:00

blitzrage:  by using the existing "include => context" functionality.  That makes it nice and consistent across the dialplan.  You could even used the timed includes to have different aliases (same names) called during different times.  I'm not really sure of the application where you'd want that, but then again, stuff always gets used beyond what the original programmer intended.  :-)
By: Leif Madsen (lmadsen) 2005-05-21 11:43:29

Aha! You're right, regular include => would work. Need more sleep I guess :)
I really like this idea.
By: Michael Jerris (mikej) 2005-05-21 12:37:15

as long as you could include them in global, as well as an included file, that seems good to me.
By: Michael Jerris (mikej) 2005-06-19 10:45:55

Is there any consensus on how this should be?  Mark-  Let's not let this one rot, what would you like to see and let's get this in.
By: Michael Jerris (mikej) 2005-06-23 06:38:30

kevin-  This needs to go in one way or another.  Can you get a definitive word on what needs to be done on this so it can go in please?
By: Michael Jerris (mikej) 2005-06-23 13:44:26

From dev conf, name "ALIAS", put it in pbx.c.  Have pbx_config load it.  mark says bonus points if you want to make ael load it too.
By: Michael Jerris (mikej) 2005-07-25 22:01:48

tony-  Were you planning on doing the updates we discussed on the dev call on this one?
By: Kevin P. Fleming (kpfleming) 2005-08-22 16:19:26

This can go into 1.2 if it gets updated in time (in the next week or so).
By: Anthony Minessale (anthm) 2005-09-07 09:15:01

I can live with the name change but I feel strongly against the idea of moving it into pbx.c  It's considered a good thing that the functionality is purely loadable, if I choose to noload this module....I dont have the feature, that is the whole point of modules.  if having it work in AEL is a bonus then leave it the way it is and it will already work.  If this is unacceptable let me know I can just move it to PBXFreeware.org
By: Tilghman Lesher (tilghman) 2005-12-01 14:58:07.000-0600

anthm:  it wouldn't go into pbx.c; it would go into pbx/pbx_config.c, as it would be integrated with extensions.conf.  If you're not willing to do this, we can suspend this bug and revisit it at a later time.
By: Anthony Minessale (anthm) 2005-12-01 19:16:48.000-0600

This module uses it's own scope to store the macros it doesn't add it to the dialplan structures so that is a little more than a minor change.  Why are we integrating it into the core again? someone refresh my memory. What happend to Keep it Simple?  Seriously I am not picking a fight or anything I just want to know what is wrong with keeping things modular the core is already about to explode from bloat what's wrong with it the way it already is? it's worked perfect for 5 months.
By: Anthony Minessale (anthm) 2005-12-02 12:17:23.000-0600

OMG you people and your egos.. Let the record show this bug was closed with no reply to my polietly asked question for no reason other than spite....Why don't you guys change it yourselves and break it like all the other things I make that get "fixed" when they are committed?
By: Tilghman Lesher (tilghman) 2005-12-02 12:33:57.000-0600

anthm:  This bugreport is full of suggestions to change this patch to make it into the trunk.  If you're unwilling to make those changes, and we don't have anybody else willing to sit down and make those changes at this time, then the only sensible thing to do is to suspend the bug until someone is available to make those changes.

It's nothing personal, but leaving bugs open when the reporter is unwilling to make requested changes is nonsensical.  Features either move forward or they get closed.
By: Anthony Minessale (anthm) 2005-12-02 15:18:42.000-0600

The suggestions are made from a high level point of view with no consideration for how much more work it entails.  akin to "Lets fix the codecs by making them not use a bitmask anymore!"  The suggestions could not be fullfilled without altering the entire extension data tree to accomidate the aliases which i still think are better named macros.  Suggesting these changes because you simply do not like many configuration files is not enough of a reason.
Please otherwise indicate that Asterisk is not a modular system and every feature is meant to to be devoured by the core or indicate that if I suggest A others will suggest B just for the fun of it. I can believe either of these reasons.