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

[Michael L. Young]

----- Original Message -----
> From: "Vladimir Mikhelson" <vlad at mikhelson.com>
> To: "Asterisk Users Mailing List - Non-Commercial Discussion" <asterisk-users at lists.digium.com>
> Sent: Tuesday, October 2, 2012 9:02:18 PM
> Subject: Re: [asterisk-users] Case-sensitivity of Dialplan variables.
> 
> 
> On 10/1/2012 4:15 PM, Mark Michelson wrote:
> >
> > 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.
> >

 
> First you need to consider compatibility with currently supported
> packages which include auto-generated dial plans like AsteriskNow,
> PIAF,
> etc.  If you plan to break their functionality you need to at least
> coordinate your move with the maintainers.

This change would go into trunk, the development line of code.  So, I am not sure that a coordinated effort would need to be made here.  As with every major release, maintainers of external packages usually check the UPGRADE.txt.  There almost always will be something to change between major versions in order to keep in step with the new release.
 
> Then you may want to consider backwards compatibility with packages
> still widely used but not actively supported any more like Trixbox.
> Maybe not the best example as their WEB site says, "This is the
> current
> stable release based on Asterisk 1.6."

Again, I am not sure there is a need for backwards compatibility.  This change would go into Asterisk 12, which is not LTS.  I would think that most packages would be focused more on working with the LTS version of Asterisk.  I could be wrong though.  Given that Asterisk 11 is the current LTS that will be probably be released soonish out of beta, the next LTS version is a couple of years away giving plenty of time for people to make the necessary changes.
 
> If you really want to make it not settable (and this is big, not a
> minor
> change, if I were you I would definitely make it settable) then I
> would
> go with case-insensitive as it allows for various custom notations,
> e.g.
> Hungarian notation in naming of custom variables without a later
> painstaking investigation whether "nCallID" is equal to "nCallId" or
> not.  Consider the fact, most of the dial plan debugging happens in
> the
> logs or in the Console Screen.  Someone may want to spell "nCALLID"
> just
> to be able to see the difference between Latin "l" and "I" where the
> first one is "L" lower case and the second one is "i" upper case.

I didn't quite follow this logic.  Your example, in my mind, would actually be easier to debug with this change.

If you know that variables are case sensitive, you know that you have to check for a typo in your variable name if you are not getting what you were expecting. Here, in my email client, the "l" and "i" are very distinct as well as the console I work in.

Just my thoughts on the above concerns presented.

Michael L. Young
(elguero)