This page is part of Setman.
The first important issue is defining the xml format. The idea is that this project would host xml files with hundreds af settings so it's important define the format properly with an xml schema.
Let's have a look at the xml format right away. This code defines a simple registry setting:
<setman> <UserSettings> ... <Explorer> <setting name="HideFileExt" longname="Hide file extensions for known file types"> <description>The default value 'Enabled' is confusing and have security issues. Should always be disabled</description> <method type="reg"> <reg hive="HKCU" subkey="Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced" valuename="HideFileExt" valuetype="REG_DWORD"/> </method> <values type="reg" current="Disabled"> <val name="Disabled" data="0"/> <val name="Enabled" data="1"/> </values> </setting> ... </Explorer> ... </UserSettings> ... </setman>
This snippet describes the notorious
in the registry. The format is pretty self-explanatory. The
type="reg"> node describes that it is a registry
<values type="reg" default="Disabled"
current="Enabled"> node lists the possible values
and their names as well as specifies the OS-default value and of
course the value to be set. Another obvious type would be
type="srv"> to control the startup type of system
But of course the above does little more than a .reg file with comments would do (except for the possibility to export). The interesting part begins when we want to combine settings.
Let me state the obvious issue here right away: Settings can conflict. And since many settings are undocumented, it is not possible to extend the format above to provide foolproof combinations of settings. And filling up the file format with all sorts of dependency information completely breaks a principle goal of keeping it simple - as human readable documentation. This issue is intended to be solved by providing good documentation in the xml files.
However, combinations are necessary. If we're not able to change the WinXP performance setting, 'Adjust for best performance' or 'Adjust for best appearance' which is comprised of many individual registry settings, then it's hardly worth the effort.
The solution is this:
<setting name="ACombinedSetting"> <method type="combined"/> <values type="combined" current="CombinedValue2"> <val name="CombinedValue1"> <subval setting="BasicSetting1" value="Enabled"/> <subval setting="BasicSetting2" value="Enabled"/> </val> <val name="CombinedValue2"> <subval setting="BasicSetting1" value="Disabled"/> <subval setting="BasicSetting2" value="Disabled"/> </val> </values> <combinedsettings> <setting name="BasicSetting1"> ... </setting> <setting name="BasicSetting2"> ... </setting> </combinedsettings> </setting>
It introduces a new
that handles combinations.
This allows the setting ACombinedSetting to be composed of BasicSetting1 and BasicSetting2 in all possible ways and still keeps the overhead to a minimum. It also allows mixing different types of settings, like registry and services settings. It even allows arbitrary nesting of (combined) settings but that is not encouraged from a simplicity view point.
The values specified in subval nodes will override possible values in settings inside combinedsettings.
Disabling a setting is as simple as
type="combined" current="">. This would cause the script to
ignore the setting and thereby any nested settings.
Comments on the format presented above and the project in general would be greatly appreciated. Please write to the mailing list or me personally if you have any comments or ideas. And if you're interested in participating in the project you're most welcome. For example, I have little experience with xml schema's so I could probably use some help there.
Morten Odgaard firstname.lastname@example.org
Setman project page on Sourceforge
View mailing list