[asterisk-dev] application argument delimeters

[Tilghman Lesher]

On Tuesday 24 July 2007, Russell Bryant wrote:
> It certainly does seem better to settle on a syntax and not do any magic
> character conversion internally for delimiters.  However, another part of
> me is still uncomfortable with the change in regards to the vast number of
> existing dialplans that will no longer work.  Furthermore, there is a vast
> amount of example dialplan around the internet that will no longer be
> correct.

Fortunately, I think most people have avoided the escaping up until now,
mainly because there were few reasons to use it.  func_odbc is one reason
now that escaping will become more commonplace.  The only escape that
people currently use is this:

Set(CALLERID(name)=Some Company\, Inc.)

and while this will change to:

Set(CALLERID(name)=Some Company, Inc.)

it isn't really that big of a deal to send a backslash as part of a callerid.
At worst, it's an annoyance that is easily fixed.

Oh, one other case, too:  needing to encode a semicolon into a SIP
header.  That syntax won't change.

> It has always been a value of this project to put forth a best effort to
> maintain backwards compatibility.  In the cases where we decide not to
> maintain compatibility, it has been done over a two release cycle.  The
> first one has marked a given option or syntax as deprecated, with
> appropriate warning messages any time they are used.

The problem with this isn't a change which can really work with backwards
compatibility.  Either you triple escape certain things or you don't, and
trying to manage both is a recipe for ensuring that things that should work
fine once the transition is complete won't.  As I commented on an earlier
thread about this change, it's a flag day event, and there's no getting around
that.

The motivation is to get this changeover done as quickly and as soon as
possible.  The longer we delay, the more pain this transition will cause.

> Don't get me wrong, I am all for simplifying configuration.  I just want to
> be really sure that we don't fix one problem by creating a bigger one. 
> Also, I want to put forth a best effort to ensure that the upgrade path is
> as simple as possible.

I honestly think the previous situation was untenable, at best.  Making the
dialplan easy to work with is a good long-term goal, and that's really what
this change was all about.  The essential problem with the previous situation
is that you needed to really understand the internals of Asterisk and how each
level, in turn, needed its own escapes, before you could create a working
dialplan (which included literal commas) on the first try.

I am certainly one of the people who can do that, but I've encountered a good
portion of users of func_odbc who cannot.  Blitzrage, JMLS, and several others
have repeatedly thought they had found bugs in func_odbc, and I was able to
show them the right number of escapes to give them the desired results without
changing the source.  The non-intuitiveness inherent in forcing people to ask
experts how to correctly formulate dialplan such that it works properly is not
sustainable.

That said, I've found a few edge cases where it would have been better to
encode triple backslashes directly into source to get the dialplan to behave
properly, and that's also completely insane.  We want people to be able to do
complex stuff without needing to be Asterisk developers themselves -- it
allows the developers to go on to create greater things, and it permits users
to stay blissfully ignorant of things they really didn't want to learn anyway.

-- 
Tilghman