On Oct 31, 2013, at 7:10 AM, Erik Arvidsson <erik.arvids...@gmail.com> wrote:
> I see that Jason added a Loader.prototype.define to his reference > implementation. > https://people.mozilla.org/~jorendorff/js-loaders/Loader.html#section-177. > This is great. It is a much needed capability to allow bundling modules into > a single file. > > It allows you to do something like > > System.define(['url-a', urlB], ['export var a = "a";', moduleBodyForUrlB]); > > However, this is just another form of eval and will therefore not be > available in CSP. Can we come up with something that works in CSP > environments? How about? > > module 'url-a' { > export var a = "a"; > } As I said in the September meeting, eliminating the named declarative module form (a form which, you might recall, you went on record in the London meeting as saying was a mistake we'd regret... ;-P) is motivated by separation of browser concerns and ES concerns. The answer to making this work in CSP is to (a) make the loader API sufficiently generic that we can (b) solve it in the HTML layer. So the way we've done that is to say that loaders have a polymorphic notion of what "module source" is -- it doesn't have to be a string. In the browser API level, the AppWorker (aka ServiceWorker aka NavigationController) will be introducing ways to load cross-domain opaque payloads that can be absorbed by some sinks in the platform that are allowed to absorb them (e.g. <img> and <script> tags). The browser system loader will then be specified to allow .define to take such cross-domain payloads. There's no need for ad hoc language forms for peculiarities of the web platform, when they can much more cleanly be designed with web platform API's. Dave _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
