"Open" system, as we mean it, seems to mean all of the following:
Open2: meaningful lower-level "VMachines" available, substitutes possible
Uniform: language-level call syntax & data types @ all levels that programmer can reach at all.
Layered: careful attention to dependencies, organization of system, as kernel & higher levels
Transucent: Open2, Layered
Safe: Cedar-safe
Protected: Safe or firewalled.
Packaged: some notion of interface.
All Open systems to date are based on single-address space. Most open2 systems would have to be categorized that way, although any single-user system is in a sense open2 (one can go change the operating system.)
Cedar (& Pilot) are really modified open2, since lots of stuff is intentionally buried in configs, open2 only to subset of system.
Smalltalk
Has always been Safe, thus Protected
Has always been at least nearly-Uniform
Layered maybe, but not particularly explicit -- class structure shows composition of implementations, doesn't indicate intended dependencies among disjoint classes -- global name space provides near-complete access.
Packaged -- yes, at object-level and category level.
Recent versions are largely Open2.
More notes:
Be sure to mention finalization in Safe Storage component section.
Discussion should inherit all or part of:
Providing automatic storage management eliminates the concern over ownership of shared objects. When a module interface returns a new object (a pointer to some newly allocated memory space) the space for that object is always owned by the storage management system rather than by the client or the implementation program. The client program may use the pointer as it sees fit, pass it on to another client, retain it, or dispose of it. Since the storage management system can discover what storage is accessible, the storage will be reclaimed only when no remaining valid references to the object exist. As a result of automatic storage management, programmer time and effort spent on solving problems related to storage management has decreased from an estimated 40% in Mesa to an estimated 5% in Cedar.
Safe Storage: This component also deserves considerable attention, because it is both a significant source of improved programmer productivity and an important contributor to the success of Cedar as a reliable but open programming environment. In response to an explicit program request for a new region of storage of a specified type, SafeStorage allocates one and returns a reference (pointer) to it. A pair of garbage collectors reclaim the storage when no reachable references to it remain: one is incremental and unobtrusive but incomplete, while the other is thorough but preemptive [5]. Type information associated with each allocated object allows the garbage collectors to locate and process embedded references. These characteristics make programming easier; in section 3 we also argue that they help to improve the structure and reliability of the Cedar open architecture.
Because Cedar has SafeStorage, it can also have some other things. Variable-length text strings (ROPEs), linked lists containing values of arbitrary (but specified) type, and Lisp-like atoms are data types that have been introduced into the Cedar language. The inclusion of type information with every allocated object also enables a safe (and cheap) implementation of generic pointers. Cedar programs can manipulate references to objects whose types they do not specify, performing runtime type checks or type-based dispatches in order to access the referenced objects. Rovner covers Cedar storage management in more detail in [20].
See Also 2.3.4 in the original non-summary.
Extracted from the Viewers section, for use in "part 2":
The relationship between the lower-level Terminal interface, the Graphics interface, and Cedar Viewers provides the setting for a compelling example of the nature of the open, or translucent, architecture of Cedar:
Most clients obtain their screen real estate by creating viewers, then using built-in display capabilities of one of the standard viewer classes, or providing their own images through the Graphics interface.
With some care, one can descend below the Graphics abstraction and directly manipulate the bit map within a Viewer -- for performance, or in order to render something that the Graphics package does not directly support.
Finally, by using facilities in the lower-level Terminal interface, an experimental or antisocial application can gain access to a virtual screen/keyboard pair that is completely separate from the standard Cedar screen. On this screen the application has free rein to manipulate its screen's bitmap, using all or none of the Viewers and Graphics facilities as it chooses. There are functions in Terminal for switching from one virtual terminal (or virtual universe, as far as the user is concerned) to another.
These examples represent a consistent degree of coexistence, with varying degrees of integration! Each step away from standard behavior requires more effort and more care, both to obtain the desired results and to avoid untoward side effects. As usual, few programs need to use these escape mechanisms, but in these few instances their availability is vital.
For every application, there's usually a package. That doesn't come through very well in the higher levels of the overview. Notably missing are ReadEvalPrint and Interpreter.
Here is some text that has been left out, relating to the above.
Life Support includes a parser and interpreter for Cedar expressons. Given a Cedar ROPE containing a valid expression and some parameters that specify the execution context, the interpreter evaluates the expression, returning the result in the descriptive form used by the Cedar abstract machine. The interpreter can be used for debugging, of course, but it is equally applicable to other applications. In support of debugging, one can create an Interpreter Tool that uses the Intepreter package to evaluate successive expressions as the user types them into the tool's viewer.
Here's an apologia for the command tool -- shouldn't exist when nice display-oriented tools are developed.
As Cedar applications mature, they usually are equipped with user interfaces that exploit the power and convenience of the two-dimensional, high-resolution display. During development, it is often easier to test new features through a simple command interpreter. Several such interpreters have been produced for cedar (including the Cedar expression interpeter, of course), some specialized, some more general. (Leads to Command tool discussion)