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 improving:

• 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 scaling.

• 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.