Configure ALP

First we need to understand what is configurable in ALP and why. ALP acts much like a WEB server and many terms can be easily translated from the typical WEB development to their ALP equivalents. However there are slight differences which should be noticed. Let us begin with a few words about the typical structure levels of a WEB based software 

Sites, Applications, Directories and files. 

Usually in the WEB programming we recognize 3 levels of the structure: 1. WEB site 2. WEB application 3. WEB directory (often called virtual directory, but we will avoid this term because it carries some other meanings too). In fact these terms are not strictly defined in a general context except the "WEB site". Anyway, we are used to talk about them and talk about configuring "site", "application" and sometimes "directory" (sometimes even particular file settings). For example we can think of how to configure certain "WEB site" to answer requests sent to a given DNS name (e.g. www.yourdomain.com). Or we can think of configuring a "WEB application" to execute certain file extensions using certain WEB server modules or CGI processors. And finally we may want to allow or disallow the visitors to see the contents of certain directory in our WEB application or forbid/allow the execution of the configured files in it and so on..

Even without strict definition most WEB programmers think that the WEB site consist of one or more WEB applications, which in turn contain one or more directories (can be nested) where the HTML, ASP, PHP, Perl, image and the other files reside. If we take a look over the configuration tools/files of the most WEB servers we will see that the developers prefer those in which these divisions are clearly separated and can be configured separately. Apparently the hierarchy described above proved itself as convenient. Therefore ALP follows these general concerns.

Let say a few words about each one of them comparing the usual WEB server meaning with the ALP meaning of the term:

"WEB site" or "virtual WEB site" in ALP is most often refered as "virtual ALP site". It is very like a virtual WEB site on a WEB server, but there is a difference. In a WEB server the WEB site is defined as set of directories and their subtrees on the server (this may include virtual directories as well) and also as DNS name(s), and/or IP adress(es), and/or ports on which the WEB site will answer. The result can be thought as a consistent directory tree - the root is the site root/home directory and we may have many subdirectories under it with files and other subdirectories. In ALP everything occurs locally on the user's PC and thus no DNS name nor IP address or IP port make any sense. Thus in ALP the "ALP site" is defined just by the site's root directory and its subtree of directories. I.e. everything ALP engine needs to know in order to treat part of the file system as a virtual site is a physical path to the directory where the "ALP site" begins.

The "WEB application" definition often depends not only on the WEB server but also on the language/add-in/external CGI processor used to execute the application code. However the term is most often associated as execution settings that apply over certain subtree of the "WEB site". Sometimes the site and the WEB application overlap (i.e. we may assume the site consist of only one WEB application), but in other cases one WEB site contains several "WEB applications" more or less isolated from each other. When we talk about ASP (Active Server Pages) we should refer to MS IIS (Microsoft Internet Information Server). In it the application is defined in certain directory and affects by default the entire subtree beginning with that directory. The application settings define such things like which processor/extension will execute certain files (recognized by their file name extensions for instance), what MIME type will be reported for the files which are served without processing and so on. Aside of the configuration the very existence of the application defines a boundary that determine which files will share common Session and Application objects. So, the application's directory tree shares the same application settings and the ASP files in it have access to common Session and Application objects. Also the application may have (optionally) a global.asa initialization file in the directory where the ASP application starts. In ALP the things are much like in IIS, the "ALP application" is defined in certain directory and affects its entire directory sub-tree, the Application and Session objects are shared between the ASP files there and a global.asa file may appear in the directory in which the "ALP application" is defined. There are also MIME type mapping settings and other settings very similar to the other environments where the "WEB application" term is clearly defined.

The "WEB directory" is most often assumed to be part of the WEB application where certain restrictions apply over the basic actions the visitor may perform and also some default settings. The latter usually include the so called "default documents" i.e. the file that will be served if the URL do not include file name (i.e. the URL refers to the directory itself). The restriction settings usually include permission to list the directory contents (if no default document is found), execute scripts, execute programs etc. In ALP this may look a bit unneeded (except the default documents of course) but still it is supported for developer convenience. Furthermore ALP supports some additional settings intended to provide the developers with convenient protection mechanisms against potentially dangerous online content. The latter reflects the ALP specifics. ALP is like a WEB browser which can be thought as acting much like a personal WEB server as well. This means that the user may use the same browser to run local ALP applications and browse online content. Thus malicious users may be tempted to implement attacks against the local applications by redirecting the user to them from online pages, passing arguments that would cause the local pages to perform malicious tasks. The same technique can be used of user's benefit, but obviously it can be used to harm the user's machine. Thus the ALP applications must stand such attacks and ALP provides them with unattended execution protection that helps the developers implement protection without additional efforts. See ALP directory settings in ALP Settings shell extensions for more information.

