Ada Application Program Interface (API) Management

1. Ada Application Program Interface (API) Management Clyde Roby SIGAda December 11, 2002

2. A Disclaimer • Clyde Roby is NOT President and CEO of Ada Core Technologies • The document upon which this discussion is based is an early draft and is still incomplete • Outline of discussion • Purpose, Background, Overview, Definitions • Approach for Registered and Managed APIs • Responsibilities • Charter, Membership, …

3. Purpose • To provide a mechanism for the management of Application Program Interfaces (APIs) for the Ada programming language • Standardized APIs • Registered APIs – focus of our discussion • Unregistered APIs

4. Background • Most Ada bindings to APIs are unmanaged • Most Ada bindings are hard to find • If found, little information is included with them • No automatic announcement of updates (if any) • Do not evolve as Ada evolves • ISO/WG9 requested proposals from SIGAda and Ada-Europe • ISO/WG9, Ada-Europe, and SIGAda work together to manage Ada bindings to APIs

5. Overview • Registered APIs will be publicly available • Ada API web page • Compilable Ada API • Artifacts (examples, tutorials, known problems, lessons learned, etc.) • Procedures to easily Register APIs • APIWG responsible for registration and public availability (on web page or links) • APIWG subgroups to maintain/evolve API ???

6. Definitions • ACM SIGAda, Ada-Europe • Ada • Ada Binding • Application Program Interfaces (APIs) • API Working Group (APIWG) and APIWG Subgroups • API Home Page • ISO/WG9

7. Definition of APIs • Standardized APIs – provided in the Ada LRM or through secondary ISO standards (e.g., ASIS) • Registered APIs – Ada bindings or APIs made publicly available via the API web page; individual or organization is responsible for each Registered API • Unregistered APIs – neither, but a link may be provided on the API web page

8. Definition of Registered APIs • Registered APIs – keeping up with who/where API is developed and/or maintained by a third party, with permission • Registered and Managed APIs – Subgroup responsible for (possible development and) maintenance of API; changes managed via consensus; Subgroup baselines and versions API • Registered APIs are NOT standards

9. API Home Page / Web Site • Provides compilable Ada API for each Registered API • Includes valuable artifacts • Examples, tutorials, useful tips • Known problems, lessons learned, etc. • On SIGAda’s web page -- ??? • May contain links to Unregistered APIs • May be mirrored on Ada-Europe website

10. API Working Group (APIWG) • ACM SIGAda chartered Working Group to manage Registered APIs • Chair’s reponsibilities include • Updating API web site for all Registered APIs • Coordinating work of all Subgroups • Define Charter for APIWG

11. APIWG Subgroups • Subgroup for each Registered and Managed API • Subgroup chair is responsible for the maintenance and evolution of the particular Registered and Managed API • Subgroup responsible for evolving API (via consensus), including baselining the API, versioning of new releases, and identifying associated artifacts

12. Approach for Registered APIs • Provide current set of developed Registered APIs on web page • API is provided unchanged from originally developed API, with associated artifacts • If requestor is not the API developer, APIWG Chair seeks proper permissions to place API (now and forever?) in the public domain • If permission is granted, all artifacts, including source code placed on APIWG web page; APIWG Chair announces it; others may also add artifacts (tutorials, examples, etc.)

13. Approach for Registered and Managed APIs • Ada Binding evolves as API evolves • Subgroups responsible for evolution and maintenance of each API • Web page identified and email list created • Necessary artifacts can be placed on web site (documentation, tutorials, examples, etc.) • Email list used for Subgroup discussions, Subgroup business, notification to others

14. Responsibilities of SIGAda EC • Creates APIWG and appoints Chair • Approves APIWG Charter • Approves creation of APIWG Subgroups and Chairs • Provides necessary support to APIWG and Chair, all Subgroups and Chairs • Yearly assessment of Subgroup viability and possible dissolution

15. Responsibilities of APIWG Chair • Maintain current artifacts for all Registered APIs • Secure approval to place third party APIs on APIWG web page • Facilitate SIGAda EC approval of each Subgroup • Ensure Subgroups are viable and maintain effective web pages for their API

16. Responsibilities of Subgroup Chairs • Develop, Maintain, Evolve the Ada Binding to their API (via consensus) • Maintain their API and its artifacts on the API’s web page • Approve baselines and versions of their API • Recommend replacements of their APIs when they are no longer viable

17. Members of the Ada Community • Recommend to the APIWG Chair those APIs to be established as Registered APIs • Recommend to the APIWG Chair those APIs to be established as Registered and Managed APIs • Provide feedback to the APIWG Chair and API Subgroup Chairs to make more (valuable and useful) information available to the Ada community

18. APIWG Charter • To be created from discussions about this presentation in this forum this evening • Should there be separate Charters for each Subgroup?

19. Membership • Membership in the APIWG or any of its Subgroups is open to any interested party • Members are responsible for their own expenses • APIWG Chair must be a member of both ACM and SIGAda (or Ada-Europe) • Other members are encouraged to be members of SIGAda or Ada-Europe

20. APIWG Home Page • A resource to the entire Ada community • Publicly available (no password) • To upload the necessary artifacts to the APIWG web pages, one must have an account on the ACM server (this usually means that one must be a member of ACM and SIGAda)

21. APIWG Email Lists • Each Subgroup will have their own email discussion list • Anybody can be a member of that Subgroup’s email list • Any member of the list can freely post • Others’ posts must be approved by the list owner • List owner must be a member of ACM and SIGAda

22. Announcement of API Versions • Each API Subgroup is responsible for setting the current version of their API • Notification of the latest version should be • Posted on the web • Announced in Ada Letters • Announced through the Subgroup’s email list • New versions will be in the monthly announcements of the SIGAda-Announce list (also? Ada-Europe, Team-Ada, WG9)

23. Why SIGAda and Ada-Europe? • Lightweight process carried out by volunteers to share bindings to APIs among the Ada community • Provides a forum and mechanism to evolve APIs as needed so that changes can be made without involving ISO/WG9 • When ready, APIs may be formally standardized by ISO/WG9

24. Candidates for possible APIs? • Possible Subgroups to Register APIs • Files/Directories – done • Sockets – exists within GNAT • HTTP/CGI • Timezones • Environment variables • ODBC/JDBC or equivalent • XML • others… • Base upon POSIX and/or Win32 and/or others? • Can we define these within a year?

25. Discussion