The previous section presented our vision of what an information appliance is. It is now time to turn attention to what implications this vision might have on system design.
First, the diversity of appliances implies that performance and cost requirements may differ widely between any pair of information appliances. Of course, there have been differences before, say between PCs and workstations, but in the appliance arena, differences of order-of-magnitude scale exist and need to be accommodated. Given this variety, it is clear that a one size fits all approach would not be able to do justice to all information appliances. Instead, what is needed is an infrastructure that represents the least common denominator among all information appliances. That infrastructure can then be extended to provide the exact functionality required by a particular appliance. In the traditional sense, this least-common denominator represents the operating system, but since the least common denominator is probably small, the usefulness of such an operating system is also very limited. Indeed, if it were necessary to build each appliance directly on top of this infrastructure, not much were gained relative to writing the system from scratch.
A key requirement for an appliance-oriented system is, therefore, that it must facilitate the building of reusable higher-level software in an easy and flexible manner. This can be achieved by structuring the higher-level software in a modular fashion. A modular design supports a mix-and-match approach that allows building the software for a particular appliance by simply selecting and combining the modules that implement the required functionality.
In the ideal case, building a new appliance should be a simple matter of configuration without involving any costly or time-consuming programming. A modular approach also meshes well with the fact that, due to the diverse nature of appliances, the rate at which new products are introduced will be high. A modular approach makes it possible to adopt a new appliance simply by programming the smallest delta that is required to go from the next closest appliance to the new one. Typically, this would involve programming device drivers for the few devices that were added or changed in the new appliance and maybe the addition of a few other modules that extend or enhance the functionality of the new appliance.
Modularity also implies configurability. The question is when configurability needs to be supported. In the extreme case, a system can be reconfigured on the fly at run-time. However, since appliances are expected to be of relatively stable nature, it seems that supporting configurability only at system build time might be versatile enough. Limiting appliances to static configuration reduces the complexity of the resulting systems and also simplifies building highly efficient appliances. Note that static configurability does not mean that appliances cannot be upgraded. It just means that an upgrade will typically involve replacing the entire system software, rather than performing an incremental upgrade.
The specialized and unchanging nature of appliances also reduces the need for separate address spaces. In traditional systems, address spaces serve two roles: they provide fault-domains that protect competing and mistrusting processes from each other and they simplify the loading and unloading of programs at run-time. The native code in an appliance is available to the system builder, so mistrust is usually not an issue. Similarly, the various services in an appliance are normally of a collaborative, rather than competitive nature. That is, the traditional incentives for multiple address spaces exist to a much smaller degree. This is not to say that multiple address spaces never make sense for an appliance, but it is fully expected that many, if not most appliances will not fundamentally depend on them. Since some appliances may need fault-isolation, but not dynamic loading of programs, the two issues should be kept separate. Doing so makes it possible to employ light-weight protection techniques such as software fault-isolation (SFI) or type-safe languages such as Modula-3, Java, or Limbo when protection is all that is desired [109, 7, 4, 102].
As appliances are likely to be realized in a single address space, the distinction between application and operating system becomes fuzzy. There is nothing wrong with this. In fact, this is in line with the realization that, in a communication-oriented system, it is difficult or meaningless to attempt to pin-point the application. It is much more appropriate to view an appliance as being composed of a collection of modules that are more or less simple filters. Some of these filters certainly can be complex (such as an MPEG video codec) and some may even exhibit characteristics of traditional applications, but whenever reasonably possible, it will be advantageous to employ the filter-view when building modules for an appliance.