Sounds good, helps a lot when config is big. Ordering lexically is also great so it can be manually controled what to load first.
On Fri, 23 Jan 2026, 16:59 Gustaf Neumann (sslmail), <[email protected]> wrote: > Dear all, > > Here is a proposal to introduce directory-based configuration loading for > NaviServer using > > nsd -t <directory> > > Key properties: > > * predictable lexicographic ordering > * improved maintainability for large configurations > * compatibility with both pure NaviServer and OpenACS deployments > * improved error localization > * alignment with established Unix configuration practices > > The feature is simple to implement, non-intrusive, and immediate useful > for complex deployments. > > Below are my design considerations. The goal would be to include this in > the NaviServer 5.1 release. > > Comments of all kinds are always appreciated. > > All the best > -g > > > --------------------------------------------------------------------------------------------------------------------------- > ## 1. Motivation > > NaviServer currently requires the `-t` option to reference a single > Tcl configuration file. Large installations (both OpenACS-based and > pure NaviServer setups) increasingly require splitting configuration > into multiple smaller files for: > > * improved readability and maintainability > * separation of defaults, parameters, modules, and per-server > configuration > * easier isolation of syntax errors > * smaller diffs and clearer version control history > * provide a mechanism to include/remove sections without file editing > * reuse of configuration fragments across multiple server instances > > At present, this requires explicit source logic inside a main > configuration file. This RFC proposes first-class support in > NaviServer for loading configuration from a directory, while > continuing support for single configuration files. > > ## 2. Proposed Feature > > Extend NaviServer so that the `-t` option accepts either: > > * a file (current behavior, unchanged), or > * a directory, interpreted as a configuration set. > > Example: > > nsd ... -t /usr/local/ns/conf/openacs-config.d > > This proposal is strictly additive and does not modify existing > file-based behavior. > > ## 3. Directory interpretation > > When the argument passed to -t is a directory, NaviServer shall: > > 1. Verify that the directory exists and is readable. > 2. Enumerate all files in the directory matching *.tcl. > 3. Sort these filenames lexicographically. > 4. Evaluate each file in order using the same Tcl interpreter used > for a single configuration file. > > Example directory contents: > > 00-bootstrap.tcl > 10-parameters.tcl > 20-network.tcl > 30-runtime.tcl > 40-db.tcl > 50-modules-global.tcl > 60-server-openacs.tcl > 70-final.tcl > > Load order: > > 00-bootstrap.tcl -> 10-parameters.tcl -> 20-network.tcl -> ... -> > 70-final.tcl > > Ordering is therefore explicit, predictable, and controlled solely by > filenames. > > ## 4. Variable scope and execution environment > > All configuration fragments are executed in the same global Tcl > interpreter used today for monolithic configuration files. > > As a result: > > * Variables defined in earlier fragments are visible in later fragments. > * `ns_section` declarations behave exactly as in a single-file > configuration. > * No special scoping rules or namespace changes are introduced. > > This preserves full compatibility with existing configuration logic. > > > ## 5. Behavior when `-t` is a file > > When `-t` refers to a file, behavior remains unchanged: > > nsd ... -t /usr/local/ns/conf/nsd-openacs.tcl > > * Only that file is evaluated. > * No directory scanning or fragment loading occurs. > > This ensures full backward compatibility and avoids unexpected behavior. > > > ## 6. Error handling > > If any configuration fragment loaded from a directory fails due to a > syntax error or runtime error: > > * The error SHALL be reported with filename and line number. > * `nsd` SHALL terminate startup with a non-zero exit status. > > This mirrors existing behavior for single-file configurations while > making error localization significantly easier. > > > ## 7. Logging behavior > > During startup, before sourcing each configuration fragment, `nsd` > SHOULD emit a log entry such as: > > ns_log Notice "nsd: sourcing config fragment: <filename>" > > This makes fragment ordering and loading behavior visible and debuggable. > > > ## 8. Naming recommendations (non-normative) > > While NaviServer does not enforce naming conventions, the following > scheme is strongly recommended: > > NN-description.tcl > > Where: > > * 'NN' is a two-digit numeric prefix controlling load order > * 'description' is a short, human-readable identifier > > Example: > > > 00-bootstrap.tcl > 10-parameters.tcl > 20-network.tcl > 30-runtime.tcl > 40-db.tcl > 50-modules-global.tcl > 60-server-openacs.tcl > 60-server-xotcl.tcl > 60-server-cvs.tcl > 70-final.tcl > > > This structure supports: > > * multiple server configurations > * OpenACS and non-OpenACS servers > * consistent ordering across installations > > > ## 9. Backward compatibility > > This proposal is fully backward compatible: > > * Existing configurations using `-t <file>` continue to work unchanged. > * Inline `source` commands remain supported. > * Directory-based configuration is opt-in and only activated when `-t` > references a directory. > > No existing configuration files need to be modified. > > > _______________________________________________ > naviserver-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/naviserver-devel >
_______________________________________________ naviserver-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/naviserver-devel
