[asterisk-dev] Asterisk 1.6 Realtime Database must use ', ' not '|' in appdata field?
russell at digium.com
Wed May 28 15:17:32 CDT 2008
Tilghman Lesher wrote:
> On Thursday 22 May 2008 12:51:36 JR Richardson wrote:
>> I'm testing 1.6 ARA. All seems to be functioning well, but Asterisk
>> does not like | (pipe) separators in the appdata fields in the
>> database. I don't think this is particular to ARA because I see the
>> same results when I use static extensions in extensions.conf also.
>> So I'm guessing pipe processing has been deprecated or possibly this is a
> Removed. Comma is what most people are used to using in extensions.conf,
> and has thus been made the authoritative delimiter.
I'd like to address something back at a very early point in this thread that I
don't think was made very clear from the beginning.
This change was _not_ made directly to Asterisk's database support. It was made
to make writing dialplans in general more straight forward. In my opinion, the
decision to support both ',' and '|' as a delimiter in the dialplan was a very
poor one. The internal conversion of ',' to '|' internally made for some very
confusing behavior. If you literally wanted a comma in the dialplan, you had to
do an illogical amount of escaping to get things to work correctly.
That really was a pain. So, one day, Tilghman proposed cleaning it up once and
for all. The work was done in the public, and was discussed on this list. The
result is much more predictable parsing of the dialplan.
A comma was chosen as the delimiter, as that was the most popular choice between
the | and ,.
Now, as was pointed out in this thread, the comma is a poor choice for the case
of realtime. Tilghman recognized this and wrote the compatibility mode to allow
pipes instead of commas. I was happy to see that this was done.
So, we're basically left with whether this change is appropriate for hand
written extensions.conf. In my opinion, given the nastiness that this change
cleared up, it is a justified and welcome change. The change does have
ramifications on compatibility, but that is exactly why the change was reserved
for a major version update, and is clearly documented in the UPGRADE.txt file
that is distributed with each major version upgrade.
However, everything in Asterisk is always up for discussion and is subject to
change. Given this information, if anyone would like to discuss this further, I
would be happy to, provided that the discussion stays sane and productive. :)
Some people hate illogical parsing and escaping rules. Some people hold
compatibility above all else, no matter how bad the situation is from a
technical point of view. With all changes, we have to find the magic balance
that keeps the majority happy, because without keeping a community of happy
users, we have no reason to be here.
Senior Software Engineer
Open Source Team Lead
More information about the asterisk-dev