Bart Van der Donck wrote:
Richard Cornford wrote:
>Bart Van der Donck wrote:
>>I am not aware of an HTTP header that affects image
preloading techniques from javascript, and I'ld be
surprised if this would exist.
You don't think the HTTP pragam, expires and cache-control
headers might come into this then? Do you actually appreciate
what HTTP-EQUIV is supposed to mean in a META element (what
aspect of HTTP the EQUIV is 'equivalent' to)?
The actual HTTP-headers are more important, yes. HTTP-EQUIV
might help here or there
"Might help here or there"? Are we working with technology or offering
prayers and sacrifices for a good harvest?
and it certanly doesn't harm to repeat an HTTP header in
HTTP-EQUIV.
Web development is plagued with things that 'do no harm'. It should be
important to distinguish between the things that do some good and the things
that are no more that mystical incantations, and possibly the things that
were once of some value but have not become redundant (and are continued
because they are doing no harm so nothing exists to break the habit).
An example of the latter is wrapping SCRIPT element contents in <!--
.... -->, which, for a short period, was a good idea, but is now totally
redundant but persist because it is (mostly) harmless. Unfortunately the way
in which it persist is in people who operate on the basis of mystical
incantation propose to others that this incantation is necessary when
'conjuring' a SCRIPT element.
It's right that 'equivalent' is too much honour for these
tags.
Absolutly.
>>Let me tell you why I counseled the use of those META headers.
About two/three years ago I used such image preloading
techniques in a geo-application. It worked well, but it
appeared that in Microsoft Internet Explorer (I think 5.x
at that time) the image buffer could be flushed sometimes
What is the "image buffer"? Are you talking about the browser's
client-side cache, or images in a running browser's memory?
I'm not sure about the exact distinction between those two.
Just the images that were preloaded, stored in buffer and
available for (immediate) referencing on the page.
The process that is labelled "preloading" is more a matter of pre-requesting
an image, with the intention of moving it into the browser's local disc
cache. The cachablitly of that image has a considerable impact on the
usefulness of doing that.
>>so that the browser needed to fetch the image(s)
back from server. It didn't happen too often though, but
it did, and I had a feeling at that time that it had
something to do with the code complexity of that project
as well.
The HTTP headers sent with the images are much more likely to
influence the frequency with which the browser sees the need to
query the server for updates. From what I am reading I suspect that
never knew what those headers were (and possible never knew they
existed).
Then tell me, does javascript read out the image's HTTP headers
in order to decide when it should flush the (preloaded) image ?
I would be surprised if that were true.
Javascript has no role in the decision as to whether an image is cached,
used from the cache or re-loaded from the server. The browser makes that
decision, but it certainly is considerably influenced in that decision which
headers are sent with an image (or with the image last time it as requested,
or instead of the image (in the case of a response to a 'If-Modified-Since"
request where the server sees no update)).
Working with such stuff seems very browser dependent
and very dangerous to rely on.
However something is "worked with", a starting position of understanding
what HTTP provided for use in relation to caching would be of considerably
value in determining how any browser may act outside of the specified
behaviour (or fill in any 'gaps').
But yes, there is technically no problem at
server side.
>>Since I added the META-tags, the images were cached
correctly and were always shown immediately.
So you observed a coincidence, but never established a
cause and effect relationship.
That is true up to a certain point.
You either establish a cause and effect relationship or you don't. There is
no "up to a certain point" in that.
I tested my solution thoroughly and I concluded that it
worked okay (which it still does until today, btw).
If your 'solution' was a coincidence (and the theory says it will have been
as there is no reason to expect the cachability of an HTML page (assuming
that the HTTP-EQUIVE META elements on the page will effect its cachablity
(though they can do no more)) would influence the caching behaviour of image
resources that are referenced from the page) but was in itself harmless then
its repeated use ("tested ... thoroughly") would demonstrate nothing.
I'm not sure how things work from your Sedes Sapientiae,
but I have less-than-perfect expierences as well.
Is that another bogeyman named "less-than-perfect expierences"?
>>For me that was reason enough to start using them ever
since for this kind of image preloading.
That is "programming by coincidence", and so not something
you should be recommending to others. Most of the META tag
cargo-cults have started that way (all praise the mighty
HTTP-EQUIV; "META, META, Meta, meta, ...".)
It's not programming by coincidence,
Demonstrate the cause and effect relationships and it may not be. But it
looks to me as if you never even considered many of the factors that would
be expected to influence the situation.
but a practical solution to a concrete problem.
You do not even know for certain that it influenced the situation you
described, let alone that it 'solved' anything. The most you are able to say
it that it was not harmful.
Richard.