Re: Status: -> Progress:

Paul Everitt <peveritt@pandora.ncts.navy.mil>
Errors-To: listmaster@www0.cern.ch
Date: Wed, 11 May 1994 17:04:37 +0200
Errors-To: listmaster@www0.cern.ch
Message-id: <Pine.3.89.9405110949.A26639-0100000@pandora>
Errors-To: listmaster@www0.cern.ch
Reply-To: peveritt@pandora.ncts.navy.mil
Originator: www-talk@info.cern.ch
Sender: www-talk@www0.cern.ch
Precedence: bulk
From: Paul Everitt <peveritt@pandora.ncts.navy.mil>
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
> > Paul "S." Wain writes:
> > 
> > > Anyone for HTTP/1.1 ? :)
> > 
> > It would be useful to start a list of features for a next major
> > release of HTTP, e.g:
> > 
> >     o   Secure HTTP
> >    o   Anonymous Session Ids
> >    o   Additional Logging info
> >    o   Multi-GETs
> >
> > Any other ideas?

Let me pitch an idea that would mean something to a new HTTP.  
I won't spleen ad nauseum, as I would rather get a prototype 
working before blue-skying. Unfortunately, I don't know tcl-dp,
perl5, or python, or why I should be choosing them!  Anyway...

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
decomposed into a more granular object, with child objects for
each entity.  This granularity would allow more attributes such
as versioning for group editing and workflow "intelligence".

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, but the ability
to notify the client what public methods the document supports,
and allowing the client to send messages altering the state of
the document object, would be, well, good :^)

/ramble off

--Paul