This roadmap lists the top level directories in the KOE source distribution and briefly describes their contents. The roadmap is intended to make it easier to find your way around in the code.
A proxy runs in unrestricted mode and exports a 'safe' interface to some set of operations. For example, the urllib proxy provides an implementation of the urlopen that can be used to limit which URLs a KP is allowed to open.
The proxy implementation can be used to allow a KOS administrator to add modules to the restricted environment which require non-restricted implementations. In general, you can implement a proxy that lets a KP call some protected function, e.g. open a file or exec a process, but checks the arguments to those functions before making the call.
At this time, the proxy architecture is not fully documented. The doc string in the file supervisor/KPRExec.py describes it in greater detail, but it still has some gaps.
Although the code is in a package, KPs do not yet have access to packages. (The implementation of restricted execution used by KPs does not support Python packages.) Instead, a KP can import modules directly from koe.common. The other packages should not be needed from a KP.
The practical impact of the koe package structure is that standalone utilties and plugins must import from a package, while the koe.common package is implicitly on a KP's path. For example, in a plugin you might see
while in a KP, you would simply see:from koe.common import nstools from koe.interfaces.stubs import GenericAPI__skel
import nstools
The KP supervisor automatically manages the binding of ILU stub classes, so a KP would not import from koe.interfaces. However, KPs do need to use the exceptions defined by ILU interfaces and this policy prevents them from doing so. The work-around is described in the catching exceptions section of the KP interface documentation.