Re: Status: -> Progress:

Rick Troth <troth@rice.edu>
Errors-To: listmaster@www0.cern.ch
Date: Wed, 11 May 1994 18:56:04 +0200
Errors-To: listmaster@www0.cern.ch
Message-id: <Pine.3.89.9405111157.B18687-0100000@brazos.is.rice.edu>
Errors-To: listmaster@www0.cern.ch
Reply-To: troth@rice.edu
Originator: www-talk@info.cern.ch
Sender: www-talk@www0.cern.ch
Precedence: bulk
From: Rick Troth <troth@rice.edu>
To: Multiple recipients of list <www-talk@www0.cern.ch>
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 <troth@rice.edu>, Rice University, Information Systems