Dependencies on peripherals are often created by the programmers of applications that do not create alternate means of inputing commands or data to change the way an application behaves. For instance, in our view, if a user has access to a display and an input device, the user should be able to edit a document on the user's disk. But in today's world it is all too likely that the user's document editor requires both a mouse and a keyboard (even though one or the other is sufficient).
In order to enable smart devices to overcome peripheral dependencies, a capability description language may be appropriate. Such a language would allow the smart devices to query their peers to resolve their capabilities. So, an application might query an input device about whether it could emulate a mouse. And the slide projector in a conference room could advertise its resolution and supported scan rates.
But there's a challenge hidden in the idea of a capability language: how many different types of devices are there, and how do we represent them? For instance, a mouse can come with one to three buttons. An application will have to behave differently, depending on the number of buttons. But the last thing we want is a world where an application refuses to work because the user has a one button mouse and the application expects a three button mouse.
This problem was recognized many years ago by the ARPANET pioneers and dubbed the m-by-n problem. The basic idea is that if there are m applications that know the details of n different devices, then cost of adding the n+1st device to the mix is often prohibitive, because it requires updating the m applications. The trick is to actually have as few distinct types of devices as possible. So, for example, we could classify keyboards, pointers and mice, as input devices, capable of giving us a single one-button signal, and require every application to work this device. We can then allow optional negotiation of additional capabilities such as "can you send character codes?" and "do you have more than one button?"1.
Developing these kinds of standards requires tremendous community effort and a great willingness to radically simplify. But it has tremendous advantages.