Location modules handle a mountpoint in Challengers virtual file system. Request to a URL under a modules mountpoint will be sent to that module. Unless there are more location modules with overlapping mountpoints, in which case the module with the longest mountpoint will be tried first. So if there are one module mounted on /test/ and another on / the module mounted on /test/ will be tried first. If it returns that it could not handle the request the module mounted on / will be tried.

Location modules are either Pike or CGI scripts written as modules or file systems. For script like modules it will only be necessary to implement the find_file() method. The advantages of writing scripts as modules is that they can be configured and installed nicely.

Location modules that implement file systems need to implement all API methods. This is to make it possible to interact fully with other module types, like directory modules. File system modules usually either give access to the normal file system, but do some special processing or access control, or give access to files stored somewhere else, for example in a CVS repository. For the first type of file system modules it can be a good idea to inherit the Filesystem module.

The module type for the Location Modules is MODULE_LOCATION.

API methods

find_dir()

returns a directory listing. It is used indirectly by directory type modules to create directory listings.

find_file()

is the fundamental method of all location modules. It will be called to handle all accesses to the modules mount point.

query_location()

returns the mountpoint of the module. It can be omitted if the module has a configuration variable location.

real_file()

returns the path to a file in the real file system. It can of course only be implemented if the file in question exists in the real file system.

stat_file()

returns information about a file, in the same format as Pike's file_stat() method.