Discuss
  • Proposal revisions: "Draft Proposed Standard SES" becomes "Draft Proposed Frozen Realm API"

Proposal revisions: "Draft Proposed Standard SES" becomes "Draft Proposed Frozen Realm API"

# Mark S. Miller (9 years ago)

At FUDCo/ses-realm

Since I last posted this, I have received much useful feedback of this proposal, especially from Daniel Ehrenberg, Ojan Vafai, Elliott Sprehn, Alex Russell, and Dave Herman. Thanks!

This revision addresses this feedback in a variety of ways:

  • By overemphasizing security, the previous version underemphasized the utility for normal non-security robustness.
  • In accord with extensible web principals, it proposes a lower level API not specific to ocaps, that can support ocaps and other security models.
  • It reconciles this proposal with the old Realms API proposal at gist.github.com/dherman/7568885
  • By generalizing the spawning of descendant realms, this API supports the creation of polyfilled realms derived from TheFrozenRealm.

Enjoy!

# Bradley Meck (9 years ago)

Does this mandate that the global inherit from any specific prototype? Most cases in the wild inherit from Object at some point, but I feel that should only be in the Annex. Several large libraries depend on this, but it is not strictly required for all libraries.

# Mark S. Miller (9 years ago)

Good question!

Regarding the existing global, the frozen realm API proposal does not say anything at all -- it is concerned only about TheFrozenRealm and realms descendant from it. Outside of the frozen realm proposal, I would indeed like us to pin this down better for globals in general. Why only in the Annex? If we can get agreement to pin it down, I would prefer that it be in the main normative-mandatory text.

Regarding the global of TheFrozenRealm, I did not intend to underspecify that. This is an oversight that I will fix. When I said "the global of TheFrozenRealm is a plain object" I had in mind that it would inherit directly from Object.prototype. I will revise to say that explicitly.

# Bradley Meck (9 years ago)

This requirement is not specified in EcmaScript, and I have started playing around with null inheriting globals. I do not want it explicitly mandated by this if ES does not mandate it. Is there a reason it is a mandate and not an Annex that is there due to some parts of the ecosystem?

# Mark S. Miller (9 years ago)

On Tue, Mar 29, 2016 at 6:54 AM, Bradley Meck <bradley.meck at gmail.com>

wrote:

This requirement is not specified in EcmaScript, and I have started playing around with null inheriting globals. I do not want it explicitly mandated by this if ES does not mandate it. Is there a reason it is a mandate and not an Annex that is there due to some parts of the ecosystem?

If we can get general agreement, to minimize pointless variations after that agreement, mandating the agreed state is generally better. If we can't, then we probably can't get enough agreement for an Annex B entry. The main reason for listing something in Annex B:

  • It is normative optional -- if the feature exists at all, it must exist like so.

Since the global object must exist, the normative optional rationale would not seem to apply.

# Mark S. Miller (9 years ago)

On Tue, Mar 29, 2016 at 6:50 AM, Mark S. Miller <erights at google.com> wrote:

Good question!

Regarding the existing global, the frozen realm API proposal does not say anything at all -- it is concerned only about TheFrozenRealm and realms descendant from it. Outside of the frozen realm proposal, I would indeed like us to pin this down better for globals in general. Why only in the Annex? If we can get agreement to pin it down, I would prefer that it be in the main normative-mandatory text.

Regarding the global of TheFrozenRealm, I did not intend to underspecify that. This is an oversight that I will fix. When I said "the global of TheFrozenRealm is a plain object" I had in mind that it would inherit directly from Object.prototype. I will revise to say that explicitly.

Done.

# Bradley Meck (9 years ago)

Moving discussion to FUDCo/frozen-realms#14 , not a fan.

# Mark S. Miller (9 years ago)

On Tue, Mar 29, 2016 at 7:02 AM, Mark S. Miller <erights at google.com> wrote:

[...]The main reason for listing something in Annex B:

  • It is normative optional -- if the feature exists at all, it must exist like so.

As the proposal says:

Some of the elements of Annex B are safe and likely mandatory in practice,

independent of host environment:

Some of these are messy but none are unsafe or inherently stateful. I

would welcome an investigation into which of these are in fact normative mandatory in practice, independent of host environments. For those, I would welcome proposals to move them into the main normative mandatory text. However, I do not have the energy to pursue that myself. Thanks.