[_CD8_]<cedardocs>per>report>per.3c!1

The contents of this section were largely extracted from Butler Lampson’s memo of March 9, 1978 titled "Components for office systems" (file [Maxc1]<Lampson>components.memo). The interested reader is referred to that memo for additional discussion of the items below and of the role of packages in a programming environment. There is a lot of overlap between this section and the previous ones on VM/Language and Tools, since many of these packages will be required to implement the facilities mentioned in those sections.

Beyond the virtual machine and programming language, which are forced on all users, and the tools, which should be applicable to all users, the quality of a programming environment is largely determined by the presence of packages that provide functional capabilities useful to many applications. We cannot stress too strongly that, from our experience, the only way to ensure the necessary high quality for such packages is to have a very small group (1-4 people) with the final authority and responsibility for deciding which packages are to be incorporated in the system in a way that makes them readily available to all.

The manipulation of images is of primary concern to us in our experimental systems. We can divide these manipulations into two categories:

Manipulation of abstract objects such as formatted documents, forms, line drawings, pictures in AIS or related forms. The operations on these objects are defined by the semantics of the objects, not by their representation on a medium.

Manipulation of the images of these objects on displays or printers. These operations must take the nature of the medium into account.

In the first category we might find editing operations on document files such as insert, replace, search, etc.; on drawings and pictures such as scale, rotate, reflect, clip, shade, connect points with a spline curve, etc. In the second we find operations for mapping objects onto media in a variety of ways, some of which must be reversible (e.g. when a user makes a selection in the displayed image of a document, that selection really refers to the data in the document itself).

We believe that enough experience has been gained in these areas that it is possible to construct packages that will be useful in a wide range of programs, and that will markedly decrease the effort required to write programs that use them.

An interesting area that we have not discussed per se is the general notion of "annotation" of documents (or data structures): formatting information can be considered an annotation to the text, comments to a program, meta-descriptions in the KRL sense to a slot or another description. Pilot, for example, provides a notion of "subsequences" of a byte stream, which can easily be used to represent formatting information in a way that uninterested programs can ignore.

In addition to the basic screen management capabilities mentioned under VM/PL above, there are some additional facilities (scrollable windows, for example) that many programs will want to share. Again, we believe there will be a payoff from the presence of some carefully designed packages in the environment.

The manual transfer of files between machines is a significant source of errors and wasted time. Such transfers are necessary either because of space problems or because one machine has a capability (such as a printer or high-performance display) not possessed by all. Pilot provides the ability for any program to access files stored on a remote server as though they were stored on the local disk.

As a goal, we believe that the well-integrated access to large data bases mentioned under VM/PL has a potentially enormous payoff, since many tools as well as experimental programs will benefit from it. However, if it turns out that we can’t figure out how to provide this, then we will need a well-designed data base package for managing locally stored data.

The ability to call a procedure on another machine as though it were on one’s local machine is a different, less well understood communication paradigm.

Event logging is a useful technique for redundancy and crash protection, for gathering statistics, and for reducing the cost of updating a data base in response to events affecting it.

In an interactive system with enough real memory, both external communication (sending and receiving mail, printing) and computation (recompilation, Masterscope data base maintenance) can make effective use of time when the user is thinking.

Many applications can benefit from a cache mechanism that provides local copies of more remote data, e.g. copies in memory of data from the disk, or copies on a local machine of files stored remotely. A package could keep track of which items had been used least recently, schedule rewriting of changed items, and deal with locks and timeouts.

Laurel had to re-implement a modest but significant part of the editing capabilities of Bravo. There is no good reason why anyone should have to do this again.

Packages that provide standard user interface tools such as forms, menus, selection, etc. are desirable both in the interests of uniformity and simply to save work.

Programs should be able to take advantage of the same mechanisms used by the system to provide the history and undoing capabilities discussed in (T11).

Data base manipulations and code overlaying require brief bursts of high-bandwidth disk activity. The system should not prevent the programmer from using the disk’s full bandwidth, and a package should make it easy (like the ScanFile package for the Alto).

Office applications involving documents can benefit from easy access to an English dictionary (for spelling correction, hyphenation, and thesaurus applications, for example).

Inter-person communcation should play more of a role in our future experiments; we need a package to handle the mechanics of keeping several users’ views of the screen, cursor, etc. consistent.

We have hardware support for capturing and playing back audio information, but hardly any software support. Something like the current audio message system ought to be a very small project.

As in (P17), the system should not obstruct the programmer’s access to the machine’s full I/O bandwidth in experimental situations.