[whatwg] Browser Bundled Javascript Repository

[Joseph Pecoraro]

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