| OOP

A Post-Hoc Rationalization of the Object Oriented Design of the World Wide Web

(that's a fancy way to say "I told you so!" :-)

Abstract

By investigating the duality between APIs and network protocols, we re-discover the design of the web, and the relationship between mobile/distributed objects and knowledge sharing/exchange. For background, be sure to see "Toward A formalism for communication on the World Wide Web" posted to www-talk back in Feb 94.

Intro

The WWW/OOP Thesis: the hypermedia architecture of the web is isomorphic to--or perhaps a special case of--modern distributed object systems. URLs are symbols in the intertwingled GEB sense.

• Web Document
• Dexter Node
• CORBA Object
• COM Object

Motivation: Why Bother?

• Automation: machine translates from formal interface description to network protocol stubs
• Shared understang: one page protocol description (for those who grok the formalism)
• Syntax/Transport independence: interface abstracted from communications mechanism
• Rational Evolution:  extending the protocol via subtyping/inheritance allows us to localize and reason about the changes
• Genericity: abstraction should allow us to layer technology such as security, transactions
• Automatability: expose richer semantics for manipulation by programs

The Trivial Mapping

of HTTP into an RPC system:

procedure GET(path: String): ByteSequence;

• Where are the objects?

Introducing Objects

interface Document {
	GET(): ByteSequence;
}
interface Server {
	docNamed(path: String): Document;
	};

• Insight: URL = object identifier
• use RPC naming facility to move Server object functionality down into infrastructure

We know GET can and should be cached. How do we tell the RPC infrastructure?

RPC Caching Facility: Functional Methods

interface Document {
	functional GET(): ByteSequence;
}

• documents change over time. Cache coherency?

This looks like HTTP 0.9! What about error codes? Accept: headers for format negotiation?

Adding HTTP 1.0 (RFC822) Expressiveness

interface Document {
	GET(version: String, fields: FieldList):
		struct {
			version: String;
			status: Integer;
			header: FieldList;
			body: ByteSequence;
		}
	}

• must check for exceptional responses manually?
• syntax of fields not captured:
  • programmer still has to do date parsing
  • which fields are required/optional/prohibited in which context?

We don't want to think about versios at this level. Can we make the version implicit in the interface by using RPC facilities?

Can we exploit RPC exception facilities to avoid manually checking for error codes?

Using RPC Version, Exception Facilities

interface Document version "HTTP/1.0" {
	GET(path: String, version: String, fields: FieldList):
		struct {
			header: FieldList;
			body: ByteSequence;
		} raise(Partial, ClientError, ServerError)
	}
exception Partial, ClientError, ServerError {
	status: [0..99];
	message: String;
	header: FieldList;
	body: ByteSequence;
	};

• Using status codes 6XX thru 9XX requires interface change (new exception)
• Does this require a version change? Is version mismatch handled gracefully?
• Hmmm... what about 100 continue?

Can we express more of the structure and semantics of the header fields?

Using Typed Arguments

in stead of string syntax: (ref 1.1 spec)

interface Document{
	GET(      Accept-Charset: CharSetMetrics, 
                      Accept-Encoding: Encodings,
                      Accept-Language: LanguageMetrics,
                      Authorization: Credentials,
                      From: String,
                      Host: String,
                      If-Modified-Since: Date,
                      If-Match: String,
                      If-None-Match: String[],
                      If-Range:
                      If-Unmodified-Since: Date,
                      Max-Forwards: int,
                      Proxy-Authorization: Credentials
                      Range: record start, end: int end,
                      Referer: Document,
                      User-Agent: Product) : Response;
type Response = struct
	struct { Age : Duration,
                       | Location: Document,
                       | Proxy-Authenticate: Challenge,
                       | Public: MethodList,
                       | Retry-After: Delay,
                       | Server: Product,
                       | Vary: VariantMap,
                       | Warning: String
                       | WWW-Authenticate: Challenge,
			body: ByteSequence;
		} raise(Partial, ClientError, ServerError)
	

• interface begins to look large, complex, brittle
• @@optional argument facility? (M3: yes. ILU, CORBA, COM: no)
• Host: header disappeared for the same reason the path argument did.

Using RPC Authentication Facility

in stead of Authorization argument.

interface Document{
	GET(      Accept-Charset: CharSetMetrics, 
                      Accept-Encoding: Encodings,
                      Accept-Language: LanguageMetrics,
                      From: String,
                      If-Modified-Since: Date,
                      If-Match: String,
                      If-None-Match: String[],
                      If-Range:
                      If-Unmodified-Since: Date,
                      Max-Forwards: int,
                      Range: record start, end: int end,
                      Referer: Document,
                      User-Agent: Product) : Response;
type Response = struct
	struct { Age : Duration,
                       | Location: Document,
                       | Proxy-Authenticate: Challenge,
                       | Public: MethodList,
                       | Retry-After: Delay,
                       | Server: Product,
                       | Vary: VariantMap,
                       | Warning: String
                       | WWW-Authenticate: Challenge,
			body: ByteSequence;
		} raise(Partial, ClientError, ServerError)

• credentials disappears into infrastructure. @@Challenge still needed? check ILU/gss API
• note: RPC secruity facilities typically provide confidentiality and/or integrity via MAC and/or encryption. Rarely do they provide non-repudiation. A public key operation per RPC is just too much to put in the infrastructure. See signed Entities below...

Why do semantically void information such as From: and User-Agent: and Server show up at this level?

Using Context Handles

interface Document{
	GET(      Accept-Charset: CharSetMetrics, 
                      Accept-Encoding: Encodings,
                      Accept-Language: LanguageMetrics,
                      Host: String,
                      If-Modified-Since: Date,
                      If-Match: String,
                      If-None-Match: String[],
                      If-Range:
                      If-Unmodified-Since: Date,
                      Max-Forwards: int,
                      Range: record start, end: int end,
                      Referer: Document : Response;
type Response = struct
	struct { Age : Duration,
                       | Location: Document,
                       | Public: MethodList,
                       | Retry-After: Delay,
                       | Vary: VariantMap,
                       | Warning: String
			body: ByteSequence;
		} raise(Partial, ClientError, ServerError)

• @@ only sematically void stuff (UA, Server, QOS) only? or can we express PEP str=required?

Does RPC marshalling facility require that the whole body be in memory?

Using Streams

interface Document extends IPersistStream{
	load(a: Anchor){
		bc = new BindingContext()
		// set up my bc with persistence formats that I know about
		loadFrom(a.openRead(bc));
	}
	displayOn(w: Window);
}

interface IPersisStream{
	loadFrom(s: InputStream);
	saveTo(s: OutputStream);
}


interface BindingContext{
	@@ captures semantics of following headers:
// data understandin capabilities
      Accept-Charset: CharSetMetrics, 
                      Accept-Encoding: Encodings,
                      Accept-Language: LanguageMetrics,
// freshness info
                      If-Modified-Since: Date,
                      If-Match: String,
                      If-None-Match: String[],
                      If-Range:
                      If-Unmodified-Since: Date,
// latency requirements
                      Max-Forwards: int,
}

interface Anchor { /* ala IMoniker, CosNaming::NamingContext */
	openRead(bc: BindingContext, referer: Anchor): InputStream; (* GET *)
	openWrite(bc: BindingContext, referer: Anchor): OutputStream; (* POST *)

        openAppend(bc: BincingContext, referer: Anchor): OutputStream; (* PUT *)
	delete(bc: BindingContext, referer: Anchor); (* DELETE *)
@@ mkdir? 9fs? DLS (link management)?

@@type Response = struct
	struct { Age : Duration,
                       | Location: Document,
                       | Public: MethodList,
                       | Retry-After: Delay,
                       | Vary: VariantMap,
                       | Warning: String
			body: InputStream;
		} raise(Partial, ClientError, ServerError)
}

• format negotiation: document object knows what formats it can un-freeze-dry itself from
• Hmmm... how many round trips to get document content?
• Is a stream a first-class object? i.e. does it have a URL?
• special marshalling for streams (DCE pipes, ILU bulk transfer, Modula-3 Rd/Wr)

Adding Filesystem Caching Semantics to Streams

interface Entity: InputStream {
	contentId(): URI; (* URN *)
	location(): URI; (* URL *)
	lastModified(): Date;
	validator(): ETag;
	md5();
	volume();
Age : Duration,
}

interface BindingContext{
	attribute CacheControl;
	maxForwards(): CARDINAL;
                      If-Modified-Since: Date,
                      If-Match: String,
                      If-None-Match: String[],
                      If-Range:
                      If-Unmodified-Since: Date,
                      Max-Forwards: int,
	Accept-Charset: CharSetMetrics, 
                      Accept-Encoding: Encodings,
                      Accept-Language: LanguageMetrics,
                      Range: record start, end: int end,

                       | Warning: String

}

interface Anchor : IMoniker{
	bindToStorage(bc: BindingContext, referer: Anchor): Stream
@@Hmm.... what about...
	                       | Public: MethodList,
                       | Vary: VariantMap,

raise(Partial, ClientError, ServerError)
	
	}

interface Document : IPersistStream{
	load(data: InputEntity);
	saveTo(data: OutputEntity);
}

	GET(      
type Response = struct
	struct { 
                       | Location: Document,
	body: InputStream;
		} 

• Last Modified Date (how about creation date? owner?)
• Content-MD5
• Etag: strong validator, weak validator
• future: volumes (matches functinality of OM Express nicely)
• Content-ID?
• binding context: belief system? trust info?

Attaching Application Security Semantics to Entities

interface SignedEntity {
	prove(antecedent: Formulas, conclusion Formula) raise Undecidable (f: Formulas);
}
interface EncryptedEntity {
	decrypt(k: Key): Stream;
}

• Code Signing
• Non-repudiation
• Payment?
• "cryptolope" features

Intellegent Naming: Anchors, Symbols, Monikers

• URLs are both the "print name" and persistance format for Anchors
• spero's value dictionary, ala X atoms?

Evolvability, Interface Negotiation

• Add an interface ID parameter to a few methods, like bindToStorage()! (perhaps an array of IIDs. See: DCOM RQueryInterface)

Profiles: Name Services and Binding Revisited

• Named profiles?
• binding context has-a or is-a profile?
• interaction with Referer?
• interaction with PEP? capability-based binding vs. before/after filters?
• QueryInterface?

Filters

• Are these tried and true?
• Is this where PEP fits in?

Generic Object Interfaces

interface Bank{
	open(customerName: String): Account;
	};
interface Account{
	deposit(amount: Currency);
	withdraw(amount: Currency);
	balance(): Currency;
	};

HTTP mapping:

OPEN /bank HTTP/1.new
CustomerName: Fred Jones

	200 OK
	Content-Type: application/url

	http://server/account/1

Documents Aren't the Only Object

• lots of different objects from the same stream: extract business card info out of HTML
• bind to different entities using differen bindingContext info. Use Vary: stuff? discover links?

POST for DII, IDispatch

• also: VHLL Objects, desktop message bus, ...
• HTTP POST = IDispatch::invoke()
• = Tk send
• = python apply
• what's next after www-url-encoded and multipart/form-data? s-expressions? M3 pickles? Java serialization?

Business Cards and Magazine Subscriptions: Composeable Web Objects

• @@Rohit: I forget: what annotations did we need to automate web forms?

Open Issues: CGI, CCI

• what does the CCI interface look like in this model?
• Burchard's compound docs, frames?
• CGI? (and FastCGI?)

References

9FS

versatile name/file service

ILU

DCOM