Building to KnownSpace Helium

Here are the planned kernel development directions of the KnownSpace project. This should help potential developers decide what they might like to work on. Most of the following kernel extensions will occur over the release period of KnownSpace Hydrogen---January 2000 to December 2000.

The following changes do not include extensions like adding actors to parse, markup, and manage images, videos, music, and other non-textual data. They also do not include extensions like adding new applications (such as text editors, bookmark managers, and phone book assistants), nor extensions like the ability to encrypt and decrypt entity values, nor extensions like adding various builder tools outside of KnownSpace proper (for example, tools to create EntityValue classes, to build new interfaces, to manage source code repositories, or to aid developer communication). None of the above extensions involve kernel changes.

Currently, any actor can access or alter any entity's value or links. This is likely to change as we add a permissions model to the kernel. Future releases will let actors create entities that no one else (including other actors running inside the same virtual machine) can examine or alter. The kernel will eventually allow entity access at the finest level of granularity. This will also make fine-grained entity locking and multiple users easier.

Currently, all entities live in one pool. This is likely to change to allow multiple pools. Actors will then be able to create pools, delete pools, add entities to pools, remove entities from pools, store pools inside other pools, and so on. This will make multi-user versions easier to implement since each user can then have their own set of pools, and users can share pools.

Currently, the whole system runs on one virtual machine. This is likely to change to allow remote user interfaces and other portions of the system to interact with centralized kernel servers. Together with a permissions model and support for multiple pools, users will then be able to share their data and their code freely at whatever level of sharing they feel comfortable. Further, centralizing servers in this way will let users share high-bandwidth connections and massive computational resources, leaving only the most critical user-related tasks to run on their client machines.

Currently, actors can subscribe multiple times to any event generator, but can only unsubscribe totally from any event generator. Consequently, to unsubscribe just one event constraint from an event generator, an actor must unsubscribe all of them, then add the others back again. This is likely to change as we add a more sophisticated subscription model to the system. In future, we will add overloaded methods to let actors be more specific about just what events they want to unsubscribe from.

Currently, actors can only subscribe to single event generators. We do not presently allow actors to subscribe to arbitrary (constraint-delimited) sets of event generators, but we expect to add overloaded methods to do so in future. Note that this is more than simply iterating over a subset of event generators and adding subscription requests to each one since a set of event generators can---as a whole---generate different events than each of the event generators separately. For example, it's not presently possible to establish an event subscription like: "tell me when any user-interface simpleton deletes any three entities from the following set of entities". To support that kind of global event we will be adding support for subscription to sets of event generators.

Currently, constraints cannot specify arbitrary subsets of entities since, for example, regular expression matching is missing. We will be adding to the constraint hierarchy to improve the power of constraints. Eventually constraints will give way to a script language, then perhaps simpletons will be written using the language, rather than in raw Java. Eventually, we'd like to turn all application programming into script programming so that even users without Java expertise can add to KnownSpace.

Currently, each simpleton runs in its own thread and can live forever. Further, it is currently impossible for an application to specify when or how a simpleton should be run. All four of these properties are likely to change as we modify kernel thread management to improve efficiency and user control. Future simpletons will likely be given threads from a limited thread pool, and only selected simpletons will be run at any time, depending on which simpletons have already run and what the user wants to do at present. Simpletons will also have priorities. Some simpletons may even have time limits on how long they can run.

Currently, there is a big difference between simpletons and entities, although active entity values blur the line. Future releases will blur the line even more, until there is essentially no difference between them. Simpletons themselves will be entities, which can be stored in pools of entities. Then new simpleton-simpletons can work on the stored simpletons just as if they were bits of data like any other entity. That will let future releases control and evolve its own behavior as it's behaving.

Currently, the system can easily save meta-information but applications have no way to query the system and perhaps modify it based on the results of those queries. For example, it's easy for the kernel to track all search requests, and then build indexed structures of all constraints submitted to it. Consequently, it's easy for the kernel to improve how it's responding to the system as a whole. Eventually we'd like to make this meta-information---packaged into entities---available to applications so that they can if they wish dynamically alter their own behavior as it affects the system of which they themselves are a part.

Currently, the helper parts of the kernel---EntityValues, PassiveEntityValues, ActiveEntityValues, EventHandlers, EventGenerators, Constraints, DataManagerEvents, and DataManagerExceptions---are all quite simple, but all of them are application-writer expandable. As more applications are written, we will incorporate the best ideas into the kernel so that future releases will grow more and more sophisticated and application writers will have to do less and less to accomplish the same tasks.

Several, if not all, of the above kernel changes will come with KnownSpace Helium in January 2001. We expect that none of them will force changes to presently existing code.