[asterisk-dev] Asterisk 1.6 Realtime Database must use ', ' not '|' in appdata field?

Russell Bryant 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
>> bug?
> 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.

Russell Bryant
Senior Software Engineer
Open Source Team Lead
Digium, Inc.

More information about the asterisk-dev mailing list