also sprach Steve Edwards <asterisk.org at sedwards.com> [2015-05-16 23:22 +0200]:> I use a preprocessor > (http://software.hixie.ch/utilities/unix/preprocessor/) to tailor > dialplans and configuration files to each host based on the client > (or project) and the hostname.Yeah sure, templating works, but it introduces a layer of complexity that can make debugging hard(er). I just had the following alternative ideas. - when #include parses a file, prefix all stanzas found therein with text derived from the path, e.g. * #include foo/extensions.conf ? "foo-" * #include bar.conf ? "bar-" * #include foo/bar/moo.conf ? "foo-bar-moo-" - if e.g. a context includes another context using a path separator, then the [common] context is looked up in a different location: * include foo/common ? "foo/extensions.conf" * include foo/bar/common ? "foo/bar/extensions.conf:foo/bar.conf" The same logic could be applied e.g. in the arguments of the Dial() application or local channels or registry instructions in sip.conf. The first is probably easier to implement, while the second is clearer to the user. Is this something to consider? -- @martinkrafft | http://madduck.net/ | http://two.sentenc.es/ "when faced with a new problem, the wise algorithmist will first attempt to classify it as np-complete. this will avoid many tears and tantrums as algorithm after algorithm fails." -- g. niruta spamtraps: madduck.bogus at madduck.net -------------- next part -------------- A non-text attachment was scrubbed... Name: digital_signature_gpg.asc Type: application/pgp-signature Size: 1107 bytes Desc: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current) URL: <http://lists.digium.com/pipermail/asterisk-users/attachments/20150517/73276040/attachment.pgp>
On Sun, 17 May 2015, martin f krafft wrote:> also sprach Steve Edwards <asterisk.org at sedwards.com> [2015-05-16 23:22 > +0200]:>> I use a preprocessor >> (http://software.hixie.ch/utilities/unix/preprocessor/) to tailor >> dialplans and configuration files to each host based on the client (or >> project) and the hostname.On Sun, 17 May 2015, martin f krafft wrote:> Yeah sure, templating works, but it introduces a layer of complexity > that can make debugging hard(er).While preprocessing could be called 'templating,' this may be confusing because Asterisk already as a configuration file feature called 'templates.'> I just had the following alternative ideas. > > - when #include parses a file, prefix all stanzas found therein > with text derived from the path, e.g. > > * #include foo/extensions.conf ? "foo-" > * #include bar.conf ? "bar-" > * #include foo/bar/moo.conf ? "foo-bar-moo-" > > - if e.g. a context includes another context using a path > separator, then the [common] context is looked up in a different > location: > > * include foo/common ? "foo/extensions.conf" > * include foo/bar/common ? "foo/bar/extensions.conf:foo/bar.conf" > > The same logic could be applied e.g. in the arguments of the > Dial() application or local channels or registry instructions in > sip.conf. > > The first is probably easier to implement, while the second is clearer > to the user.And you find preprocessing/templating complex?> Is this something to consider?I don't think so, primarily because it is specific to your problem. The audience is too small. Let's take a closer look at preprocessing using the preprocessor I referenced above to make sure I understand your needs. If we had extensions.conf.pre containing: #filter substitution #define PREFIX a #include generic.conf.pre #define PREFIX b #include generic.conf.pre # (end of extensions.conf.pre) (Note that '#include' is seen by the preprocessor, not by Asterisk's configuration file parsing code.) and generic.conf.pre containing: [@PREFIX at -long-distance] exten = s,1, verbose(1,[${EXTEN}@${CONTEXT}!${ANI}]) #if PREFIX==a same = n, verbose(a specific code) #endif same = n, hangup() # (end of common.conf.pre) we could process these files with a command like: ./preprocessor.pl extensions.conf.pre >/etc/asterisk/extensions.conf which would create extensions.conf containing: [a-long-distance] exten = s,1, verbose(1,[${EXTEN}@${CONTEXT}!${ANI}]) same = n, verbose(a specific code) same = n, hangup() [b-long-distance] exten = s,1, verbose(1,[${EXTEN}@${CONTEXT}!${ANI}]) same = n, hangup() This lets you write generic contexts that will be prefixed as well as 'tailor' code specific to the value of the prefix. Isn't this what you're looking to accomplish? Also note, the 'real' extensions.conf contains no additional complexity so it is as easy to understand and maintain as you want it to be. -- Thanks in advance, ------------------------------------------------------------------------- Steve Edwards sedwards at sedwards.com Voice: +1-760-468-3867 PST Newline Fax: +1-760-731-3000
also sprach Steve Edwards <asterisk.org at sedwards.com> [2015-05-17 08:31 +0200]:> While preprocessing could be called 'templating,' this may be > confusing because Asterisk already as a configuration file feature > called 'templates.'Fair point. Preprocessing it shall be.> And you find preprocessing/templating complex?Hehe. The difference is that e.g. when encountering a problem, in your situation one always has to look at the preprocessor output, identify the issue, and then translate it into a fix in the input. Whereas with hierarchical includes, the files you edit are the same files Asterisk reads and hence this can be taken into account e.g. in log messages etc.> >Is this something to consider? > > I don't think so, primarily because it is specific to your > problem. The audience is too small.You know the Henry Ford quote about faster horses, right? ;)> Let's take a closer look at preprocessing using the preprocessor I > referenced above to make sure I understand your needs.[?]> This lets you write generic contexts that will be prefixed as well > as 'tailor' code specific to the value of the prefix. Isn't this > what you're looking to accomplish?Yeah, and it's nicely done. Arguably it's still a hack and debugging becomes an indirect process (see above). But sure, it'll probably be the best solution for now. ? although I believe Asterisk would benefit from better namespace separation between sets of registrations/contexts. -- @martinkrafft | http://madduck.net/ | http://two.sentenc.es/ "you raise the blade, you make the change you rearrange me till i'm sane. you lock the door, and throw away the key, there's someone in my head but it's not me." -- pink floyd, 1972 spamtraps: madduck.bogus at madduck.net -------------- next part -------------- A non-text attachment was scrubbed... Name: digital_signature_gpg.asc Type: application/pgp-signature Size: 1107 bytes Desc: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current) URL: <http://lists.digium.com/pipermail/asterisk-users/attachments/20150517/d1db583e/attachment.pgp>