Again, couldn't find the answer to this in the archive or wiki…
In the secure case, there would only need to be one frame for all
secure modules in all secure module systems. That frame would be
locked down with something like MarkM's initSES script.
http://code.google.com/p/es-lab/source/browse/trunk/src/ses/initSES.js
Any code evaluated in that frame would be guaranteed by virtue of
Object.freeze to be unable to communicate with any other code
evaluated in that frame except through capability objects explicitly
passed into that evaluation.
This limits the scope of concern for inter-frame communication between
permissive frames and the single secure frame. In those cases, it is
possible for the "outer" frame to construct primordials *for* the
secure frame with that frame's eval:
let frame = Frame();
let SecureArray = frame.eval("Array");
Kris Kowal
--
You received this message because you are subscribed to the Google Groups "CommonJS" group.
To post to this group, send email to comm...@googlegroups.com.
To unsubscribe from this group, send email to commonjs+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/commonjs?hl=en.
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
Thomas Aylott wrote:
> If they don't all work the same way then there is a major
> compatibility issue here.
> This needs to be specified in CommonJS. Isn't that the whole point of
> CommonJS? To unify stuff like this?
> This is not an implementation detail. It's a very basic expectation
> for the environment.
>
> I have stuff to build and I'd like to know how to actually build real
> stuff for the real world right now. Ideally in a way that won't break
> 6 weeks from now.
>
> � Thomas Aylott
> SubtleGradient
> MooTools
>
>
> On Mon, Jan 4, 2010 at 4:30 PM, Kris Kowal <cowber...@gmail.com
> <mailto:cowber...@gmail.com>> wrote:
>
> �
>
Perhaps there is need for "CommonJS Modules" & "CommonJS SecureModules".
I think in this case leaving it undefined as an implementation detail is just going to cause incompatibilities and problems.
I think the crux of the issue for me is discoverability.I've been trying to figure out exactly how all this stuff works practically all day and your short answer here is exactly what I was looking for.If CommonJS ever does specify how natives relate to modules, I'd like this proposal to help push for keeping these two ways of handling natives with modules explicitly separate and distinct.Until then it might be good to explicitly note somewhere that this is undefined and remains so at least until it is explicitly defined.