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 SIGAdas 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
• Chairs 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 APIs
  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 Subgroups 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 Subgroups 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