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
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.
Lets take the following directory:
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