Open design occurs when the provider has to choose a fundamentally different modularization (and set of interfaces for those modules) to provide access to the desired mapping conflicts. This is the case in the Mach external pager example. An open design provides more flexibility to a client (in addition to possibly better performance), but there are ramifications to existing clients whose structure may have to change to use the new version of the provide. This is not simply the annotation of meta-interface information into an existing client.
Open implementation occurs when a client can be provided access to mapping conflicts within the range of a given design (and existing interfaces). This is the case when a client can choose from a particular array layout provided by a language and annotate the choice into an existing client (without changing the structure of the client). Here, the emphasis is more on performance. Open implementations of this form are found in new component library approaches (like C++'s STL) where there is more choice in combining implementations with interfaces (i.e., obtaining a sorted list with a certain sort performance). There may be many open implementation choices for a given open design. (In fact, an open design may in some sense have a closed implementation where some mapping conflicts that arise during implementation are not exposed to the client).
These are two (reasonably extreme) examples chosen from different ends of the spectrum of what the foil currently refers to as open implementations.
It may be that in the case of open implementation (my definition above), it is possible to clearly label parts of "the interface" as either base or meta. This may be much more difficult in the case of open design. Open design also suggests more "pre-thought" of flexibility that can be provided to clients and may be the result of previous experience implementing many instances of the same family of systems.
Understanding where existing examples of open implementations (general definition) fit into such a spectrum may help clarify which mechanisms are useful in which circumstances (e.g., what programming language support is need, guidelines for design, etc.) and how the use of a given open implementations mechanism affects the evolutionary development and deployment of a system (e.g., how changes to the open implementation affect clients, portability, interoperability, etc.).
Back to Alphabetical List of Responses
(Last Revised February 1995)