Future Plans for the Knowbot Software
CNRI is committed to improving the Knowbot software. We are aware
of many of its current deficiencies, and will take care of them as we
find appropriate solutions. Some of the key issues we plan to work on
- Security. Knowbot programs (or their submittors) need to
authenticate themselves. Discretionary access control based on this
authentication should be provided for key resources. Knobot programs
should be able to accept or deny requests from other Knowbot programs
based on their authentication.
- Resource limits. Apart from access control based on
authentication, Knowbot programs should also be limited in their
resource usage based on some kind of "fuel" or "cash" mechanism.
- Java support. We will support Knowbot programs written in
Java. These will use the same interface definitions as Knowbot
programs written in Python, so that Java and Python Knowbot programs
can communicate and interoperate.
- Windows port. We understand that many potential users would
like to use the software on Windows. When we find there is enough
demand for a Windows port, we will undertake one.
- Namespace partitioning. Currently the Knowbot namespace only
has a single level between the worldroot and the individual hosts.
This should be changed to a deeper hierarchy so as to accommodate
- Persistence. Currently, all executing Knowbot programs are
killed when the Knowbot Operating System software (or hardware)
crashes. We will provide mechanisms for preserving the state of
running Knowbot programs and automatically restarting them when the
KOS is restarted.
- Local filesystem access. Knowbot programs should have
(limited) access to a local filesystem, e.g. for temporary storage of
bulk data. This will be subject to the access controls mentioned
above under "Security". Persistence of data stored locally may depend
on available funds and access controls.
- Interface restructuring. Many of the existing interfaces are
provisional. We plan to gradually improve the interfaces, both
presented to Knowbot programs and to other components of the system.
For example, the connection broker/manager may disappear; the trigger
manager may give way to a more standard event model; suitcase access
may be integrated with local filesystem access. We also plan to give
Knowbot programs access to the Python hierarchical package/module
namespace as seen by most other components.
- Knowbot program representation. We may replace the current
ad-hoc representation of a Knowbot program with a ZIP/JAR based file
format, and give the Knowbot program access to it, probably integrated
with the local filesystem as suggested above. This will allow for
compression and signing of specific components.
- Support automatic stubbing of ISL files. This will allow
Knowbot programs to carry interface definitions with them (just like
they can already carry class definitions with them).
- Rationalize the exceptions raised by the system.
- Improve performance.