Re: Server control over history?

Paul Burchard <burchard@horizon.gw.umn.edu>
Errors-To: listmaster@www0.cern.ch
Date: Tue, 15 Feb 1994 18:53:39 --100
Message-id: <9402151747.AA08949@horizon.gw.umn.edu>
Errors-To: listmaster@www0.cern.ch
Reply-To: burchard@horizon.gw.umn.edu
Originator: www-talk@info.cern.ch
Sender: www-talk@www0.cern.ch
Precedence: bulk
From: Paul Burchard <burchard@horizon.gw.umn.edu>
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: 2136

Dave_Raggett <dsr@hplb.hpl.hp.com> writes:
> [Paul Burchard <burchard@geom.umn.edu> writes:]
> > Exactly---but this sort of automatic unlimited UNDO
> > capability is a wonderful thing for increasing interactivity.
> > The higher bandwidth of interaction you want to achieve,
> > the more useful it becomes.
> 

> But, how do you get the database at the other end to roll
> back in sync with the browser. At the very least the
> browser would have to send a message to the server to
> roll-back each step. This is well outside the current
> HTTP/fill-out forms mechanism. Worse, I can't see how
> its possible to roll-back the state in all cases. 


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.

I realize that database front ends can't go quite as far, since the  
server has its own state independent of the state of ongoing  
transactions with each user.  But if users would frequently want to  
undo or edit transactions by backtracking, then the front end should  
probably use an explicit transaction commitment scheme anyway.  Under  
that assumption, random access could at least be provided within a  
sequence of uncommitted transactions.

Again, I'm not arguing that you should *always* be able to provide  
complete random access to the server, just that the hypertext format  
of the Web raises user expectations to a point where you ought to  
have some pretty good reasons for the limits you do place on random  
access.

--------------------------------------------------------------------
Paul Burchard	<burchard@geom.umn.edu>
``I'm still learning how to count backwards from infinity...''
--------------------------------------------------------------------