«

Richard Cornford wrote:
<snip>
> It is considerably easier to say "just make sure to use a different
> random number for each call" (assuming "call" is acceptable terminology
> here (which it probably isn't)) than to actually do it. Remember that
> you would have to be keeping track of which random numbers had been
> used, even between sessions, as it would not be too good if the browser
> decided to deliver content that it had downloaded in a previous session
> from its cache in response to a request in a later one.

Agreed. However, the odds that the same random number would be
generated within the lifespan of the cache is sufficiently miniscule to
preclude the need to keep track of the used numbers. (Especially
considering the example I used provided for up to 1 quadrillion
numbers.)

> That is why using the millisecond time in this context has been
> proposed, as each time will be unique (at least so long as no two times
> are requested within about 60 milliseconds, at most) and it is in the
> nature of time that is does not repeat itself. That is; what is wanted
> is a unique number rather than a random one, and each item in a sequence
> of increasing integer values is unique within that sequnce.

It cannot be guaranteed that each time will be unique. JavaScript uses
the system clock. Granted, the odds that a user will change the time
and a second request goes out with the same millisecond timestamp is
very small. Perhaps 1 in a trillion?

> >>That is a flaw in the approach -
> >>not a different method to accomplish the same goal.
> >
> > I guess I'll admit there was a flaw.
>
> Yes it is. At lest in part because the proposal that the OP should "make
> sure" that no two random numbers be the same is considerably more
> troublesome than an available alternative.

I agree that it would be. But, again, the odds are remote enough to
preclude the need to do so.

>
> > And that is that I didn't write
> > all the javascript for the original poster.
> > I guess I'm more of a teach-a-man-to-fish sort
> > of guy versus a give-a-man-a-fish guy.
>
> "Fishing" in an HTTP context would be better mastered with an
> understanding of HTTP, and specifically the way in which various HTTP
> headers can be configured to discourage client-side caching of various
> resources (and possibly the different ways in which POST and GET
> requests are handled with regard to caching). With the correct header
> configuration it is possible that the URL hack would be unnecessary,
> else you would see such "random numbers" on the end of every URL on
> every dynamic site.

We agree again! But as this is a JavaScript Usenet group, the
workaround(hack) suggested involved JavaScript. But just so you know
that I'm not being stubbornly argumentative, I'll agree that the
millisecond method is superior assuming no user clock adjustments. The
random number method would be superior for requests made within 50
milliseconds of each other.

Now that I think about it, both methods should be used simultaneously.
Append the random number after the millisecond timestamp and then you
have a workaround that avoids the simultaneous request problem and the
user clock adjustment problem. Genious!

JRS: In article <dim3m7$a4p$1$>, dated
Thu, 13 Oct 2005 17:57:42, seen in news:comp.lang.javascript,
Richard Cornford <> posted :
>
>That is why using the millisecond time in this context has been
>proposed, as each time will be unique (at least so long as no two times
>are requested within about 60 milliseconds, at most) and it is in the
>nature of time that is does not repeat itself.

For the present purpose, that, if correctly interpreted, will
do.

However, the current time has to be in a form not affected by
Summer Time (a civil hour in Autumn is repeated, in many
places); and, for travellers, by change in location : so UTC
should be used, and +new Date() will give that.

Also, any system in which a drifty clock is corrected by
reference to a time source is liable to have repeated times.

Real Greenwich Mean Time and Real UTC are monotonic, increasing
by close to / exactly one second per second; buy, when it really
matters, one should allow for a computer's estimate of time to
be non-monotonic.

--
© John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v4.00 MIME. ©
Web <URL:http://www.merlyn.demon.co.uk/> - w. FAQish topics, links, acronyms
PAS EXE etc : <URL:http://www.merlyn.demon.co.uk/programs/> - see 00index.htm
Dates - miscdate.htm moredate.htm js-dates.htm pas-time.htm critdate.htm etc.