Common+API+Specification

=[|**The Common API Specification Initiative**]=

The Common API Specification project started when several vendors (Sun Microsystems, IBM, Hewlett-Packard, Novell/USL and OSF) organized together to provide a single unified specification of the UNIX system services. By implementing a single common definition of the UNIX system services, third-party independent software vendors (ISVs) would be able to more easily deliver strategic applications on all of these vendors' platforms at once.

The focus of this initiative was to deliver the core application interfaces used by current programs. The economic driver that initiated the project was to ease the porting of existing successful applications. While the work was led by a central group of vendors, it received widespread support within the industry.

[|**Developing the Common API Specification:**]
A two-pronged approach was used to develop the Common API Specification. First, a set of formal industry specifications was chosen to form the overall base for the work. This would provide stability, vendor neutrality, and lay a well charted course for future application development, taking advantage of the careful work that has gone into developing these specifications. It would also preserve the portability of existing applications already developed to these core models.

X/Open Company's XPG4 Base was chosen as the stable functional base from which to start. XPG4 Base supports the POSIX.1 system interface and the ANSI/ISO C standards at its core. It provides a rich set of 174 commands and utilities.

Many UNIX systems already conform to this specification. To this base was added the traditional UNIX System V Interface Definition, (SVID) Edition 3, Level 1 calls, and the OSF Application Environment Specification Full Use interface definitions. This represented the stable central core of the latter two specifications.

The second part of the approach was to incorporate interfaces that are acknowledged common practice but have not yet been incorporated into any formal specification or standard. The intent was to ensure existing applications running on UNIX systems would port with relative ease to a platform supporting the Common API Specification. A survey of real world applications was used to determine what additional interfaces would be required in the specification.

Fifty successful application packages were chosen to be analyzed using the following criteria:

From the group of fifty, the top ten were selected carefully, ensuring that no more than two representative application packages in a particular problem space were chosen. The ten chosen applications were:
 * Ranked in International Data Corp's. 1992, 'Survey of Leading UNIX Applications',
 * The application's domain of applicability was checked to ensure that no single application type (for example, databases) was overly represented,
 * The application had to be available for analysis either as source code, or as a shared or dynamic linked library.

AutoCAD; Cadence; FrameMaker; Informix; Island Write/Paint; Lotus 1-2-3; SAS (4GL); Sybase; Teamwork; WordPerfect

APIs used by the applications that were not part of the base specifications were analyzed:


 * If an API was used by any of the top ten applications, it was considered for inclusion.
 * If an API was not used by one of the top ten, but was used by any three of the remaining 40 applications, it was considered for inclusion.
 * While the investigation of these 50 applications was representative of large complex applications, it still was not considered as a broad enough survey, so an additional 3500 modules were scanned. If an API was used at least seven times in modules that came from at least two platforms (to screen out vendor specific libraries), then the interface was considered for inclusion.

The goal was to ensure that APIs in common use were included, even if they were not in the formal specifications that made up the base. Making the Common API Specification a superset of existing base specifications ensured any existing applications should work unmodified. The sponsors of the work considered pruning the Common API Specification of interfaces from the base specifications that were not found to be in common use in the application survey.

This idea was rejected for two reasons. While some of the interfaces in the base specifications are not yet considered common practice, their inclusion in the overall specification meant there existed clear sign-posts for future applications development work. As well, it was recognized that the applications chosen for the survey were still only a representative sample, and that many other applications not surveyed may use these interfaces.

When the survey was complete, there were 130 interfaces that did not already appear in the base specification. These interfaces seem to be predominantly Berkeley UNIX calls that had never been covered in XPG4 Base, the SVID, or the AES, but did represent common practice in UNIX system applications developed originally on BSD-derived platforms. Such things as sockets and the 4.3BSD memory management calls were commonly used in many applications.

The resulting Common API Specification was impressive in its coverage. The top ten applications surveyed were completely covered. Of the remaining 40 application packages, the next 25 were within 5% of complete coverage. The software vendors involved all acknowledged that it would be fairly straightforward for them to modify the 5% of the application to conform fully to the specification.

There were 1170 interfaces in the complete specification when the work was done (926 programming interfaces, 70 headers, 174 commands and utilities), and the name of Spec 1170 was born.

Because of the breadth and origins of the specification, duplication of functionality existed. There were similar interfaces for doing the same thing in such areas as memory management (bcopy versus memmove) and creating temporary filenames (tmpnam versus mktemp). This duplication was allowed as it would increase the number of existing applications that would be portable in the new model. At the same time, certain functions have been identified as the recommended practice for future development. There are cases where the duplicated functionality cannot co-exist in the same application (for example, conflicting signals models), and it is important to ensure that the is correctly configured if the expected behavior is to be observed.

In December 1993, Spec 1170 was delivered to X/Open for fast-track processing into a proper industry supported specification. This work progressed through 1994 and culminated in the publication of the Spec 1170 work as the Single UNIX Specification in October 1994. There are now more than 1170 interfaces in the specification as the review process shaped the document accordingly. (The new internationalized curses specification contributed a large number of interfaces.)