> 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 <[email protected]>
``I'm still learning how to count backwards from infinity...''
--------------------------------------------------------------------