Open Software Foundation | H. Melman (OSF) | |
Request For Comments: 79.0 | ||
February 1995 |
OSF uses the criteria in this document to evaluate PST proposals and to form a recommendation to the OSF Board of Directors for whether the proposal should be accepted. This document is meant to codify the OSF practices and to inform Authoring Groups of OSF's criteria. These criteria are based on OSF's principles and end-user and sponsor goals.
OSF is developing an architectural document known as the Open Information Infrastructure or OII. Ultimately this RFC will be a part of the OII and as such it refers to other sections of that document. Specifically it refers to the Roadbed which defines the common infrastructure that OSF supports for Open Systems. For example, in a given technology area (e.g., GUI's) it recommends Open Systems technologies to be used (e.g., Motif). There are several different classifications for technologies in the Roadbed, an important one is known as the Main Roadbed. It describes technologies that are clear choices in their area due to expected longevity, wide-spread deployment, maturity, quality, adherence to standards, and technical superiority.
OSF staff evaluates each PST proposal against all criteria. It is expected that all criteria be met at some point in the life of the technology. Note that due to business and time constraints, this does not mean that all criteria must be met in the initial release. Information about all criteria must be provided in the PST proposal, regardless of whether an individual item is met in the initial release.
For example, if 64-bit support can't be addressed in the current release, information about plans for supporting it in the future must be included. In addition nothing in the initial release may preclude it's addition; e.g., an incompatible protocol change required to support it.
OSF will remain as open to PST proposals as our members allow. As such, there are only a few strict criteria below. Some reasonable number of the others criteria must be met with the initial proposal, with all others not precluded and in fact planned for in future releases.
These criteria apply mostly to the technical content of a PST proposal. There are other business requirements as well. For details see [PSTGUIDE].
In most cases, these parts are incomplete when the PST is proposed. However, the proposal must include a plan for completion of each part. Note that this criteria is relative to the scope of the PST. A PST could be for a test suite of some standard and the test suite code would be considered the source code. OSF is known for producing code and believes that this distinction greatly benefits the open systems industry, so specifications alone are not sufficient for a PST.
All OSF offerings must be portable across a variety of platforms. This means that source code must be written so that it can run on many platforms, instead of being limited to one or only a few. Further, the technology must not be designed, and the source must not be written such that the technology runs significantly better on one platform than on others; it must be vendor-neutral. (Licensees are encouraged and expected to add value to their product versions in part by tuning technologies to their own platforms.)
Other parts of a PST (specs, documentation, test suites) must likewise be portable and vendor-neutral.
The technology must have no architectural impediments to running on the spectrum of hardware platforms -- from PCs to mainframes. We accept that some (small) systems may not be able to fully support a particular technology, however a reasonable level of support must be provided for the system. For example, it might be reasonable to expect that PCs cannot be servers, but they should be able to be clients.
Technologies must adhere to the standards that OSF members and licensees believe are relevant. The Roadbed defines which standards are judged relevant in various areas. In most cases, these are de jure standards, but there are cases when de facto usage outweighs a paper de jure standard. In the case of competing, conflicting standards, PST's must adhere to whichever one the roadbed specifies (if OSF has made that choice).
PST's need to demonstrate that they do what they say they do. To take an extreme (and unrealistic) example, if a PST claimed to solve all printing problems, and then actually only addressed dot matrix printing, the PST would not be recommended for approval. (It could be re-proposed as a dot matrix printing PST.) The text about a PST and the proposed implementation must match.
Also, a PST is limited to the problem set that it describes. It must not provide additional unexpected functionality. For example if the same printing PST provided an entire distributed object oriented framework and 10 distributed services, it would not be recommended for approval. The PST could be re-proposed in a larger scope.
In order to help move the industry toward common solutions, OSF will not offer multiple solutions for the same problem (except in cases of legacy support). However, improved solutions come along over time, and OSF must be able to accept technological advances and retire obsolete software. Any PST that provides updated solutions to a previously solved problem must identify which technology it is designed to replace. Such a PST must also include a transition plan for moving from the existing solution to the new one. (See also next requirement on coexistence.)
An implication of this requirement is that proposed PST's must use applicable technologies in the Roadbed. For example, if a PST needed security support, it would have to use security as provided in DCE (since its in the roadbed) or extend that model rather than using a proprietary or other security system.
Although the goal of Open Systems is to move toward single, unified solutions, there are today multiple solutions in many areas. PST's should ensure that they can coexist with other relevant solutions (e.g., DCE RPC and ONC). Therefore, PST's should not be written such that they break other existing solutions. In addition, it's desirable for related technologies to be able to work with each other (e.g., DCE talking to Netware). This may require some bridging functionality on the part of the PST.
Some issues can not be dealt with in a single PST or single technology. Rather, they have an impact on nearly all technologies, and so support for them must be handled across PST boundaries. PST's should include support for these cross-technology issues, and where applicable must use the technologies described in the Roadbed to achieve this support. For example, in supplying I18N support, PST's must use API's defined in POSIX and the X/Open Portability Guide (XPG).
The need for common administration is complicated by the fact that there is no universally accepted management framework. Lacking this, OSF technologies should be administrable via secure and scalable means with consideration to existing administrative solutions. Common administrative actions such as user, host, and data management; backups and restorations; and monitoring all should be possible using reasonable (i.e., not overly complex or time consuming) and secure means.
OSF technologies must fit together. Licensees want to be able to take different OSF technologies and use them together. For example, it is highly desirable to be able to write one application that uses Motif and DCE on top of an OSF/1 system. All PST's must at least coexist with if not make use of existing Main Roadbed technologies.
In addition to coexisting with main Roadbed technologies, PST's should be well integrated with relevant Roadbed technologies. OSF technologies may depend on other Roadbed technologies. There may be cases when technologies require the presence of other OSF technologies in order to work. This is permitted, but such dependencies must be documented in a PST proposal.
Where appropriate, there needs to be a protocol layer for clients and servers that defines how they talk to each other. This protocol layer needs to be independent of system-specific characteristics such as those that might be present in an OS or a transport layer.
OSF technologies should not impinge on areas in which the industry should
be free to provide different, competing solutions. OSF technology is
typically middleware infrastructure or commodity applications. Examples of
commodity applications are xclock
or xcalc
which
offer basic functionality that users expect to be provided with their systems.
PST's must define quality and performance criteria, as well as measurement methods to be used in assessing whether the criteria have been met.
In the case of emerging technologies, OSF may receive competing PST proposals. Assuming the proposals solve the same problem and adhere to other criteria, they will be evaluated on their technical superiority.
Since English is the language that the largest majority of OSF members understand (either as a first or second language), all information provided as part of a PST must be in American English. This obviously includes specifications and documentation, but also includes human-language-sensitive parts of source code (e.g., comments, some variable names, etc.).
A PST must document whether there is anything in the proposed technology that would be difficult or impossible to change in a follow-on release (e.g., protocol limitations, binary compatibility promises, use of a specific technology without a layer of abstraction, etc.).
This RFC is based on drafts originally written by Sandra Martin O'Donnell and presented to the Architecture Planning Council for review.
http://www.osf.org:8001/pst/index.html
.
Send questions to Ken Flowers (e-mail: flowers@osf.org).
Howard Melman | Internet email: melman@osf.org | |
Open Software Foundation | Telephone: +1-617-621-8989 | |
11 Cambridge Center | ||
Cambridge, MA 02142 | ||
USA |