The URL is the most important part of each request sent to the ALP engine. It determines what code will be executed in order to process the requests and may contain also some inline parameters that give the processing code additional information about the request.

General syntax of the ALP URL-s is:

alp://drive:/path1/../pathN/file.ext?parameter1=value1&....&parameterN=valueN

The URL contains the following parts:

alp:// - the ALP protocol scheme name. In other words for the ALP consumer (Internet Explorer or ALPFrame for example) the URL looks much like an HTTP URL, but instead of http:// it begins with alp://
drive:/path1/../pathN/ - Full physical path of a directory. The canonical form is with "/" slashes, but ALP will accept back slashes instead "\" and will convert them internally to canonical form.
file.ext - File name. This is optional and if exists it specifies a file in the directory pointed by the previous part of the URL. In general ALP determines the file name extension (the portion of the file name after the last "." in it) and lookups the configuration to determine which internal ALP module should process the request. 
parameter ... - The parameters part is also optional and consists of name=value pairs separated with "&" character. If the parameter name or value contains control or non-ASCII characters they must be URL encoded.

ALP treats the physical path portion of the URL as 3 logical parts which depend on the configuration settings found (if any) in the directories in the path. The logical parts are: Virtual ALP site, ALP Application and Directory.

• Site - is a root point of directory tree that is treated as virtual ALP site. All content of the site is isolated from other virtual ALP sites. ALP associates with the site some general settings, developer licenses and administrative tasks. If no site definition is found ALP assumes root of the drive as virtual ALP site root. Also note that the ALP application and the ALP Directory settings cannot cross the site boundaries and if they are not explicitly defined the root of the Virtual ALP site is also ALP application and ALP directory settings root. 
• ALP Application - is a root directory of a directory tree that shares common application/execution settings. If no application is found in a particular virtual ALP site Application root equals to the site root. Application holds many settings and defines how to process the content. For example ASP Application and Session objects are unique for each separate application tree. 
• Directory - is always the directory pointed by the URL or directory containing the pointed resource. It holds additional settings such as execution rights and default document settings. The ALP Directory settings also cannot cross the virtual ALP site boundaries and if they are not explicitly defined the virtual ALP site uses the ALP defaults. 

ALP determines these points in the computer's file system by looking for certain files in the directories that form the URL:

• alp.site file - specifies virtual ALP site root. If not found up to the drive root - the drive root directory is assumed to be a site root. Empty file is enough to trigger virtual site root point at the directory containing the file.
• alp.application - specifies the application start point. If not found up to the site root - site root is assumed to be an application root. Empty file is enough to define new ASP application root point at the directory containing the file. 
• alp.directory - specifies directory settings root. If not found up to the site root - site root setting are applied (if any). Empty file can be used to revert to default settings if another alp.directory file exists in one of the parent directories.

Files can be empty if there is no setting to override but their existence is important in order to set the start points for the logical parts of the URL .

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/.

Even without WEB server compatibility in mind these values have important meaning to the applications as they allow them work in location independent manner. ASP compatible pages for instance offer the Server.MapPath method returns the full physical path corresponding to a virtual or relative path passed to them. For instance in the above example an ASP page in c:\sites\site1\dir1\dir2\file.asp may use Server.MapPath("/dir1/database.db") to obtain the full physical path to a database file it needs. The Server.MapPath will return in this case: c:\sites\site1\dir1\database.db because the virtual ALP site root in this example is c:\sites\site1 and the virtual path /dir1 is mapped against the virtual ALP site root directory. The same functionality applies to the links in the displayed HTML content when they specify relative or virtual paths to other pages/resources in the site instead of full URL, and the same is true for other features that concern the ALP programming (such as include directives and so on). All they together allow the developer code all the references to other files in virtual ALP site centered manner and so create code that would not depend on the actual physical location.

As you may have noticed the ALP application and ALP directory settings have no direct impact over the physical path mapping, but they concern each application because they define the ALP engine behavior exposed to the application files in the scope of each of these settings.

Conclusion 

The developer needs to understand the ALP URL as first step and keep the track of the logical parts of the URL when building applications. The logical splitting of the URL is a result of developer's actions - e.g. the developer creates virtual ALP site, ALP application and so it is just a matter of planning of the project's logical structure. The developer can always check what is the logical structure in the file system by checking which alp.site, alp.application and alp.directory files exist and where. Also a more convenient way to check and define logical structure is provided by the ALP shell extensions which are included in all the developer oriented ALP download packages. They allow the developer right click in Windows Explorer windows (over files, directories and even in the empty space of a folder window) and invoke the ALP Settings user interface by selecting the "ALP Settings" menu item. The ALP settings user interface allows the developer create and manage all the important ALP logical structure elements and settings. Alternatively the developer can also edit/create the alp.site, alp.application and alp.directory files with a text editor (notepad for example) because they are text files and are described in details in this documentation.