[asterisk-dev] (not so) new format for zapata.conf

[Kevin P. Fleming]

Tzafrir Cohen wrote:

> This is a bit simpler than the current zapata.conf syntax, but still
> badly location-sensitive: in the above example it would be preffered if
> user2 won't magically inherit the callerid settings from user1.

Yuck. I was not aware this was the case.

> 1. Use the patch from http://bugs.digium.com/view.php?id=7877 to allow
> sections not to affect one another.

Agreed.

> 2. The [channels] section of zapata.conf and [general] section of
> users.conf will be processed as before. However after processing them,
> each users.conf section processed will use a copy of the original
> configuration from after (1). See the todo comment in the end of
> http://bugs.digium.com/file_download.php?file_id=12805&type=bug ).

This sounds like a good plan... don't let settings 'leak' into entries
created by users.conf.

> 3. The parser will scan zapata.conf itself for extra configurations
> sections with the same format (any name beginning with "channel", any
> name that is not "trunkgroups" or "channels"?) and will process them the
> same way at the users.conf sections are processed.
> 
> Implementing (3) is simple: just an extra loop in setup_zap, similar to
> the one scanning users.conf . The patch linked above already simplifies
> things by making the keyword "zapconf" behave like "channel" (actually 
> generate a channel) but the processing is only done at the end of the
> section.

I don't think 'zapconf' is a good name, it never should have been
chosen. I'll speak to whoever chose that name... Is there any reason you
can't just re-use 'channel' within a [named] block? You can
differentiate them by using 'channel =>' in [channels], and 'channel ='
in named blocks.