Module File System
A NetKernel module physically consists of files stored in a tree-structured
file system.
The module may either be in expanded form, in which case the files
are located in the operating system's file system
or the module may be contained in a JAR file in which case the module's files are
combined into one operating system file that contains a virtual file system.
In either case, NetKernel maps the module file system to the
physical implementation.
The physical files in the module file system are not available to the
internal private address space by default.
As discussed in this section on a module's
logical structure,
a mapping entry using the
this element establishes a link between the
ffcpl scheme and the module's file system.
For example, if a module has the following physical structure:
resource/
resource/program.idoc
resource/icon.png
test/
test/test-program.js
test/test-program.idoc
The following mapping entry
<mapping>
<this>
<match>ffcpl:/resource/.*</match>
</this>
</mapping>
will make all of the files under the resource
directory available
within the ffcpl: namespace but will
not expose anything under the test
directory.
Scratch
The ffcpl provides a mechanism in which a SINK operation to a physical
file will not delete the original file - instead it stores the update
in a scratch directory.
Subsequence SOURCE operations will return the overwritten information
from scratch instead of from the module.
A DELETE operation on a physical resource will remove the entry
in the scratch directory, but will not remove the original file.
This capability is particularly useful for storing temporary state in
a module and for overriding configuration information.