How to refresh cached image ONCE

[C. (http://symcbean.blogspot.com/)]

Hi all,

I have an application which generates image graphs. These cache nicely
at the client, however if the user submits more data, I'd like to
force a reload of the image from the server.

I had a google, but all I could find were suggestions to use a varying
query in the URL. This is not a solution to my problem because if I
change the page to do that then ALL the graphs will be reloaded every
time.

I tried

document.getEle mentById("imgs_ id_tag").src.re load():

and

document.getEle mentById("imgs_ id_tag").reload ():

But just got errors.

(If I open JUST the image URL in a browser, I get the cached version,
if I then click on refresh, it goes back to the server to get a new
copy - which is what I want).

Any suggestions?

TIA

C.

[Thomas 'PointedEars' Lahn]

Jorge wrote:

Thomas 'PointedEars' Lahn wrote:

>Jorge wrote:

>>Thomas 'PointedEars' Lahn wrote:
Cache-controlling HTTP headers are the correct approach instead.
Right. Cache-control headers ought to be explicitly setup just for
these images. Agreed.
But the OP was looking for a client-side solution, and that's not.

| I have an application which generates image graphs. These cache nicely
| at the client, however if the user submits more data, I'd like to
| force a reload of the image from the server.

Not a single word about a client-side only solution.

Does this look like server-side scripting to you : (?)

"I tried document.getEle mentById("imgs_ id_tag").src.re load(): "
"and document.getEle mentById("imgs_ id_tag").reload (): "

I have noticed that before. So the OP had a problem with their client-side
script for refreshing the image. That does not mean in any way that the
solution must be client-side only.

>(...)
ISTM anything else would require a server-push communication
like Comet.

Duh !

Tough luck.
PointedEars
--
Use any version of Microsoft Frontpage to create your site.
(This won't prevent people from viewing your source, but no one
will want to steal it.)
-- from <http://www.vortex-webdesign.com/help/hidesource.htm>

[C. (http://symcbean.blogspot.com/)]

On Jul 19, 10:44*am, Thomas 'PointedEars' Lahn <PointedE...@we b.de>
wrote:

Jorge wrote:

Thomas 'PointedEars' Lahn wrote:

Jorge wrote:
Thomas 'PointedEars' Lahn wrote:
Cache-controlling HTTP headers are the correct approach instead.
Right. Cache-control headers ought to be explicitly setup just for
these images. Agreed.
But the OP was looking for a client-side solution, and that's not.
| I have an application which generates image graphs. These cache nicely
| at the client, however if the user submits more data, I'd like to
| force a reload of the image from the server.

Not a single word about a client-side only solution.

Does this look like server-side scripting to you : (?)

"I tried document.getEle mentById("imgs_ id_tag").src.re load(): "
"and document.getEle mentById("imgs_ id_tag").reload (): "

I have noticed that before. *So the OP had a problem with their client-side
script for refreshing the image. *That does not mean in any way that the
solution must be client-side only.

(...)
ISTM anything else would require a server-push communication
like Comet.

Thanks guys - unfortunately it doesn't really solve my proble - I
guess I didn't make it clear enough.

I really want the image to be cached client side unless the data used
to create the image (server-side) changes. I can't really get every
client who has a cached copy to update their cache. Using a dirrent
URI each time by appending a random value just makes the browser think
it is a different image - undermining the caching which is working
fine in most cases:

had a google, but all I could find were suggestions to use a varying
query in the URL. This is not a solution to my problem because if I
change the page to do that then ALL the graphs will be reloaded every
time.

However, I think it may be possible to do for the client who just
uploaded the data - since, if they click the 'Refresh' button in the
browser it carries out an unconditional reload of the content. I'm
wanting to emulate this from Javascript.

C.

[Thomas 'PointedEars' Lahn]

C. (http://symcbean.blogspot.com/) wrote:

I really want the image to be cached client side unless the data used to
create the image (server-side) changes.

That is what cache-controlling headers are for: <http://mnot.net/cache-docs>

I can't really get every client who has a cached copy to update their
cache.

Why not?

Using a dirrent URI each time by appending a random value just makes the
browser think it is a different image - undermining the caching which is
working fine in most cases:

This is updating the cache in a sense, only that it is filled with mostly
useless information then. You hardly want that.

>had a google, but all I could find were suggestions to use a varying
query in the URL. This is not a solution to my problem because if I
change the page to do that then ALL the graphs will be reloaded every
time.

However, I think it may be possible to do for the client who just
uploaded the data - since, if they click the 'Refresh' button in the
browser it carries out an unconditional reload of the content. I'm
wanting to emulate this from Javascript.

Have you already tried executing

img.src = img.src;

or

var oldsrc = img.src;
img.src = "";
img.src = oldsrc;

in a repetitive setTimeout() while using cache-controlling headers?
PointedEars
--
Use any version of Microsoft Frontpage to create your site.
(This won't prevent people from viewing your source, but no one
will want to steal it.)
-- from <http://www.vortex-webdesign.com/help/hidesource.htm>

[Dr J R Stockton]

In comp.lang.javas cript message <29d0c3f4-9a1e-4301-81b6-6dc5da5436b9@y3
8g2000hsy.googl egroups.com>, Fri, 18 Jul 2008 12:16:30, Jorge
<jo***@jorgecha morro.composted :

>On Jul 18, 7:50*pm, Thomas 'PointedEars' Lahn <PointedE...@we b.de>
wrote:

>>
Also, a random value alone is not sufficient;

Yes it is, Thomas, remember that the OP said that he wanted to reload
the image *once*.

>it must be a value that is
unique over a longer period of time, like the timestamp that you suggested.

The probability of obtaining the same ramdom number twice in a row is
about 1/(2^(8*8)) === 1/184467440737095 51615
And keeps being almost null even after tens or hundreds of
extractions.

No, for two reasons. The generator is not necessarily 64-bit or even
53-bit. In my js-randm.htm, "MSIE 6 and 7 show 53 bits; Firefox 2.0.0.3
shows 52 bits; Opera 9.21 shows 31 bits; Safari 3.1 shows 31 bits."
And, as the generator is only pseudo-random, it should not repeat until
after a full cycle.

What does that page report (for various browsers?) on your Mac?

--
(c) John Stockton, nr London, UK. ?@merlyn.demon. co.uk Turnpike v6.05.
Web <URL:http://www.merlyn.demo n.co.uk/- w. FAQish topics, links, acronyms
PAS EXE etc : <URL:http://www.merlyn.demo n.co.uk/programs/- see 00index.htm
Dates - miscdate.htm moredate.htm js-dates.htm pas-time.htm critdate.htm etc.

[Dr J R Stockton]

In comp.lang.javas cript message <48************ **@PointedEars. de>, Fri,
18 Jul 2008 19:50:07, Thomas 'PointedEars' Lahn <Po*********@we b.de>
posted:

>

>elem.src = oldSrc + '?rnd=' + new Date().getTime( );

This basically says "set the src to the exact same thing, with an
aditional 'random' parameter (current date/time as a number)"

>Also, a random value alone is not sufficient; it must be a value that is
unique over a longer period of time, like the timestamp that you suggested.

In most browser instances, Math.random can be shown to give 53 bits of
pseudo-randomness, although the initial value's randomness depends on
the quality of the initialisation.

Machines connected to the Internet generally resynchronise from time to
time with an Internet or server clock. Nearly 50% of computers will
need to be set back in time, and in the case of those which cannot be
slowed or stopped but must jump back it will be necessary to repeat a
certain amount of internal-clock time. So new Date().getTime( ) may
give the same value after an interval as it did before. That will not
often happen, but ISTM likely to happen more often than the repeat of a
good RNG, let alone of a a PRNG which will cycle through all possible
values before repeating.
Recommending adjusting HTTP headers as opposed to adjusting the 'URL' is
not helpful to those whose servers do not allow header control.
Professional servers should allow it; those available to many of the
amateurs who read this group may very well not do so.

>Please do a little research before you post something here.

Please think before you post something here.

--
(c) John Stockton, nr London, UK. ?@merlyn.demon. co.uk Turnpike v6.05.
Web <URL:http://www.merlyn.demo n.co.uk/- w. FAQish topics, links, acronyms
PAS EXE etc : <URL:http://www.merlyn.demo n.co.uk/programs/- see 00index.htm
Dates - miscdate.htm moredate.htm js-dates.htm pas-time.htm critdate.htm etc.

[Jorge]

On Jul 19, 6:07*pm, Dr J R Stockton <[e-mail] mon.co.ukwrote:

>
No, for two reasons. *The generator is not necessarily 64-bit or even
53-bit. *In my js-randm.htm, "MSIE 6 and 7 show 53 bits; Firefox 2.0.0.3
shows 52 bits; Opera 9.21 shows 31 bits; Safari 3.1 shows 31 bits."
And, as the generator is only pseudo-random, it should not repeat until
after a full cycle.

Yes you're right. In fact Safari's PRNG always repeats at n=
2,147,483,645 (-2^31) (don't tell Thomas :-)

What does that page report (for various browsers?) on your Mac?

"Apparent resolution is at least 30 bits."

Thanks,
--Jorge.

[Jorge]

On Jul 19, 6:07*pm, Dr J R Stockton <[e-mail] mon.co.ukwrote:

>
What does that page report (for various browsers?) on your Mac?

On a Mac :

Webkit r34974: "Apparent resolution is at least 30 bits."
Safari 3.1.2: "Apparent resolution is at least 30 bits."

Opera 9.51: "Apparent resolution is at least 31 bits."

Navigator 9.0.0.3: "Apparent resolution is at least 52 bits."
Camino 1.6.1: "Apparent resolution is at least 52 bits."
FF 2.0.0.16: "Apparent resolution is at least 52 bits."
FF 3.1: "Apparent resolution is at least 52 bits."

IE 5.2: "Apparent resolution is at least 53 bits."

iCab 3.0.5 : "Apparent resolution is at least 58 bits."

--Jorge

[Jorge]

On Jul 19, 6:07 pm, Dr J R Stockton <[e-mail] mon.co.ukwrote:

What does that page report (for various browsers?) on your Mac?

On a Mac :
Webkit r34974: "Apparent resolution is at least 30 bits."
Safari 3.1.2: "Apparent resolution is at least 30 bits."

Opera 9.51: "Apparent resolution is at least 31 bits."

Navigator 9.0.0.3: "Apparent resolution is at least 52 bits."
Camino 1.6.1: "Apparent resolution is at least 52 bits."
FF 2.0.0.16: "Apparent resolution is at least 52 bits."
FF 3.1: "Apparent resolution is at least 52 bits."

IE 5.2.3: "Apparent resolution is at least 53 bits."

iCab 3.0.5: "Apparent resolution is at least 58 bits."

--Jorge

[Dr J R Stockton]

In comp.lang.javas cript message <c9681dae-4958-410e-993b-86bb9eeddd00@l4
2g2000hsc.googl egroups.com>, Sat, 19 Jul 2008 12:37:21, Jorge
<jo***@jorgecha morro.composted :

>On Jul 19, 6:07 pm, Dr J R Stockton <[e-mail] mon.co.ukwrote:

>What does that page report (for various browsers?) on your Mac?

...

>iCab 3.0.5: "Apparent resolution is at least 58 bits."

That one was initially rather unexpected, since Math.random() is
supposed to return an evenly-distributed IEEE Double with an effective
53-bit mantissa, and the best previously seen or reported was 53 bits.

ISO/IEC 16262 only requires that the result of Math.random() be evenly
distributed, not that the resolution be independent of the value.

It appears that other browsers in effect mask the output of the
(64-bit?) PRNG to 53 bits before converting to Double, while iCab does
that only within the conversion itself.

It seems undesirable for there to be unnecessary numerical differences
between browsers; if anyone has contact with those writing future
specifications, then I suggest that they ask for the future spec to have
this uncertainty removed. While iCab in a sense has better randomness,
ISTM that uniformity would be preferable.

The function you observed, Resol, is now Resol1; new Resol3 is similar
but uses only randoms >= 0.5.

--
(c) John Stockton, nr London, UK. ?@merlyn.demon. co.uk Turnpike v6.05 MIME.
Web <URL:http://www.merlyn.demo n.co.uk/- FAQish topics, acronyms, & links.
Proper <= 4-line sig. separator as above, a line exactly "-- " (SonOfRFC1036)
Do not Mail News to me. Before a reply, quote with ">" or "" (SonOfRFC1036)

[Jorge]

On Jul 20, 7:32*pm, Dr J R Stockton <[e-mail] mon.co.ukwrote:

>
The function you observed, Resol, is now Resol1; new Resol3 is similar
but uses only randoms >= 0.5.

John,

I have retouched your resol1() a little bit. Now it receives a
parameter p, and it doesn't return until the higher resolution found
remains unchanged for p iterations of the loop. It gives higher
readings now.

I have also written a bits() function that finds what is the smaller
power of 2 for which it's true that (2^x) === ((2^x)+1). I think that
that must be the size of the mantissa, or not ?

See it here : http://tinyurl.com/68d9br

These are the numbers I get :

IE 5.2.3 : 53, 53.
FF2, FF3 : 52, 53.
Safari : 30, 53.
Opera 9.51 : 31, 53.
iCab 3.0.5 : 63, 53.

But I don't understand why those numbers are different. And, if the
mantissa is 53 bits (iCab), how can, why does resol1() give 63 ?

Here's the code :

<script>
window.onload= function () {
var resol1= (function (p) {
var x, t, max= 0, i= p;
while (i) {
t= 0, x= Math.random();
while ((x*= 2)%1 0) { // shift left until empty
t++;
}
if (t max) {
max= t, i= p;
} else {
i--;
}
}
return max;
})(1e4);

var bits= (function () {
var x, i= 0;
do {
x= Math.pow(2,++i) ;
} while (x !== (x+1))
return i;
})();

var test= Math.pow(2,bits );
var text= "resol1() : Maximum resolution is at least "+resol1+"
bits.<br>";
text+= "bits() : "+bits+" -In this browser "+(test+1)+ " ===
1+"+test;

(document.body. appendChild(
document.create Element(
'h2'))).innerHT ML= text;

};
</script>

Thanks,
--Jorge.