7 Future Work

This research thus far has focused primarily on the design of (SIE), with selective implementation of key points to test theories, verify strategies, and prove concepts. With the network and communication protocols established, as well as the overall flow of SIE well defined, the next step is implementation. The administrator module exists in skeletal form, and while the majority of the central issues are addressed, the multiple agent support and write permission functionality, though well defined, is yet to be implemented.

The following is a partial list of some additional future contributions which could be made to SIE:

  • Network-ability: Currently, agents can connect to the administrator if it is running on the localhost, or if it is running on any other computer networked to the host of the agent. However, because the administrator must create the device processes, there is currently no means for the devices to be run on a computer other than the one upon which the administrator is being run. Perhaps an investigation of an RPC (remote procedure call) package may provide a solution [6]. An alternative answer could be to not have devices get executed by the administrator when they are needed, but rather run them explicitly and connect them to the administrator at administrator startup, leaving them connected for the entire duration of SIE. In this way, the user could explicitly run the device module from any networked computer, though an obvious disadvantage would be that it would then become a responsibility of the user to ensure that all needed devices were running and connected. Or, perhaps a separate administrator could be run on each computer of a networked cluster, so that when one administrator needed to access resources on another computer, it could be done through inter-administrator cooperation. The advantages to distributing SIE over a networked cluster are many, as are the issues involved which would require addressing.

  • Varying Agent Priorities: A priority scheme for agent ownership of devices may be useful for SIE in situations where many agents are being run concurrently. This however, creates the added complexity of communicating to a 'less important' agent that a more important agent has come along and ruthlessly usurped device ownership.

  • Midprocess Device Requests: The present design of SIE forces all device requests by an agent to occur when the agent initially connects to the administrator. A potentially very useful modification could be a design for agents to request devices anytime during their session with the administrator, and not only upon connection.

  • Device 'Short-circuiting:' In the case where an agent essentially streams the data coming in from one device to another device (sending image data from a video frame grabber to an artificial neural network, for example) there would be a performance increase gained if the agent could tell the administrator to channel the data to a specific device rather than send it back to the agent. Very quickly, complications arise when considering this scheme due to the implicit need this creates for differing devices to have compatible communication protocols, which is otherwise not an issue in the current design of SIE.

  • Development of Agents and Devices: Perhaps the most obvious contribution to be made to SIE is the development of both agents and devices. Ideally, device modules can be created, along with a defined protocol for accessing their functionality, and then saved - building a library of devices which can then be used by agents as they are created. Most likely, device module development will be driven by necessity - when an agent requires access either to a peripheral or some distinct functional unit for which there is no current device module written. It is hoped that the design philosophy of building separate, reusable modules will be followed to maximize code reuse and long-term productivity.

Next     Previous Contents