Workshop report -- WWW5, 6 May 1996

Status: 20/5/96
Program

Programming the Web - a search for APIs

Participants, Keynote, Papers, References, Wrap-up, Comments, Mailing list

Introduction

There is a trend towards replacing monolithic general-purpose Web browsers by more finely-tuned Web applications enhanced with user-specific functionality, such as for example applets that allow for user-interaction or the display of dynamic information.

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.


slide: Introduction

Rationale

The workshop was intended to focus on concepts and requirements for high-level API suitable for developing Web-aware applications. An explicit goal of the workshop was to publish state of the art references to existing APIs.

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.


Rationale

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]

slide: Rationale

As can be expected opinions diverged on many of the issues, even the need for APIs to exist at all. To get the flavor of the positions presented by the participants, some of the points put forward are listed below:
  • 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, ...

slide: Positions

A summary of the papers can be found together with the list of participants.

Organisation

Apart from a keynote speech, the workshop program consisted of four rounds:

  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
and two discussion sessions
  1. Requirements for APIs
  2. A catalogue of state of the art APIs

slide: Organisation

The discussions were lively, but did not result in a consensus concerning requirements for APIs. This remains a topic for further discussion. Nevertheless, a wealth of material was presented, some of which is reflected in the catalogue of APIs. This catalogue needs to be extended. Also, what we need is an evaluation of the APIs listed there.

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?

The keynote was given by Luca Cardelli. As testified by a summary of the main points below (recorded by Dave de Roure) it is not altogether clear what exactly is the Web's model of computation, nor what support should be provided on a language level or API level.

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

See www.research.digital.com/SRC/personal/Luca_Cardelli/home.html for more material.


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


The slides are available at (A4) www.research.digital.com/SRC/personal/Luca_Cardelli/Slides/WWW5APITalk.A4.ps
(USLetter) www.research.digital.com/SRC/personal/Luca_Cardelli/Slides/WWW5APITalk.ps

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

Frystik Nielsen  [W3CReference] presented an overview of the LibWWW reference library, featuring stream and channels, and offering support for plug-ins. The LibWWW is an application-independent light-weight Web API. Lessons learned from a previous version were that APIs should be layered, open-ended and thread-safe. Robert Thau  [Configure] stressed the importance of configuration. He discussed some of the configuration options available for the Apache server  [Apache]. In particular, configuration through an RPC-like mechanism, or CORBA interface, needs to be studied.


slide: Round 1


Round 2: Objects and abstractions

A variety of abstractions was presented, all intended to facilitate the development of Web applications. Bernard Lang  [V6] presented the filter composition model underlying the V6 engine, which in a sense eliminates the need for explicit APIs. Mike Spreitzer  [DOOWWW] discussed a language-independent mechanism for the realization of Web applications employing distrubuted object  [ILU]. Finally, Richard Connor  [HIPPO] explored the idea of using persistent objects.


slide: Round 2

Requirements for APIs

To open the discussion about requirements for APIs, an inventory was presented encompassing complaints about the functionality of the Web, observations concerning its 'nature', general requirements for open systems development, a wish-list of desired behavioral characteristics and potential (technological) answers.
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

slide: Requirements for APIs

It was observed by Mark Brown that requirements could not be stated without an explicit indication of a perspective, that is the kind of application for which the API is intended. In contrast, the  [W3Creference] library makes no such distinction, but tries to provide a platform for a variety of applications.

Round 3: Applications and Users

In contrast to the previous rounds, which were primarily technology-oriented, in this round the focus of attention lay on the needs of particular areas of application. Ian Palmer  [VAPIS] presented an exhaustive overview of APIs for 3D and Virtual Reality applications, and proposed the notion of virtual APIs. Pierre Wellner  [Tele] discussed the requirements APIs should meet to enable resellable services. Thomas Koch  [Meta] discussed the needs for group-aware Web applications. Daniel Mavrakis  [VEMMI] presented a protocol allowing for the integration of Tele-services with the Web. And finally, Mark Brown  [FastCGI] discussed the employment of FastCGI to improve the server-side generation of documents. (See also his comments on the workshop.)


slide: Round 3


Round 4: Objects and more objects

The last round was devoted to the employment of object technology and interfacing the Web with data repositories. Bastiaan Schönhage  [DejaVu] discussed the Web components of the DejaVu framework. Anselm Baird-Smith  [Jigsaw] presented the design and realization of Jigsaw, a Java-based server. Mala Anand  [Broker] presented Oracle's solution to server-side plug-ins. Finally, replacing Andy Wood  [CAMEO], Benjamin Renaud from the Java Team discussed the new releases of the Java libraries, providing APIs for 2D/3D graphics, security, mobile methods, persistence and database access.


slide: Round 4


Discussion - What are APIs?

The application areas and solutions, whether object-oriented or not, covered a wide range of interests and did not suggest a canonical approach to the definition and development of APIs. In particular, as has been mentioned before, the somewhat blurry demarcation between computation models, languages and APIs seem to confuse all of us. Moreover, a catalogue of APIs seemed to be beyond our reach.

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.


slide: Discussion - What are APIs?


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

Nevertheless, we managed to break out of this impasse, by reconsidering what APIs are meant for, the development of Web-aware applications, and we made a start of listing our basic needs.


slide: Dimensions of APIs


Basic needs

In the discussion we came up with the following list of basic needs, that is functionality required by application developers:
  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

An additional need that was mentioned later on is support for multiple (natural) languages, see  [MAITS].


slide: Basic needs

Admittedly, in this list of basic needs, no distinction is made between the various possible perspectives, server-side, client-side, or what have you. The best we can do, as was suggested by Frystik Nielsen, is to gain experience with existing APIs (such as the ones listed in the catalogue and share these with the community.

A catalogue of state of the art APIs

Language support

General

Server-side

Client-side


slide: A catalogue of state of the art APIs


Conclusions

Conclusions, at this stage, seem to be premature.

Recommendations to W3C

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

As concerns (1), the general feeling was that in its current state CORBA does not provide an answer. As an alternative, ILU was mentioned.

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.


slide: Conclusions

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

References

www.msn.com/download/sdk/msactivedk.zip, 1996 www.geom.umn.edu/hypernews/get/interactive/index.html services applications in the World-Wide Web. ftp://ftp.netscape.com/server/fasttrack/unix/, 1996 Interfacing the web to an open agent-based market infrastructure. Protocol for the Internet.
eliens@cs.vu.nl