System API Proposal
Kris Kowal
mean for you. Please leave a mark.
https://wiki.mozilla.org/ServerJS/System
Kris Kowal
ihab...@gmail.com
Tom Robinson
match other platforms, and everything else is abbreviated.
Additionally, I think "arguments" is a teeny bit confusing due to
"arguments" special meaning within functions in JavaScript.
-Tom
Kris Kowal
>
> +1 except I would opt for sys.env and sys.args or sys.argv to better
> match other platforms, and everything else is abbreviated.
>
> Additionally, I think "arguments" is a teeny bit confusing due to
> "arguments" special meaning within functions in JavaScript.
>
> -Tom
>
Let's see hands for:
A arguments
B args (java)
C argv (python, ruby, perl)
1 env (jack, ruby, php, perl, java)
2 environ (python, posix)
3 environment
Tom Robinson's hands already counted: B or C and 1
Kris Kowal: indifferent
Ondrej Zara
I've posted a proposal for the inclusion of "sys" and what it would
mean for you. Please leave a mark.
https://wiki.mozilla.org/ServerJS/System
Hi,
thanks for this proposal.
As the "sys" object would be a built-in, I vote for naming it "System" - to be consistent with other builtins names (Array, Object, ...).
My other minor votes:
System.arguments
System.env
:)
Ondrej
Kris Kowal
Kris Kowal
> As the "sys" object would be a built-in, I vote for naming it "System" - to
> be consistent with other builtins names (Array, Object, ...).
Let's see hands for:
A arguments
B args (java)
C argv (python, ruby, perl)
1 env (jack, ruby, php, perl, java)
2 environ (python, posix)
3 environment
I sys
II System
So far:
Tom Robinson: B or C, 1
Kris Kowal: I, C, 1
Ondrej Zara: II, A, 1
Wes Garland
Ondrej, Array and Object are spelled with capital letters not because they are built-ins, but because they are classes. And Math is just wrong. ;)
I recently spent half a day changing all my module names to match lower-leading-camel-case. Don't go changing it back on me!
Wes
Wesley W. Garland
Director, Product Development
PageMail, Inc.
+1 613 542 2787 x 102
Ondrej Zara
Ondrej, Array and Object are spelled with capital letters not because they are built-ins, but because they are classes. And Math is just wrong. ;)
Well, yes. On the other hand, everything that is present in a "clean" js environment begins with an uppercase letter. For me, lowercase means user-created - that is why I don't like the [global].sys name.
Also, we might take "system" into consideration, as shorter variable names tend more to create potential collisions with user variables.
O.
Kevin Dangoor
Kevin Dangoor
work: http://labs.mozilla.com/
email: k...@blazingthings.com
blog: http://www.BlueSkyOnMars.com
Hannes Wallnoefer
> On Tue, Apr 7, 2009 at 11:14 PM, Ondrej Zara <ondre...@gmail.com> wrote:
>> As the "sys" object would be a built-in, I vote for naming it "System" - to
>> be consistent with other builtins names (Array, Object, ...).
>
> Let's see hands for:
>
> A arguments
> B args (java)
> C argv (python, ruby, perl)
>
> 1 env (jack, ruby, php, perl, java)
> 2 environ (python, posix)
> 3 environment
>
> I sys
> II System
hannes
mob
Chris Zumbrunn
On Apr 8, 2009, at 8:05 AM, Kris Kowal wrote:
> B args (java)
> C argv (python, ruby, perl)
>
> 1 env (jack, ruby, php, perl, java)
> 2 environ (python, posix)
> 3 environment
B args
1 env
On Apr 8, 2009, at 10:14 AM, Kris Kowal wrote:
> I sys
> II System
III system
(unless System would be a constructor, which isn't the intention here)
Chris
Robert Thurnher
> B args
> 1 env
+1: B, 1
>> I sys
>> II System
>
> III system
+1: III
-- Robert T.
Kris Kowal
A arguments (Ondrej Zara, Wes Garland)
B args (Tom Robinson, Kevin Dangoor, Hannes Wallnoefer,
Michael O'Brien, Chris Zumbrunn, Robert Thurnher)
C argv (Tom Robinson, Kris Kowal)
1 env (Ondrej Zara, Tom Robinson, Kris Kowal, Kevin Dangoor,
Hannes Wallnoefer, Michael O'Brien, Chris Zumbrunn,
Robert Thurnher)
2 environ
3 environment (Wes Garland)
I sys (Tom Robinson, Kris Kowal)
II System (Ondrej Zara)
III system (Ondrej Zara, Kevin Dangoor,
Hannes Wallnoefer, Chris Zumbrunn, Robert Thurnher)
Z as a free variable (Kris Kowal, Ihab Awad)
Y as a module (Hannes Wallnoefer)
Daniel Friesen
args makes no sense, it's not used anywhere in JS itself and mixes up a
builtin variable name with the habit people have of assigning something
like:
var args = Array.slice(arguments);
Inside of function calls to have an arguments array they can mutate.
Using `arguments` is basically like considering "My program is like a
big function. When it's executed I can have a list of arguments passed
to it from where it was called"
~Daniel Friesen (Dantman, Nadir-Seen-Fire)
Kris Kowal
shown on the mailing list up to this point. We've definitely seen
enough hands so far to paint the bike shed with the colors "args",
"env", and "system", but the issue remains whether more people would
prefer to use module injection instead of a free variable (Hannes
Walnoeffer holds the outstanding opinion at this point, but I suspect
that there are more supporters of a "system" module instead of a
"system" free variable and there just aren't enough opinions noted
either way to make a decision yet).
Kris Kowal
Robert Thurnher
+1 for a "system" module (as opposed to free variable).
-- Robert T.
mob
> A arguments
>
> args makes no sense, it's not used anywhere in JS itself and mixes up a
> builtin variable name with the habit people have of assigning something
> like:
> var args = Array.slice(arguments);
> Inside of function calls to have an arguments array they can mutate.
>
> Using `arguments` is basically like considering "My program is like a
> big function. When it's executed I can have a list of arguments passed
> to it from where it was called"
>
> ~Daniel Friesen (Dantman, Nadir-Seen-Fire)
the command line. So args is quite familar in that context.
Tom Robinson
Could you / Hannes summarize the arguments for each?
I was under the impression it needed to be a "free" variable for
passing in "capabilities" (in particular stdin/out/err and fs) to
secured modules. How would you do the same thing using a module?
Kris Kowal
> Could you / Hannes summarize the arguments for each?
Sure, but if you're not interested in the mind numbing details, please
goto END_OF_HARD_PART;
The only requirement for security is that capabilities (objects that
provide authority to any program that has a reference to them) like
"stdin" and "fs" be exclusively controllable by the person making the
sandbox. A comprehensive interface for running a program in a sandbox
might look like this:
sandbox(mainModuleId, capabilities = {}, modules = {}, loader = require.loader);
"modules" is usually an empty object for storing the module exports
objects, but you could potentially prime it with modules constructed
in your sandbox, which is potentially hazardous if you simply put one
of your modules in the sandbox instead of carefully crafting frozen
capability objects. Your modules have access to your capabilities, so
putting a naïve module into a sandbox could result in your authority
leaking into the sandbox. It is easier to think about the flow of
authority if no module has any inherent authority. All modules would
then receive their authority from a shared object managed exclusively
by the sandbox's creator, the "capabilities" object. We're
recommending that, for convenience, the capabilities object be known
as the free variable "system", since there's been some discussion
about where to put capability objects like "fs", and "stdin".
END_OF_HARD_PART
It is equally hazardous to inject a naïve module as it is to inject a
naïve capability object, and it's equally possible to manage module
injection and "system" injection well. We cannot claim that a free
variable is _necessary_ for securability. We could provide either of
these two routes:
var system = freeze({stdin, stdout, stderr, fs, args, env});
sandbox(main, system, [options]);
// wherein system becomes a free variable in the sandbox
var system = freeze({stdin, stdout, stderr, fs, args, env});
var modules = freeze({system: system});
sandbox(main, modules, [options]);
// wherein "system" is a module in the sandbox
There is no distinction in securability. However, Ihab and I contend
that the latter is more hazardous and could lead to unnecessary
coupling of our API's and the security platform. Ihab also contends
that it constitutes an unnecessary and undesirable conflation of the
capability object's name space (system.*) with the module name space
(require(*)).
Kris Kowal
Ash Berlin
To me, std{in,out,err} belong in an IO module, not a system module,
since they are properties of the IO 'subsytem' and not the system
itself.
Thoughts on this (removing std io handles from sys(tem) and putting
them into an IO object/class/namespace)