Some quick feedback before I heed Ian's advice and try to formalize
things a little more.
As a browser vendor (or at least someone working for one, specifically
on script-loading), I would definitely be interested in something like
this. However there are some hard problems to be solved:
I looked through the mailing list and I take it you're from Mozilla.
Correct me if I'm wrong. =)
1. How do we choose which libraries to pre-package?
I'd rather not be in charge of ruling which libraries are popular
enough or cool enough to warrant inclusion. It'd be very nice if the
"library cache" were populated dynamically as the user used the web.
Yes this point did come up. I believe that the cache can be grown
dynamically, but I don't think that the cache could be reliably used
without some indication or opt-in from the html (and thus the
developer or some automated process). Files can be compared with each
other very quickly, and SHA hashes even quicker, to determine that
indeed the same content is being sent from multiple URLs, thus
allowing potential for the cache to grow dynamically with frequently
encountered content. But, again, I think the problem is then on the
developer to opt-in to the service, otherwise the cache is just a
speculation.
2. How do we deal with identifying libraries.
As Aaron Boodman pointed out, SHA hashes means that you can't make
upgrades for security problems etc.
I still don't see this as an issue. As long as it is a SHA hash of
the content, then its the content that matters. If a developer is
using a script with a security problem then they should change their
script. At this point a browser could go the extra mile and "attempt"
to fix it for them by updating the script but thats another
"speculation". The idea of "canonical" names could run into problems
though.
3. Compat when the browser doesn't have a library cached.
A solution that includes using a different uri for browsers that do
support caching than browsers that don't is scary since there is a big
risk that the author will forget to update one but not the other.
Yes, I do see this as a problem. I gave a response to this before,
but I do still see this as being a potential headache point. Tools
can easily solve this but thats not a perfect solution. I haven't
come up with a good solution to this, but I do have some ideas.
I believe all these problems are solvable, but they do need to be
solved before considering inclusion in any spec. I'm also not
convinced this needs to be included in the HTML5 spec, but that might
depend on what the ultimate solution looks like.
I agree again. I concluded this feature makes the most sense for a
restricted environment, such as developing mobile web apps. Those
developers are already faced with some different conditions, and I
think iPhone web development even has some custom syntax. A feature
like this could make a much bigger impact in that kind of environment
where it could gain traction.
/ Jonas
Thanks for the feedback Jonas.
- Joe
