Let resources find you

Whenever possible, resources should register themselves in the Workspace and services should be told what resources to use via choices from the Workspace, so that users need remember only one way to choose things. For example, SCSI software would enumerate the devices attached to a SCSI bus and create device drivers for each device. This would happen once at boot time. From then on, the driver, not the SCSI software, provides access to the resources it represents. A SCSI disk, for instance, registers itself as a raw device to allow users to select it for formatting or partitioning.

If the SCSI disk contains volumes, it also registers itself with the File System to allow the volumes to be mounted. The File System in turn registers the new volumes on the desktop to allow users to select or open them. Note that in each case, the services only need to know the minimum information. That is, the File System only needs to know that something is a storage device, not whether it is a disk, tape, SCSI, or whatever. And the Workspace only needs to know that something is a resource. In the same way, when that resource is selected, the application only needs to know it is a storage device.

A similar example is a SCSI scanner application that looks on the SCSI bus and uses the first scanner it finds. If you have two scanners with different capabilities that you want to use alternately, you're out of luck, because the assumption built into the application is that there is only one scanner.

In the Taligent Application Environment, the scanner application waits for the user to tell it which scanner to use; the scanner might not even be on a SCSI bus. You don't have to rewrite the application to support a scanner that uses some other connection technique: knowledge of how to talk to the scanner is built into the scanner object that is handed to the application.

If you need to use another object, let the client give it to you--don't find
it yourself.