|The WEB servers such as IIS
usually keep most of their configuration in a central storage -
metabase, configuration files set, system's registry etc. ALP on the
other hand keeps only a few general settings in a global storage
(global means machine-wide configuration) and a default configuration.
The default configuration is used only to supply settings for the
options not specified by the particular applications explicitly. So,
the major part of the ALP configuration is specified as part of the
applications built for ALP and not in some kind of centralized
storage. The developers should not change the ALP defaults in its
installation directory in order to preserve the factory default ALP
behavior - all the specifics an application may need can be specified
within the application itself so there is no need to deal with the
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
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
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
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 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
- 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
A formal example:
If we have:
in the global and
in the local will produce effectively:
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.