Re: Status: -> Progress:

Rick Troth <>
Date: Wed, 11 May 1994 18:56:04 +0200
Message-id: <>
Precedence: bulk
From: Rick Troth <>
To: Multiple recipients of list <>
Subject: Re: Status: -> Progress:
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
Content-Type: TEXT/PLAIN; charset=US-ASCII
Content-Type: TEXT/PLAIN; charset=US-ASCII
Mime-Version: 1.0
Mime-Version: 1.0
> Let me pitch an idea that would mean something to a new HTTP.  
> ... 
> Imagine a new httpd that doesn't write to a "filesystem", rather
> was written in the OO versions of tcl, perl(5?), or python.  
	This is already almost possible without a complete rewrite. 
This is why I suggested a "parameters" syntax 
		GET /path/path/path/object,parms?args [HTTP/1.0] 
	(whether that delimiter is a semi-colon or a comma,  
I don't care;  maybe it could even be an ampersand)   The "args" 
are dynamic,  while the "parms" are more (but not totally) static. 
The reason I mention it in this context is that it's specifically 
intended for *program* objects,  not ordinary files. 
> Attributes such as logging information, discretionary access, meta
> information such as indices and document owner would be object
> attributes in a "document class".   ... 
> Thus, could HTTP be extened to send any arbitrary "message" to
> the "document" object?  This perl5 or tcl-dp httpd would 
> recompose the document to send to the client, thus allowing 
> conformance with the stream it should be sending,   ... 
	This is really good stuff,  Paul.   But again,  I don't think 
we have to completely reinvent HTTPD to accomplish it.   I think we're 
almost there with some of the latest juicy CGI ideas.   Any "object" 
that's a program instead of a file can accomplish what you're after. 
Just be vewy vewy kay-uh-ful about the security implications. 
> /ramble off
> --Paul
Rick Troth <>, Rice University, Information Systems