UNDERSTANDING EXTENSIBILITY IN HTTP APPLICATIONS

Rohit Khare and Adam Rifkin

$Id: extensible-http.html,v 1.7 1998/01/15 23:10:30 adam Exp $

Work very much in progress.

Abstract

In considering the future of "compositional software architectures" as rendered through distributed object systems and on the World Wide Web, it is useful to set aside the hype of new technologies and consider what is already being accompished with existing infrastructures. On the Web, users and developers have already adopted two powerful ways to compose active processing with information distribution: active pages ("cgi-bin") and active proxies. In this we focus on the latter as a tool for parties beyond the original developer to externalize extensions to a software or information architecture.

Outline of this Paper

In the beginning, HTTP was an information access protocol. Entity = resource at some time. Resources were static, not HTTP.

With gateway interface, ACTIVE pages. Databases instead of just a file system. A page could be a program.

CGI = COMMON gateway interface. URL gives way to name, gateway gives access to environment variables.

People thought resources were static from the start, but they weren't. The very first application was dynamic -- it talked to an SQL database.

Moral of the story: DECENTRALIZED extensibility. Political: owner of cgi-bin not equal to owner of server. Win32 is extensible too, but by contrast it is only extensible by the developer of the app.

Other moral of the story: INDEPENDENT extensibility. DEMOCRATIC. Crystallize, promulgate, yank it forward, look ahead.

PHILOSOPHY of PEP: cgibin allows independent extensibility of resources. HTTP+PEP allows independent extensibility of protocols.

Check: what's in the dogpile for PEP literature?

Outline of this paper.

1. PEP is a unified conceptual model of what an extension is. Isomorph to active page or active proxy.
2. Naming: unified syntax via URL.
3. cgi = 1 plugin. PEP = sequential AND parallel composition, with multiple plugins. Composibility. Pipelines.
4. NEGOTIATION. How can we all just get along? Naming, ESMTP, Telnet, negotiation of extensions.
5. Detailed syntax of PEP.
6. Examples: SEA, JEPI.
7. Conclude: will be standard. Evolutionarily better than custom developed Wev servers.

References

List of standard references with authors name, etc. For now, see our position paper to Workshop on Compositional Software Architecture

Author Addresses

Rohit Khare, rohit@uci.edu

Rohit Khare served as a member of the MCI Internet Architecture staff in Boston, MA in the summer 1997, when this paper was written. He was previously on the technical staff of the World Wide Web Consortium at MIT, where he focused on security and electronic commerce issues. He has been involved in the development of cryptographic software tools and Web-related standards development. Rohit received a B.S. in Engineering and Applied Science and in Economics from California Institute of Technology in 1995. He joined the Ph.D. program in computer science at the University of California, Irvine in Fall 1997.

Adam Rifkin, adam at xent dot com

Adam Rifkin received his B.S. and M.S. in Computer Science from the College of William and Mary. He is presently pursuing a Ph.D. in computer science at the California Institute of Technology, where he works with the Caltech Infospheres Project on the composition of distributed active objects. His efforts with infospheres have won best paper awards both at the Fifth IEEE International Symposium on High Performance Distributed Computing in August 1996, and at the Thirtieth Hawaii International Conference on System Sciences in January 1997. He has done Internet consulting and performed research with several organizations, including Canon, Hewlett-Packard, Griffiss Air Force Base, and the NASA-Langley Research Center.