On 27/09/16 11:58, Gijs Kruitbosch wrote: > On 27/09/2016 10:28, David Teller wrote: >> How hard would it be to consider all chrome code (of a JSRuntime) as a >> single webpage? That's pretty much a requirement for any module loader >> we would use for our chrome code. > > I don't see how you would do this, because the globals *would* be > different for different windows (ie 2 copies of browser.xul windows), > and for XPCOM components. Even if our module loader had magic that let > this all happen without duplicating the modules themselves, it feels > like all kinds of static analysis and tools that we'd be doing this for > would break (because modules could never assume that |window| was a > thing in their global, or that it was always the same, but the tools > would assume that they could).
I don't follow. Fwiw, I'm thinking of Facebook's Flow, which is designed for use with Node.js (so, no `window`) and modules. >> 3) The issue of loading the source code >> >> All module systems need to load their source before proceeding. If I >> understand correctly, ES6 modules rely upon the same network stack as >> the rest of Gecko to load the source code, while jsm rely only upon the >> much more limited nsIJar* and nsILocalFile. > > You've not really given enough detail here to explain why this is a > problem. You can pass chrome and jar: URIs to an XHR (obviously you get > security exceptions if you try this from the web...), and to > NetUtil.newChannel, etc. etc. - it's not clear to me why it'd be a > problem to use those to load the source code. I'm talking about ES6 modules, which (if I read their code correctly) use a built-in loading mechanism, already implemented in Gecko. Are you talking of the same thing? Of course, we could decide to write code using ES6 modules and compile it away at build time. Is this what you had in mind? >> Barring any mistake, some of our network stack is written in JS. @zb, do >> you see any way to untangle this? > > This would only be a problem if you needed the JS-y bits of the network > stack to load those JS modules or components, which I don't think is the > case - that would surely also cause problems if it was the case with > Cu.import. Maybe I'm misunderstanding what problem you're trying to > identify? Well, Cu.import doesn't have this problem because it doesn't rely on any JS code – the only I/O, in particular, is performed through nsIJarURL and nsILocalFile, both of which are implemented in C++. But yeah, I may be wrong. If Necko's C++ code can handle gracefully (and without failing) the fact that some of Necko's JS code is not loaded yet, this may not be a problem. I'm not familiar enough with that part of the code. Cheers, David _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
