What dictates this decision? ALP resembles a WEB server functionality and supports virtual ALP sites which have almost the same role as the virtual WEB servers maintained by the most WEB server software products. The virtual ALP sites are isolated from each other and as you have learned in ALP URL chapter they in fact split the local machine's file system in many virtual ALP sites. Thus for ALP the file system looks much like some kind of intranet with many sites. The applications that run in these sites may need quite different ALP configurations and thus each site may include different settings ALP will obey when it runs the applications in it. Furthermore ALP is designed with physical location independency in mind. Therefore the applications built for ALP should be able to run from any physical location in the computer's file system without need of any re-configuration. Thus the ALP configuration implementation relies on configuration files placed within the application directory structure, so that when the user moves the application's directory tree from one place to another the configuration is moved with it. A centralized configuration storage like in the case of a WEB server would not be suitable for ALP as it will would contain some full physical paths that will need to change if certain application or part of it moves.

This architecture is designed this way mostly to support the applications deployment. Thus the developer does not need to be concerned about the actual location where the application will be installed on the users' machines which considerably simplifies the setup/distribution process of the applications built for ALP. 

The configuration files

ALP uses 3 different types of configuration files. In theory it is possible to combine all the settings in one file, but we split them in 3 files to avoid the need to read all the settings in some of the cases when ALP needs them. For example in ALP URL you have learned that ALP determines the virtual ALP site boundaries by the mere existence of an alp.site file in a particular directory and treats this directory as a root of a virtual ALP site even if this file is empty. This is very important to maintain good performance because ALP needs to determine these boundaries quite often. For example in Internet Explorer or ALPFrame browsers you may have displayed a HTML content with hundreds of links. Each time the user moves the mouse over a link ALP needs to supply information about the URL so that the browser can display it in the status bar or perform another helper action. If it was necessary to read the entire configuration each time when the user moves the mouse over a link it would have decreased the browser performance drastically.

ALP uses the following configuration files:

ALP Site - alp.site. These files define the virtual ALP sites boundaries (the file existence is enough for that), contain a few optional virtual site-wide settings and may contain an ALP developer license which applies to this virtual ALP site.

ALP Application - alp.application. These files define the boundaries of particular ALP Application. The term ALP Application in this case is used to specify a logical part of an virtual ALP site that uses shared Application and Session objects and single set of ALP application settings.

ALP Directory - alp.directory. These files define some general processing settings for the files in the directory and its sub-directories up to the next sub-directory which contains its own alp.directory file (if any). The settings include default documents (files processed by default if the URL contains no file name), unattended execution protection and a few other settings that the developer may want to change in particular areas of the logical ALP application (see above).

All the files are text files that use the UDS text format which is described in ALP oriented fashion in the ALP configuration files syntax chapter. The developer does not need to edit these files manually - knowing about their existence and role is enough - the rest of the work can be done through the ALP Settings shell extension which extends Windows Explorer with ALP configuration editing capabilities.

The defaults (global) and the application specific (local) settings

As we mentioned above ALP keeps default settings for all the major options the developer may set on Virtual ALP site and ALP Application specific scope. This allows the developer to not specify all the options explicitly and rely on the defaults instead. However the ALP Settings shell extension usually generates all the options explicitly when you generates new ALP application settings or ALP directory settings which is additional guarantee that the application will work correctly everywhere - even if the ALP defaults are corrupted to some extent (you can call this a paranoid feature).  

The ALP defaults are called also global ALP engine configuration. They are kept in files with the same names as the files mentioned above. I.e. there is one alp.site, one alp.application and one alp.directory file that contain the ALP defaults. The file names are the same as the names of file that keep the local application specific settings in order to make it easier to determine each file's role when needed. The global ALP configuration files are located in the ALP installation/distribution directory. You can identify this directory most easily by the existence of the core ALP DLL in it - iewebsrv.dll. 

In ALP autorun distributions the ALP engine is usually located in a subdirectory of the distribution package and these files are there - in the same directory where the iewebsrv.dll resides as in the case of ALP installation. 

The effective settings

ALP determines the effective settings for each configuration type (virtual ALP site, ALP Application, ALP directory) by traversing the path specified in the URL back. It looks for Virtual ALP site settings (alp.site file) back to the drive root if no virtual ALP site definition is found the defaults apply. For ALP application (alp.application file) and ALP directory (alp.directory) settings the ALP engine looks back to the virtual ALP site root but not further. for each of them the defaults apply if no settings are found.

When ALP finds settings of one of these types it loads them and merges them with the defaults so that the settings specified in the local file (found in the URL path) override the defaults. Whenever an option is missing in the local settings the default option applies. In other words ALP implements two level inheritance: defaults->local settings and the local settings have priority over the defaults wherever a particular option exist in both local and default settings. 

Settings override mechanism detailed 

You may need to look into the ALP configuration files syntax for some terms. Generally only developers who want deeper understanding of the ALP configuration who intent to edit it manually need to read this section. The ALP Settings shell extension provides the developer with easy to use access to the configurations sufficient for almost all the possible scenarios except cases in which custom scripting language is used (not VBScript or JScript) and a few other rare scenarios.

The terms used: local configuration is one of the 3 types of configuration (alp.site, alp.application or alp.directory) found in the application's directory tree which applies to a given URL. The global configuration is the ALP default settings kept in the files with the same names in the ALP installation/distribution directory (see The defaults above).

• If the setting - section or record exists in local configuration, but does not exist in the global configuration it will present in the resulting effective configuration.
• If a section exists in both local and in the global configuration it will not be entirely replaced by the section existing in the local configuration. Instead the section from the global configuration will appear and only the records specified in the local configuration will replace the original ones or will be added if they do not exist in the global configuration.
• Records - are replaced by their versions in the local configuration if they exist in both configurations. If they exist in only on of the configurations they appear in the effective configuration.

A formal example:

If we have:

{ Section:
  (int)rec=1
} Section;

in the global and

{ Section:
  (int)rec=2
  (int)rec=3
} Section;

in the local will produce effectively:

{ Section:
  (int)rec=2
  (int)rec=3
} Section;

In most cases values with equal names (i.e. records with many values) are used to define lists. When configurations are mixed local list overrides the global one.

To see a dump of the effective configuration for a given URL use alpdump://<the URL> instead of alp://<the URL>. For example to see what configuration settings apply to alp://c:/mydir/myfile.asp replace the URL in the address bar (in ALPFrame right click the window caption and select "Go to URL" from the system menu) with alpdump://c:/mydir/myfile.asp.