- From: Adam van den Hoven <adam@littlefyr.com>
- Date: Mon, 7 Feb 2011 09:33:50 -0800
Hey guys, I was reading the blog today and something I read ( http://blog.whatwg.org/whatwg-extensibility) prompted me to signup to the list and get involved again. What follows is not exactly well thought out but I'm hoping that it will spark something. window.atob() and window.btoa() feel wrong, so does window.crypto.getRandomUint8Array(length), not because they're not useful but because there is no answer to 'what does converting binary data to a base 64 string have to do with window?' beyond 'nothing but where else would it go?'. In reality all these belong to javascript, but modifying JS to include them is not feasible. Also, what if I don't want to do crypto in my code, why should I have all that lying around (not that its a hardship but why pollute the global namespace)? I think that we would all be better served if we were to introduce something like CommonJS to the browser, or perhaps a modified version of the require() method. This would allow us to move the crytpo and the atob/btoa into specific modules which could be loaded using: <script> var my_crypto = window.require( 'html:crypto' ); //or however you wanted to identify the 'crypto library defined by html' var my_util = window.require( 'html:util' ); // my_util.atob(); var $ = window.require( ' https://ajax.googleapis.com/ajax/libs/jquery/2.0.0/jquery.min.js' ); </script> and so on. Further, in CommonJS, the library has to export an object in order to make it available. If we could define things in such a way that the browser compiled the library independent of the page that loads it, the browser could cache the *compiled* code and provide that to the browser page. It would also be necessary to either enforce that these cached libraries be immutable or that a copy of the compiled code be made available. I couldn't implement this so I'm not sure how feasible this is but I suspect that requiring immutability would be the easier to implement. This would have two interesting effects. 'widgets' loaded this way could easily be taken from different libraries, this jquery accordion that mootools tree view. No having access means that it would have to require it itself, and the normal scoping would keep that version internal to itself. Second, this could reduce security risks, if the widget requires a library using some authoritative URL (say from Google's CDN), then some blackhatter who injects JS onto a page by what ever means could not modify the meaning of, say, jQuery.ajax to do something else. They would have to compromise the the source code itself which is a significantly more difficult thing to do. That is the extent of my conscious thought on the subject. I'm sure someone has a better idea than I in this regard but I thought I'd throw it out there. Adam van den Hoven
Received on Monday, 7 February 2011 09:33:50 UTC