Many thanks for the positive feedback! I have received two questions in this regard, i want to share: upfront variables and ordering
1) “where do upfront variables go?” Some sites use (e.g. for multiple (developer) instances upfront variables (Tcl variables), which are used to configure later sections. For this feature, we are planning a “standardized” hook for the bootstrap step, using a configurable parameter “setupfile”. This makes it also easy accessible via docker setups. If specified, it is intended for a small, instance-specific Tcl file that only sets variables (no ns_section). ns_configure_variables (in the bootup section) sources it after applying defaults + env overrides, so you can keep one shared configuration (or fragment directory) and vary only ports/paths/hostnames per instance. 2) Fragment ordering / do we need strict semantics? Technically, the only hard requirements are: Section 00 first (bootstrap/variables) and Section 70 last (final diagnostics). Everything else is an ordering recommendation to provide clear “places to put things” (parameters, network, runtime, DB, server blocks, …). If you concatenate the fragments in lexicographic order, you should get the same behavior as a single monolithic file — the sections are there to make structure and future splitting/maintenance obvious. Technically, all sections can be concatenated to a single file configuration file having the same semantics. The section organization is already documented and used by openacs-config.tcl [1]. All the best -g [1] https://raw.githubusercontent.com/naviserver-project/naviserver/refs/heads/main/openacs-config.tcl > On 23.01.2026, at 18: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
