The Application Platform
Donald Norman and others have begun to advocate the information
appliance as the way out of the personal computer morass.
They speak metaphorically (which is good) but it would seem that they advocate separate pieces of hardware.
Some of the examples represent new applications which indeed inherently require separate hardware, but others seem to require separation for integrity and conceptual purposes.
I have perhaps 20 applications on my Mac that I am likely to use at least once a week.
I haven’t room for twenty boxes, each with a screen and keyboard.
Further I was hoping to begin to keep my computer with me in my pocket.
I certainly don’t have room for twenty screens in my pocket.
One adequate screen is already a severe problem for my pocket.
Is there an architecture that will accommodate the ends of those who pine for separate boxes? I propose an application container in your pocket that feels like a place to keep autonomous information objects that are unaware and unthreatened by each other.
If you have heard me before you might guess that I will advocate capabilities as the solution.
I don’t have a crisp reason why capabilities solve the problem and nothing else does, but I will wave my arms and describe vaguely how to build such systems with capabilities.
A bit of history:
In 1955 the programmer would reserve time on a computer, bring his or her data and program, start the program and upon the probable crash, print the 8KB of memory on a slow printer.
This would take 5 or 10 minutes.
By the late 50’s there were batch processing systems that eliminated the human interaction time and increased thruput, but somehow not the number of useful bug-shots per day.
It greatly increased the latency.
Early timesharing systems were a reaction this abysmal practice.
The vision was to isolate users from the effects of other users.
“User” meant programmer! (It still means that today in Unix land.)
On an historical time scale timesharing turned out to be easy and useful despite early widespread misgivings about its feasibility or utility.
Having achieved separation it was discovered useful to poke holes in the wall to let programmers cooperate.
This was done on an ad hoc manner.
Timesharing was the way to go until computers got so cheap that they could be bought without showing up on the budget.
Even private individuals could buy them.
At first they were so puny that the main-frame people sneered.
Many already saw, however that there were ultimately few real obstacles to the briefcase computer supplanting the contemporary mainframes.
Moore had spoken!
The early personal computers had no room for an OS.
Some would say no need.
Some of the first PCs were marketed to those who would write their own programs.
It was clear, however that this was not where the money was.
OS’s arose in the PC land not to separate users but to make the system more friendly.
The art of separation was gradually forgotten by a generation of programmers.
The mind-set, as far as I can imagine was:
It was imagined that it would obvious which program did the dirt.
|There are no security problems.
When a program does something other than exactly what the user wants, the remedy is to get a better program!
With the “integration” of browser and OS, Microsoft seems intent on blurring any boundaries in the system that the user might make out.
My experience with Windows and MacOS is that far too much of my time is spent learning what usage patterns causes system failures.
In effect the system trains me what not to do by negative reinforcement.
This training is painful, very time consuming and limits how I can use my applications.
If I count my time at normal rates I spend far more being trained by my computer of my computer’s limitations, than I spend buying hardware and software together.
Some application training is fun--such as how to draw diagrams.
Discovering fatal combinations of system extensions shouldn’t be my job.
What is needed for an application platform?
There are conflicting goals here.
The application owner may wish to do things that the platform owner is unwilling to allow.
Conversely the application owner may be unwilling to allow his code into a platform where he cannot account for use of information, in order to guard copyright interests.
In general some degree of tamper resistance is necessary to meet some requirements of the application owner.
The careful reader will see incompatibilities among these apartment attributes.
Some attributes may pertain only to sub-apartments.
I think that today most application failures are the fault of some other component, either other applications or the infrastructure.
I suggest the term apartment to describe the place that an application uses to be responsible for its own world without having to worry about other applications and “sys-admins” making judgments concerning what parts are not just right.
The issues go well beyond memory protection.
This is very similar to the information hiding called data abstraction.
The application is responsible to its client for total space and time, but not how it allocates those internally.
- Application Interactions only by Mutual Consent
- Just as timesharing systems soon found that users needed to cooperate, so do applications.
Applications must be able to control the information that departs from their realm and mediate all information and entering signals.
Again this is reminiscent of data abstraction.
- The platform owner may want assurance that his secrets will not leave the application environment, despite the application’s wish to export it.
The apartment has no phone (Internet access) unless provided by the owner.
The platform owner may wish to confine applications or instances thereof.
- Non Cloning
- It may be reasonable to install applications that represent money, such as in the Mondex card.
To duplicate such behavior and state would be to duplicate money.
This must be prevented just as duplicating $100 bills must be made difficult.
- The platform owner may want protection from extortion by the application.
Some forms of such protection can be provided.
Some applications will require durability of sub-contractors in order to provide durability themselves.
- Resource Accountability
- The application must be unable to allocate too many resources.
The platform owner must be always able to reclaim space and time.
These requirements must be squared with the durability requirements.
Incidentally screen space is a primary resource.
The platform owner is the ultimate owner of the screen.
- Plumbing Review
- The owner must be able to consult with his platform about what dependencies and data flows have been established, even, especially, if he is the one who established them.
I use the term “plumbing” to evoke images (drawn on the screen) of boxes connected with data paths.
These images allow the user to reason about what information can get where.
Nixon had a good term.
- Owner enforced separation
- Only the owner is allowed to notify the application of what other applications there are on his platform.
The working of an application may not depend on the state of some other application, or even if it is installed on the platform.
Few if any of these requirements can be met by conventional operating systems.
These requirements are relative and work within negotiated parameters.
Mutually trusted code can provide mutual assurance that terms are met.
Perhaps a few of these functions could be added to a conventional kernel.
With capability architectures these functions can be added outside of the kernel and so evolve smoothly, leaving underlying functionality stable.
The language, graphic and textual, of current operating systems is unable to express these requirements.
New metaphors, familiar in the outside world, may be adapted to help the owner understand what’s connected to what.
If my sound amplifier at home produces funny sound, I can reason by examining wires behind it about where the causes may be.
I wish it were so easy to determine where the sounds from my Mac speaker arose!
Further ideas about apartments can be found here.