[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.
DELIMITER=|
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