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