On 2/22/11 7:19 PM, Kyle Simpson wrote:
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?
First of all, which two proposals are we talking about here?
If not, would the feasibility of such a system make implementing this proposal
unlikely?
It would certainly make implementing it soon unlikely, if such a beastie
is needed.
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
That's an excellent question. Is that the correct thing?
For some things (e.g. stylesheets and images) browsers don't do this in
many cases (and the HTML5 spec in fact requires such behavior). What
should the script behavior be?
isn't that still feasible within the constraints of either of the two main
proposals?
Sure.
My point was that coalescing loads in ways that HTTP doesn't actually
allow is one way to handle the memory growth issue without exploding
cache complexity.
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.
Because if you're trying to implement some sort of "sophisticated
in-memory content-uniqueness cache" is also expected to implement HTTP
semantics, that makes implementing it a good bit more difficult.
-Boris
