> I would like to hear your opinions and ideas relevant to the fact that
> the "require" function (https://wiki.mozilla.org/ServerJS/Modules/
> SecurableModules) can be implemented in two ways: as a pure-JS
> function (we have already seen first successful implementations), or
> in a low-level code (C, C++).
It is up to the implementation to decide.
Implementing in C (or Java for Rhino) allows for direct manipulation
of the scope chain and can protect against missing "var".
by accident. And if a native module purposefully modifies global (or
anything else outside its scope), there is no way in hell ANY closure
trick will help you.
Wesley W. Garland
Director, Product Development
+1 613 542 2787 x 102
Clearly I'm missing something (yes, I looked at your link). Can you
explain in more detail?
This is mostly tangential to serverjs, but the thesis Ihab's and my
proposal to TC39 is that all ES really needs (deferring the issue of
syntactic sugar for modules) is a hermetic evaluator so that a
"require" function can create module instances in an air-tight room.
This room would have its own, frozen, tamper-free global object tree,
so module factory functions can be evaluated with this "global" in its
scope chain without risk of communicating malice through mutation of
their common scope. The same can be effectively achieved, as a
stopgap, on the server side by a validator that the client module
loader trusts. The reason we call our proposal to serverjs
"securable" instead of "secure" is that its our hope that "serverjs"
creates a population of modules that are written in a fashion that
would be compatible with a compliant loader implementation that uses
this secured, hermetic evaluator to achieve security on the client
side. It's something we'd encourage prototyping, but is summarily
off-topic for your endeavour.
It's also worth mentioning that a compliant module loader does not
actually need to add anything to the global scope. There's been
mention that "require" would be added to "global", which is not
strictly necessary. A module loader implementation can be constructed
entirely in the privacy of a closure and use its private "require"
sandbox object to execute the initial program module.
Excellent explanation. But, a word on the PATH: while a module loader
implementation may or may not use a list of paths to look for modules,
there should definitely be a module root path off which "require"
finds modules by default. I find that its far more common for a
library to import standard libraries off this "root module path" than
to instantiate neighbor modules relative to its own module path. I
recommend that "require" resolve module identifiers off the "root
module path" by default, and only resolve the path relative to its own
module identifier when the first term of the required module is "." or
"..". This is analogous to the new convention supported by Python 2.6
and 3 where modules are "absolute" by default and "relative" if they
begin with a ".". The problem Pythonists ran into here was that you
could not effectively import a standard library from any module that
contained a module by the same name as the standard library module in
the same directory as the importing module. For example:
/www/csv.py: import csv
/www/foo.py: import csv
In this example, /www/foo.py will get /www/csv.py, and /www/csv.py
will get itself. This is resolved in the new Python:
/www/csv.py: import csv
/www/foo.py: import .csv
Such that /www/foo.py receives /www/csv.py and /www/csv.py in turn
receives the standard library.