As is evidenced by the many examples of open implementation enumerated in the OI workshop foil, even if we haven't been thinking about all of these issues in quite these terms most of us have been dealing with at least some subset of them implicitly for quite a while. We have a fairly concrete notion of what we mean by an interface, and we have a firm if more undefined notion of the category of decisions that we think might need to be adjusted by client programmers and users. Thus most of us probably have the feeling that we have a basic intuitive understanding of the distinction between base and meta interfaces.
Having said this, however, we have already put a particular spin on our description of the problem that will have an influence on the structure of our analysis and our solutions. Using words like ``interface'' makes most of us think of the traditional notion of procedural interface. It is not clear, however, that we want to cast all open implementation problems or solution approaches as variations of procedural interfaces. While it may be likely that most base-interfaces are procedural in nature, even many of our simplest examples present meta-interfaces which are not at all procedural in nature (e.g. compiler switches, pragmas, by-hand substitution of chunks of code, etc.).
A meta-interface may also be invoked at a different ``time'' in a program lifecycle than the base interface, for example to control compiler optimizations or particular data layouts, or to ``adjust'' the program itself rather than just its executable image (perhaps in the form of specifications which permit automatic generation techniques to modify or extend program code).
Another complication comes from sharing, for example of OS resources or as a result of distribution or concurrency. Many of the kinds of implementation tuning that we explicitly want to address will have implicit effects on the environment of other applications: some kinds may be relatively independent (e.g. data layouts, or increased usage of CPU cycles), but others (e.g. memory protection or scheduling schemes) may cause conflicts without additional safeguards. Designing protocols which allow meaningful interactions and which provide useful feedback about state information will be an important part of making the open implementation approach work effectively.
There are thus many issues related to the structuring of the meta-interface which have come out in the responses to the OI workshop foil document: how to characterize the base/meta split; how to effectively control or protect the client access to dangerous or shared state; whether we can or should be prepared to view the meta-interface as a collection of meta-interfaces, each focusing on some particular logical category of adjustment. As we explore these and other questions, we need to be prepared to question our own assumptions so that the formulation of our questions doesn't color or even obviate the resulting responses.
Back to Alphabetical List of Responses
(Last Revised Febuary 1995)