This can cause the wrong image to show temporarily, until replaced by the
right one (which I consider a bug; I think the cache needs to be less
aggressive).
That approach is clearly not workable for scripts... ;)
No, clearly not. I think we're finally in agreement on something. :)
I think we need to refocus the thread. Boris, you've brought up issues of
essentially:
1. Will keeping scripts around in memory that never get "used" lead to
run-away memory usage?
2. Does the caching behavior of IE do incorrect things (that Mozilla would
want to avoid)?
For #1, I think we've established this is probably true (for those rare
corner cases). Perhaps a more sophisticated in-memory content-uniqueness
cache could be constructed, but it may be more work than it's worth. To push
the ball forward, in a rough (non-binding) estimate, do you think that
Mozilla could be persuaded to agree to either of the two proposals, granted
the potential corner case negative performance, *without* such a
sophisticated in-memory cache to address some of those concerns? If not,
would the feasibility of such a system make implementing this proposal
unlikely? Or would it just be a pre-requisite that made the implementation
of "preloading" somewhat more complicated than it appears on the surface?
For #2 (and several other related questions we've been exploring)...
granted, it clearly seems that IE's implementation is not perfect (but is at
least getting better as of IE9). But as with the above assertion/question
about #1... if the correct thing is just to always follow HTTP semantics,
and assume you have to request every URL until you get caching headers
saying otherwise... isn't that still feasible within the constraints of
either of the two main proposals? Granted that it would be diverging from
IE's bugs in this area, but would it be workable to do so? If not, can you
clearly articulate why you think the proposals could not fit with existing
precedent on HTTP caching semantics?
Also, I want to go back to a question I asked earlier in this thread and I
don't think I quite got a full answer to:
With respect to the HTTP caching semantics (or other related performance
concerns), *other than the potential waste of unused scripts*, what
additional concerns does "preloading" imply that the quite standard current
practice of dynamically adding script elements to the DOM wouldn't imply?
I'm trying to figure out why "preloading" presents additional
challenges/risks that the current dynamic loading mechanisms don't.
--Kyle
