Location modules
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.
|