Workshop report -- WWW5, 6 May 1996

Programming the Web - a search for APIs

Introduction

This raises the issue of what support should be provided for developing such applications. So a workshop was organized for the WWW5 entitled Programming the Web - a search for APIs with the goal of defining requirements for high-level APIs and frameworks for Web programming, and characterizing suitable components for Web-aware applications.

Rationale

The papers that were submitted covered a wide range of interests, including computation models, applications and user requirements, software architectures and libraries as well as heuristics and guidelines for API developers.

Computation Models

 [Model],  [DOOWWW],  [CAMEO],  [HIPPO],  [V6]

Applications and Users

 [Meta],  [UOD],  [URA],  [VAPIS],  [VEMMI] ,  [Tele]

Software Architecture

 [W3CReference],  [V6],  [Broker],  [CAMEO],  [DejaVu],  [Jigsaw],  [FastCGI]

Heuristics and Guidelines

 [W3CReference],  [Configure],  [VAPIS]

• APIs should be layered, open-ended, thread-safe, platform-independent, ...
• Configuration must be part of API.
• APIs must provide support for monitoring, notification and triggering.
• APIs should be avoided -- instead filter composition devices should be used.
• APIs should provide for callbacks, plug-ins, ...

Organisation

1. Round 1: Reference libraries -- configuration and composition
2. Round 2: Objects and abstractions
3. Round 3: Virtual APIs and Users
4. Round 4: Objects and more objects

1. Requirements for APIs
2. A catalogue of state of the art APIs

Note: This report reflects my personal view of the workshop and its outcomes. Look at the comments for an assesment from the point of view of the participants.

Keynote -- What is the Web's model of computation?

• There is concept of "global computation" (eg crawlers) but...
• Web is not uniform (except HTTP)
• Speed of light is finite => mobility a necessity
• Single global structure not enough, view as multiple "global computers" ("intrawebs", maybe non
• HTTP, non-Java-VM) each with some guarantees
• model of computation = language independent model for APIs + model on which to base language constructs
• turn web into uniform structure or "program the complexity" (yes)?
• existing programming models don't capture locality
• observables like referential integrity and QoS not in trad. models
• Different languages may be appropriate for different "global computers" e.g. Telescript, Obliq, Java
• Semantics needed to understand computational assumptions and requirements, answer important security questions, reason about programs
• Issues: Typing (MIME is a mechanism...?), security, reliability, modularity, resource management

In particular, Cardelli's speech made clear that the distinction between API, languages and computation models is not clear cut.

Round 1: Reference libraries - configuration and composition

Round 2: Objects and abstractions

Requirements for APIs

Complaints

• lack of referential integrity
• undetected failures
• no control over Quality of Service

Observations

• dynamic quality of services
• complex interaction

Requirements

• uniformity, openness, flexibility, orthogonality, layered, platform-independent

Behavior

• reliable, configurable, monitoring, notification, triggering, thread-safe

Answers

• object-oriented, components, virtual APIs, callbacks, plug-ins

Round 3: Applications and Users

Round 4: Objects and more objects

Discussion - What are APIs?

An attempt to overcome the confusion by restricting ourselves to discussing the requirements for the (future) Java class libraries failed, surprisingly, because the majority felt that the restriction to a particular (!) language was not appropriate.

So the workshop was in danger of being halted, with a number of questions unanswered. What actions should we take in terms of recommendations to the W3C? What perspectives can we (meaningfully) distinguish? And, what (exactly) are our areas of interest? For example, although many of the solutions proposed were object-oriented in spirit, only few were so in the flesh.

Actions

• Define a distributed model of computation that suits the Web.
• Define canonical (language-independent?) object models for ... resources, application domains ...

Perspectives

• servers - extensions
• browsers - clients, viewers, configuration
• agents - e.g. payment

Interests

• distributed objects
• plug-in components
• formalization of requirements and solutions

Basic needs

1. resolving URLs
2. authentication of users
3. communication (and negotiation)
4. distribution - eg. applets accross sites
5. security - authentication of network identity
6. configuration - also the delegation of configuration
7. billing and payment
8. application persistence - i.e. states
9. QOS and QOT demands - e.g. bandwidth
10. notification and monitoring

A catalogue of state of the art APIs

Language support

•  [ILU]

General

•  [W3Reference]

Server-side

•  [ISAPI] documentation, Microsoft Corporation, in ActiveX Alpha SDK, http://www.msn.com/download/sdk/msactivedk.zip, 1996
• NCSA server documentation, http://hoohoo.ncsa.uiuc.edu 1995
•  [NSAPI], Netscape server API documentation http://home.netscape.com/newsref/std/server_api.html, 1995 ftp://ftp.netscape.com/server/fasttrack/unix/, 1996
•  [Apache]
•  [FastCGI]
•  [Broker]

Client-side

•  [DejaVu]

Conclusions

Recommendations to W3C

1. Develop Corba compliant API for LibWWW?
2. Define formalized object models for the Web?

Very surprisingly, a vote on (2) resulted in a majority in favor of a more formal approach. However, not in a prescriptive fashion but rather to better understand the nature of the Web and the basic needs of application developers.

Hopefully, this is not the end of the discussion. To the participants, thanks for your contribution. Anton Eliëns

References