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

Paul Hewlett paul at gccs.co.za
Thu May 29 02:40:29 CDT 2008

Russell Bryant wrote:
> 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.
Why not have a global variable "DELIMITER" which is set to the delimiter 
of choice i.e.


or is the current code too complex to implement something llike that ?

Paul Hewlett

Technical Director, GCCS
Tel: 086 111 3433 Fax: 086 111 3520 Cel: 076 072 7906
web: http://www.gccs.co.za

More information about the asterisk-dev mailing list