Re: Server control over history?

rodw@cbl.leeds.ac.uk
Errors-To: listmaster@www0.cern.ch
Date: Wed, 16 Feb 1994 13:31:45 --100
Message-id: <3622.9402161226@cblelcc.cbl.leeds.ac.uk>
Errors-To: listmaster@www0.cern.ch
Reply-To: rodw@cbl.leeds.ac.uk
Originator: www-talk@info.cern.ch
Sender: www-talk@www0.cern.ch
Precedence: bulk
From: rodw@cbl.leeds.ac.uk
To: Multiple recipients of list <www-talk@www0.cern.ch>
Subject: Re: Server control over history?
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
Content-Length: 1162
Paul Burchard <burchard@edu.umn.gw.horizon> writes:
>
>Fill-out forms, as they exist now, can hold arbitrary state  
>information during a sequence of transactions (this will soon be  
>completely straightforward and aboveboard using type="hidden"  
>fields.)
>
>In the W3Kit system used to build our interactive Web apps, the  
>complete per-user application state is in fact encoded in the  
>fill-out form, as an archive of persistent objects.  This allows  
>rollback, even random access to history, since despite appearances  
>the server remains fully stateless.

A result of this approach is that all the forms with instantiated
state have the same url.  Therefore, to go to the same state again
you either have to save a local copy of the form or follow a set of links to 
reach the desired state.  Saving the page's url on your hotlist won't get
you back to the same place, same goes for mailing the url to someone -- they
will not be able to get to the same place.  I think these failing underline
that a url should contain enough state to enable a script to regenerate the 
html page.

Rod
----
Roderick Williams          R.J.Williams@cbl.leeds.ac.uk