Dear Paul,
many thanks for the nice words.
Let's start with the package parameters: Parametrization can be done already in multiple (too many?) ways.
- In general, all package parameter can be overloaded in the configuration file of NaviServer (see e.g. [1]). So, every nsd instance might have different settings depending on the configuration file. Overloaded means, that this value is fixed for this instance.
- In case you want to initialize the parameters differently for some instance, on case use the .xml files (see e.g. [2]), which can be used the set various settings (not only parameters), when a package is installed. It can be certainly customized for certain sites.
- For the xo* packages, there are further means, site-wide parameters and parameter pages. In xowiki/xowf there are default values, which are used whenever such a package is newly instantiated (i.e., adding such a package to a course, etc.). These are set via the "site_wide_package_parameters".
- If some of these instances should have a certain combination of parameters set, this can be further refined via parameter pages (which are FormPages (attribute/value pairs with a user interface). With parameter pages one can provide a certain subset of the parameters, on can define access/modification rights to these, and can keep a central place, where one can maintain all such values from a single place.
So, depending on your needs, different mechanisms might fit better.
Concerning overloading/modifying procs. Normally, the best thing would be not having to change the procs, but to provide sufficient parametrization for all needs (which is probably not possible either). When seeing some needs, post these to forums or make feature requests via the bugtracker would be the best.
When you have to overwrite code, it is often useful to define your own separate files loaded after the files from the distro. However, this requires certainly checks, when the overloaded procs are changed, since similar changes are required as well in your modified code clones. In practice this is often easier than doing complex merges. The xo* code supports mixin classes, which allow fine granular overloading on the fly without altering the code.
When altering code is still needed, providing a proper setup of the code repos can ease maintenance significantly. We use git (essentially a checkout of OpenACS from github with local branches), which is a longer story (Maybe Hector can sum this up, when he is back from vacation).
Hope this helps,
all the best
-g
[1] https://bitbucket.org/naviserver/naviserver/src/c7611641e17a090a7de08ea83bf0bac5802e8e32/openacs-config.tcl#lines-613
[2] https://github.com/openacs/dotlrn/blob/oacs-5-10/install.xml
