On Wed, 2003-07-02 at 01:44, Mark E. Mallett wrote:
Perhaps some of the confusion is that it looks like you are using groups as a way both to encapsulate a group of settings and as a way to override inheritence of global settings. While those things are similar it's hard to generalize them by way of nested statements.
Yes .. Well, currently there's only auth group which encapsulates settings. Although it also allows overriding global settings :) That's a bit messy. You have to be able to define multiple auth processes - how would you show that they work differently? Another similiar thing is namespace configuration which I'll add later.
At any rate perhaps a different way to accomplish parameter grouping would be to define templates and invoke those templates within scoped declarations, e.g.:
Ah, yes :) That could be better. More powerful and probably easier to understand as well.
I could imagine implementing a "template" as a set of context-free tag/value pairs. When invoked (e.g. via "like") the parser would simply note the reference to the template, and eventually parse the tag/value pairs when the scope is closed, applying those that had not already been specifically set.
It probably should also be possible to add some subgroups in it .. Such as:
template modular_imap { protocol imap { mail_use_modules = yes } }
server a { like modular_imap }
Anyway, I think we'd still need to have everything default to root-level definitions. So that I wouldn't need to add "template standard {" to beginning of config file. And add "like standard" to every server definition. Also good for backwards compatibility..
But template certainly replaces the old "group".