Up to this point we described what is usually configured in a WEB development environment. An experienced developer or an administrator will note that the settings can be so much that without some help from the WEB server it will be really difficult task to define them all. Each environment provides some way to avoid such a huge work. Some environments allow settings to be copied and modified, others use default settings mixed with local settings (e.g. the default setting applies if the local configuration does not define a value for it), others use settings inheritance through the tree of the elements (e.g. think of hierarchy like this WEB server, WEB site, WEB application, WEB directory, WEB file). In ALP the first two methods are used - i.e. copying and mixing of default and local settings. If you are familiar with IIS you know that it is one of the environments that use also settings inheritance. Why ALP is not using such a mechanism? The answer is the next important point:

How the settings are kept. The WEB servers are usually installed on a server machine and even if more than one instance of the WEB server is active there is a need of synchronization between the instances that will keep the illusion that there is one WEB server on that machine. Therefore in the common case the WEB server settings are machine wide. In other words they define "what is served and how it is served to the world". The common practice is to keep the settings in a single global storage (like in IIS) or in several files which link to each other (like in Apache). This serves several purposes. One of them is speed - having all the settings collected we can cache them and serve all those thousands of visitors, also sometimes we may want to serve the same content with different settings and in IIS for instance this can be done by defining two or more virtual sites that serve the same physical paths. In ALP we have completely different situation. We have only one user (of course there could be several concurrent requests at the same time but we know for sure that they are only a few), we want to be able to copy the application to another place without troubling ourselves with reconfiguration. We may have separate ALP instances running independently of each other with completely different settings and it is even possible that these instances may run different versions of the ALP core files. This is the reason for the solution implemented in ALP. A comparison between IIS and ALP will be the best way to see the differences caused by the different needs: 

In IIS the settings are kept in a metabase - only one for the whole machine.
The ALP configuration is kept in a few special files which reside in the WEB site's directory tree.

The default settings in IIS, like the specific settings (for virtual site, application etc.) reside in the same metabase
In ALP the defaults are kept in files located beside the ALP engine's core DLL

When IIS site is copied, moved through the file system the metabase must be updated with physical paths for the new location.
In ALP copying a virtual ALP site will copy the configuration settings, because they are in files in it and they will work in the new location like in the old one.

IIS keeps all the settings in a single metabase. I.e. the virtual WEB sites, the ASP applications, particular directory settings are all in the same configuration storage. IIS determines which setting applies by the IP, DNS name and other information contained in the request URL.
ALP splits the settings in 3 different types of files - one for virtual ALP sites, one for ALP Application settings and one for ALP directory settings. The ALP URL refers to a local physical path, but it cannot be determined what kind of this URL represents a virtual ALP site or ALP application before inspecting file system for the ALP settings. If it was not so a global storage would have been required which would have required in turn re-configuration when the applications are moved across the file system. Having the different settings split in separate files ALP is able to determine if they exist by determining if the file that must contain them exist and thus minimize the need of file system access and preserve its flexibility.

Thus ALP uses:

For virtual ALP Site - alp.site file. 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 the particular virtual ALP site.

For ALP Application - alp.application file. 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.

For ALP Directory - alp.directory file. 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 in NDL. 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.

Example:

Lets take the following directory:

C:\sites

There are 2 site files in two sub-directories:

C:\sites\site1\alp.site and C:\sites\site1\dir1\site2\alp.site

2 application files:

C:\sites\site1\dir1\alp.application and C:\sites\site1\alp.application

The URL: alp://c:/sites/site1/dir1/dir2/file.htm

has site root: c:\sites\site1 and application root: c:\sites\site1\dir1

The URL: alp://c:/sites/site1/dir1/site2/dir3/file.htm

has site and application root: C:\sites\site1\dir1\site2

As we have mentioned already most of the ALP programming interfaces (and especially the primary programming interface - ASP compatible pages) resemble existing WEB programming techniques. Therefore ALP must split the URL in logical parts that will be exposed to these programming interfaces in terms known from the WEB programming - such as Host/Server name, virtual path in a WEB site and so on. By determining the starting points ALP defines these values and it exposes the site physical path with "/" slashes as a host/server name and the resting part of the URL as virtual path to the programming interfaces. In previous example for the first URL host name will be c:/sites/site1/ and for the second c:/sites/site1/dir1/site1/. The virtual path will be for the first case /dir1/dir2/ and for the second /dir3/.