[asterisk-dev] Case-sensitivity of Dialplan variables.

[Julian Lyndon-Smith]

I vote for case-insensitive anywhere

I may be in the minority, but I have _never_ understood the reasoning
behind variables with the same "name" but with different case would
have different meanings or contents.

Yes, I have been fighting Javascript recently ;) One of the biggest
bugs I found in my code was that I had a variable called LastCallDate
and mistyped it as LastCalldate somewhere further down the line.

aargh.

:)

On 1 October 2012 17:56, Mark Michelson <mmichelson at digium.com> wrote:
> Hi!
>
> I've been confronted with an interesting issue to resolve. The
> issue is located here:
>
> https://issues.asterisk.org/jira/browse/ASTERISK-20163
>
> The issue involves case-sensitivity of channel and global variables
> in the dialplan. Current behavior is as follows:
>
> 1) Variables created in the dialplan by users are case-insensitive.
> Thus if the variable MARK were set, then ${MARK} and ${mark} would
> both evaluate to the set value..
>
> 2) Variables used internally by Asterisk are case sensitive. So if
> some application set a variable called MARK, it would be different
> from a variable set by some application called mark.
>
> First off, this inconsistency is just weird. It would be much easier
> to just have things work one way or the other, not to have this mix.
>
> In addition, this can lead to some awkward situations. Consider that
> someone wants to use a specific SIP codec and so they set the
> variable SIP_CODEc to be "g722". Notice that the final 'c' is
> lowercase, presumably due to a typing error. The option would not
> take effect because chan_sip specifically checks the value of the
> case-sensitive ${SIP_CODEC}. What makes this weirder is that if
> the dialplan writer were to check ${SIP_CODEC} in the dialplan
> using a NoOp or Verbose call, then he would see the variable set
> to the value he set it to when he set ${SIP_CODEc} because the
> variable substitution is case-insensitive in the dialplan. This
> makes debugging the problem difficult.
>
> I propose that dialplan variables need to be made consistent in their
> evaluation. We need to choose either to be always case-sensitive or
> always case-insensitive. The problem is, I don't know which of these
> changes would have a larger effect on people. This is where I would
> like your feedback. Which way should it go?
>
> Some of you might be eager to propose a configuration option to
> decide which it should be. I'm sick of having hundreds of options
> in Asterisk to slightly tweak the behavior one way or another. This
> needs to go one way or the other, not be configurable.
>
> What I plan to do, no matter which way the vote goes, is to document
> on the wiki how things currently behave in Asterisk, to include the
> example I gave above (or something similar anyway). Depending how
> the vote goes, I will make the necessary code changes in Asterisk
> trunk. I will document the behavior change both in UPGRADE.txt and
> on the wiki.
>
> When considering which way you lean, consider that we really don't
> have much of a precedent to go on. For instance, dialplan applications
> are case-insensitive ("answer" and "Answer" and "ANSWER") are all the
> same. Dialplan functions, on the other hand, are case sensitive
> ("HASH" would be evaluated properly but "hash") would not. My personal
> opinion is that all variable evaluations should be case-sensitive.
> I don't feel all that strongly about it though and could easily be
> swayed the other way if people respond overwhelmingly in opposition.
>
> So respond here and let me know what you think. Also let me know if
> this should be posted on the -users list.
>
> Mark Michelson
>
> --
> _____________________________________________________________________
> -- 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



-- 
Julian Lyndon-Smith
IT Director, Dot R Limited

"I don’t care if it works on your machine!  We are not shipping your machine!”

The kangaroo dances: http://www.youtube.com/watch?v=MAWl5iYOaUg