Re: Server control over history?

Stan Letovsky <letovsky-stan@CS.YALE.EDU>
Date: Tue, 15 Feb 1994 16:00:10 --100
Message-id: <199402151409.AA28474@RA.DEPT.CS.YALE.EDU>
Reply-To: letovsky-stan@CS.YALE.EDU
Precedence: bulk
From: Stan Letovsky <letovsky-stan@CS.YALE.EDU>
To: Multiple recipients of list <>
Subject: Re: Server control over history? 
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
Content-Length: 3044
From: Dave_Raggett <>
To: Multiple recipients of list <>
Subject: Re: Server control over history?

Neal Holtz writes:

> Is anyone else interested in having the server have some control over
> a clients history list?
> ... In these cases, you probably do not want to see these nodes put
> on the history list.

Dave Raggett replied:
I have been worrying about this too. ...
Another common case occurs with fill-out forms. Keeping a history of
the successive stages of filling out a form, and the updates to that
form by the server is of dubious value (it would only make sense in the
context of a multi-level UNDO mechanism).  So it makes sense to flag
intermediate steps as not to be placed on the history stack. This could
be done by an element in the document's head or an HTTP header (the two
are formally equivalent).

So how about:

        a) adding an attribute to the <A> element to rollback the
           history stack to the node before the *last* occurrence of
           the linked node, e.g.

           <A HREF="main_doc.html" ROLLBACK>Return to Home page</A>

        b) Defining a new HTTP header for history hints which servers
           can generate based on META elements in document heads, e.g.

           <META NAME="History" VALUE="discard">

For (b) clients would get the HTTP header

           History: discard

Other values such as "rollback" may be useful. This seems preferable
to adding yet another element to HTML+. Let me know what you think,
and I will ammend the HTML+ spec.

Dave Raggett

----- End Included Message -----

>> Letovsky replies:

(Subsection on Immediate Commands) I propose another approach to this
issue, based on techniques common in database interface tools.
Specifically, I propose:

	o a hash table allowing arbitrary attribute+value pairs to
	be associated with widgets (and documents).
	o html extensions allowing those attributes to be accessed and set.
	These include a header directive analogous -- I think -- to Dave's proposed
           <META NAME="History" VALUE="discard">
	which I called 
	the idea being that inhibits pushing a new document onto the stack,
	which is the standard client action.

	The GET and PUT directives proposed there constitute an approach to
	implementing a means of communicating fill-out form deltas in a
	non-pushing context. I urge people thinking about this issue to look
	beyond simply setting the visible values of the fields, and to consider
	the need to manipulate invisible associated values. These may be previous
	values of the fields, needed in order to create, e.g. SQL statements along
	the lines of
		update table set field = newvalue where field = oldvalue
	as well as for undo change commands; also to store surrogate keys (ID#s)
	which you may not want visible, but which the form needs to know about
	in order to send the server a message that allows SQL to be generated that
	refers to those keys.