The Windows or MacOS application is written assuming that the program can generally access any file by mere knowledge of its name in the directory structure. Such programs may indeed query the list of available names. What response should be made to such a query from a conventional application?

The Windows Application Cocoon

This is mainly an exercise not in interface to the user, but in interface to the application. We start this design exercise by presuming that the application be informed that there are no files on the system except for those created when the application was installed. Each time the application is newly instantiated, the application is presented with an accessible system state just like that immediately subsequent to its installation. The apparent state as installation begins is just that immediately after installation of the simulated Windows or MacOS. Every application will perceive that it is the first to be installed.

Many applications accumulate user preferences as state with which to begin new jobs. This is indeed useful and labor saving but there are some problems even when the application runs in its conventional environment: The site of this state is mysterious. The user may wish to move or duplicate this state onto a new machine, or maintain different preferences for different circumstances.

An idea from the Lisa comes to the rescue. (The Lisa was a predecessor to the Mac from Apple.) The Lisa came with a LisaWrite icon on the screen. It behaved much like the Mac "Stationery" icon that the Mac reinvented years later. If you want your default font size to be 11, you click on the original LisaWrite icon and an empty document appears. Its font size attributes are as delivered by Apple. You change the font size and save as a new document, yielding a new icon. The two icons are now the same status. Now the site of the user preferences is manifest and natural. Fewer concepts are required by the user.

In this plan it is not necessary to inform the application when a backup copy is made of its state.

A new question concerns the illusion to present to the application that wants to write a file. In the simple word processor model the written file is not normally read by the instance of the application that wrote it and it suffices to pretend that the file was written. On the other hand most word processors only write a file when specifically instructed by the user, either as part of a "save now" operation or pursuant to "save periodically" instructions. A "save now" operation may be intended by the user to keep a document sate in addition to the state that he plans to drive the "in RAM" version. Our system has the opportunity of displaying both of these states on the screen at once, if we can find the appropriate manifestation concept.

Cocoon Summary

The cocoon is a box to contain an application that presents the illusion from inside the box, of a single time line to the "present". From the outside of the box there is a branching tree of instances. The state of each instance of the application has evolved from the actions performed on the ancestors along those portions of the tree since the installation at the root. Within the box it appears as a machine on which there is only one application. Within the box only files and other artifacts created by the application can be seen by the application. In the simple model if the application quits the state is lost.

Limitations of the Cocoon

There are clearly some extensions of cocoon logic required. No mechanism is yet available to combine two documents. No OLE (Windows) or Publish-Subscribe (Mac) support is possible. Some applications recover from RAM exhaustion by crashing, presumably to restart from a saved document. This design may have been chosen when memory was not virtual, in short supply and not available after application launch.

Cocoon Tricks

When application X sends a query to application Y the intent is presumably to transfer information from Y to X. The nature of the transaction, however, allows information to flow from X to Y as well. The cocoon allows an interesting solution to this: Clone Y, yielding Y', permit X to query Y' and then delete Y'. Y is unaware of having been queried.