HTTP Server Futures (interfaces and protocols)

Tony Sanders <sanders@BSDI.COM>
Errors-To: listmaster@www0.cern.ch
Date: Wed, 11 May 1994 20:25:26 +0200
Errors-To: listmaster@www0.cern.ch
Message-id: <199405111821.NAA19039@austin.BSDI.COM>
Errors-To: listmaster@www0.cern.ch
Reply-To: sanders@BSDI.COM
Originator: www-talk@info.cern.ch
Sender: www-talk@www0.cern.ch
Precedence: bulk
From: Tony Sanders <sanders@BSDI.COM>
To: Multiple recipients of list <www-talk@www0.cern.ch>
Subject: HTTP Server Futures (interfaces and protocols)
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
Organization: Berkeley Software Design, Inc.
Organization: Berkeley Software Design, Inc.

Rick Troth writes:
> Paul wrote:
> > Imagine a new httpd that doesn't write to a "filesystem", rather
> > was written in the OO versions of tcl, perl(5?), or python.  
..
> > Attributes such as logging information, discretionary access, meta
> > information such as indices and document owner would be object
> > attributes in a "document class".  The HTML itself could be
I'm currently working in perl5 to write Plexus 4.0 which will basically
do what you describe by overlaying an "object database" (of some form)
with the standard filesystem in some, hopefully, interesting ways.

Clearly, the current server design (of at least CERN, NCSA, and Plexus)
isn't going to be able to cleanly support all of the HTTP features we want
to be able to support.

> 	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] 
I'm thinking about something like this (where [stuff] means it's optional):
     GET object[{msg}][;metadata][?querydata]
Where ``msg'' is defined by the object (and to some extent the server,
perhaps added by some standard, see next paragraph) but is probably some
form of attribute/value pair.  And "metadata" is resevered for
future standardization in the HTTP URL space (since there has been
some talk about this in the past though the exact syntax may differ
from my example).

Perhaps we need to form a group to define a Common HyperObject Protocol
so servers can agree on these conventions, like CGI does for the current
interface but perhaps a little more comprehensive.

--sanders