Re: Static? Dynamic?

 >From www-talk-request@w3.org Tue Jun 29 19:23:02 1999
 >Date: Tue, 29 Jun 1999 19:03:34 -0400 (EDT)
 >From: "Russell Steven Shawn O'Connor" <roconnor@undergrad.math.uwaterloo.ca>
 >To: www-talk@w3.org
 >Subject: Re: Static? Dynamic?
 >
 >On Tue, 29 Jun 1999, Dan Connolly wrote:
 >
 >> But it's perfectly reasonable to publish a resource that
 >> is "the current score of the NBA playoff game" that would
 >> change quite rapidly, provided you label it with the
 >> relevant metadata (expires, time-to-live, whatever).
 >> If I visited such a resource, then followed a link, then
 >> came back, I'd prefer to see the *old* score, plus
 >> a "dead fish" or whatever that tells me I'm looking at
 >> stale info.
 >
 >*whew* It's not clear to me what is the right thing to do in this
 >situation.  In the example you give, I think ideally there'd be an applet
 >(or something) that keeps you advised of the current score.  But in the
 >more general case I can see it sometimes being irritating to have what you
 >are trying to read suddenly change on you, and sometimes irritating to
 >have what you are reading being out of date.
 >
 >Your dead fish is one approach.  Another might be to get the most recent
 >copy, but still have an accessible cache of what the page was like when
 >you visited before.
 >

	[Stuff deleted]

I'd like to throw my 2 cents in to this discussion. BACK and FORWARD
should redisplay what you already saw. By default, URLs should not be
resubmitted to recreate a page, especially if the page was returned
as a result of a FORM submission.

If a Refresh-equivalent were done for a Form submission, you would have
to prompt the user to resubmit the form data, as is done now when
Refresh is pressed.

Beyond Forms, though, the display of a Web page is not necessarily
idempotent - it is not the same thing to retrieve it once as it is to
retrieve it many times. There are simple statistics and counters that would
become incorrect. Ads would be regenerated. You might repeat the 
shopping transaction that you just made. The act of retrieving
a Web page might cause some physical action to happen - zooming
a camera or shifting a production line forward - not something you
would want to repeat accidentally.

Some dynamic pages require enormous resources to generate or transmit -
long running queries or live images.

They need to be marked as volatile, so that they are not cached,
but if you just want to see the page again, you shouldn't have to
perform the operations, some of which you might be paying for
by the hit. (I like the dead fish idea, although some companies,
like Starkist, might not want such a symbol appearing with their pages.)

On the other hand, a Web page author should be able to specify
that their pages are to be refreshed on Back and Forward. I haven't
looked at the standard recently, but there's a Meta refresh tag
I believe, and instead of just being able to give a time, it might be
good to give an action that would refresh the page, i.e., Refresh: BACK.

Since this is part of HTML, not HTTP, you couldn't do this with
individual image URLs, or other non-HTML content, but the overall page
could be marked as such.

I don't know if I've gotten all the nuances right, but I'm sure
you get the general idea.

	Scott Orshan
	BEA Systems
	+1-908-580-3185

Received on Tuesday, 29 June 1999 20:49:10 UTC