ServerJS/Modules/SecurableModules: Difference between revisions
Jump to navigation
Jump to search
m (→Security) |
(Trimmed the securable modules proposal to its essential elements and organized the remaining content into sub-pages.) |
||
| Line 1: | Line 1: | ||
This specification addresses how modules should be written in order to be interoperable among a class of module systems that can be both client and server side, secure or insecure, implemented today or supported by future systems with syntax extensions. These modules are offered privacy of their top scope, facility for importing singleton objects from other modules, and exporting their own API. | This specification addresses how modules should be written in order to be interoperable among a class of module systems that can be both client and server side, secure or insecure, implemented today or supported by future systems with syntax extensions. These modules are offered privacy of their top scope, facility for importing singleton objects from other modules, and exporting their own API. | ||
=== Module | == Contract == | ||
=== Module Context === | |||
# A module receives a "require" function. | # A module receives a "require" function. | ||
| Line 9: | Line 11: | ||
## If the requested module cannot be returned, "require" must throw an error. | ## If the requested module cannot be returned, "require" must throw an error. | ||
# A module receives an "exports" object that it may add its exported API to as it executes. | # A module receives an "exports" object that it may add its exported API to as it executes. | ||
# | # modules must use the "exports" object as the only means of exporting. | ||
=== Module Identifiers === | === Module Identifiers === | ||
| Line 19: | Line 21: | ||
# Absolute identifiers are resolved off the conceptual name space root. A loader may check multiple roots in a consistent order, like a PATH. | # Absolute identifiers are resolved off the conceptual name space root. A loader may check multiple roots in a consistent order, like a PATH. | ||
# Relative identifiers are resolved relative to the file in which "require" is called. | # Relative identifiers are resolved relative to the file in which "require" is called. | ||
=== Unspecified === | === Unspecified === | ||
| Line 42: | Line 29: | ||
# Whether a PATH is supported by the module loader for resolving module identifiers. | # Whether a PATH is supported by the module loader for resolving module identifiers. | ||
== Sample Code == | == Sample Code == | ||
math.js: | |||
exports.add = function() { | exports.add = function() { | ||
var sum = arguments[0]; | var sum = arguments[0]; | ||
| Line 68: | Line 41: | ||
}; | }; | ||
increment.js: | |||
var add = require('math').add; | var add = require('math').add; | ||
exports.increment = function(val) { | exports.increment = function(val) { | ||
| Line 76: | Line 47: | ||
}; | }; | ||
program.js: | |||
var inc = require('increment').increment; | var inc = require('increment').increment; | ||
var a = 1; | var a = 1; | ||
inc(a); // 2 | inc(a); // 2 | ||
== Notes == | |||
* [[ServerJS/Modules/Secure|Secure Modules]] | |||
* [[ServerJS/Modules/CompiledModules|Notes on compiling modules for browsers]] | |||
* [[ServerJS/Modules/ScriptModules|On writing modules that also work as <script>s]] | |||
== Amendment Proposals == | |||
# [[ServerJS/Modules/Environment|Module Environment]] | |||
== Implementations == | |||
* ondras is presently implementing this proposal for v8cgi http://code.google.com/p/v8cgi/ | |||
* tlrobinson is presently implementing this proposal for Jack http://github.com/tlrobinson/jack/tree/functional | |||
* kriszyp has implemented this proposal in Persevere http://www.persvr.org/ | |||
* pmuellr posted a sample loader http://wiki.github.com/pmuellr/modjewel | |||
* kriskowal: prototype for a client-side module loader that supports modules that conform to this specification using PATH relative URL's or module relative URL's without making security guarantees is partially complete in the [[http://code.google.com/p/chironjs/source/browse/branch/safe/src/modules.js "safe" branch of modules.js]]. | |||
* wes garland at pagemail is working on a spidermonkey implementation | |||
Revision as of 21:25, 1 March 2009
This specification addresses how modules should be written in order to be interoperable among a class of module systems that can be both client and server side, secure or insecure, implemented today or supported by future systems with syntax extensions. These modules are offered privacy of their top scope, facility for importing singleton objects from other modules, and exporting their own API.
Contract
Module Context
- A module receives a "require" function.
- The "require" function accepts a module identifier.
- "require" returns an object containing the exported API of the foreign module.
- If there is a dependency cycle, the foreign module may not have finished executing at the time it is required by one of its transitive dependencies; in this case, the object returned by "require" must contain at least the exports that the foreign module has prepared before the call to require that led to the current module's execution.
- If the requested module cannot be returned, "require" must throw an error.
- A module receives an "exports" object that it may add its exported API to as it executes.
- modules must use the "exports" object as the only means of exporting.
Module Identifiers
- A module identifier is a String of "terms" delimited by forward slashes.
- A term must be a camelCase identifier, ".", or "..".
- The extension of the file corresponding to a module identifier must be inferred by loaders.
- Module identifiers may be "relative" or "absolute". A module identifier is "relative" if the first term is "." or "..".
- Absolute identifiers are resolved off the conceptual name space root. A loader may check multiple roots in a consistent order, like a PATH.
- Relative identifiers are resolved relative to the file in which "require" is called.
Unspecified
This specification leaves the following important points of interoperability unspecified:
- Whether relative module identifiers are supported.
- Whether a PATH is supported by the module loader for resolving module identifiers.
Sample Code
math.js:
exports.add = function() {
var sum = arguments[0];
for (var i=1; i<arguments.length; i++) {
sum += arguments[i];
}
return sum;
};
increment.js:
var add = require('math').add;
exports.increment = function(val) {
return add(val, 1);
};
program.js:
var inc = require('increment').increment;
var a = 1;
inc(a); // 2
Notes
- Secure Modules
- Notes on compiling modules for browsers
- On writing modules that also work as <script>s
Amendment Proposals
Implementations
- ondras is presently implementing this proposal for v8cgi http://code.google.com/p/v8cgi/
- tlrobinson is presently implementing this proposal for Jack http://github.com/tlrobinson/jack/tree/functional
- kriszyp has implemented this proposal in Persevere http://www.persvr.org/
- pmuellr posted a sample loader http://wiki.github.com/pmuellr/modjewel
- kriskowal: prototype for a client-side module loader that supports modules that conform to this specification using PATH relative URL's or module relative URL's without making security guarantees is partially complete in the ["safe" branch of modules.js].
- wes garland at pagemail is working on a spidermonkey implementation