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

[Tzafrir Cohen]

On Tue, Jan 16, 2007 at 06:42:28PM -0600, Kevin P. Fleming wrote:
> 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.

The latest version of the patch (6) now implements that. Will work with
most settings. Some settings are still set globally (e.g.: progzone) and
I did not want to touch the code that sets them. Those are the left-over
static-s.

> 
> > 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 have not implemented that yet. I also don't understand why is the lock
to iflist being dropped before getting configuration from users.conf .

> 
> 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? 

I don't care about using either 'zapconf', 'chanconf' or 'channel'. What
I do care about is the semantics: don't generate a channel in the middle
of a section: only in the end.

If you want to give 'channel' a different meaning in the [channels]
section, just use the existing skipchannels flag passed to process_zap
and change its meaning a bit.

> You can
> differentiate them by using 'channel =>' in [channels], and 'channel ='
> in named blocks.

Hmmm.. is it possible at all? After parsing I only get key and value,
right? I don't think I'd like to break the current semantics all over
Asterisk that '=' and '=>' are equivalent.

-- 
               Tzafrir Cohen       
icq#16849755                    jabber:tzafrir at jabber.org
+972-50-7952406           mailto:tzafrir.cohen at xorcom.com       
http://www.xorcom.com  iax:guest at local.xorcom.com/tzafrir