Re: [w3ctag/design-reviews] Realms API ECMAScript Proposal (#542)

Hello! 

It's been a while but we finally worked on top of @domenic's proposal and adjusted our Realms proposal that avoids direct access to objects while enabling a Callable Boundary between realms. 

This Callable Boundary API enables implementation of membranes frameworks as a good layering for virtualization. We have a [proof of concept here](https://github.com/caridy/irealm). 

We've been iterating over this new updated API within weekly public SES meetings, where it received a very positive feedback. We also presented it to the TC39 Plenary where we received a general positive feedback (meeting notes pending publication).

The slides are [here](https://docs.google.com/presentation/d/1VbfgfZgNCcWhPu-8JWd27hrL9jEfakWPSWPcJLa3SIw/edit#slide=id.gcbecde6e4c_0_7
) and I intend to record a presentation for future usage. The new [rendered spec text is here](https://tc39.es/proposal-realms/). The link for the explainer, remains [the same](https://github.com/tc39/proposal-realms/blob/main/explainer.md), but it's now updated to match the new API.

I'd like to present it again to TC39 in May 25th requesting advancement to Stage 3. For that, I don't have plans to make many essential changes to the API.

There are some open points I'm interested to discuss and I'd appreciate feedback:

## Challenge: Global names

The Realm global should only include a new set of intrinsics listed in ECMAScript as the global names.

After analysis, I'm strongly arguing against shortening this list. This means we should shorten the list of global names describe in ECMAScript. FWIW, there is already a strong pushback from TC39 to make this special subsetting in ECMAScript.

The other way around would be introducing **more** names global list, to be defined by the host. I don't think it's useful, as any flexibility would end up requiring most customization for virtualization settings to verify and replace or remove host defined APIs. The environment virtualization is among the main use cases for Realms, and IMO there isn't a specific line between the ECMAScript intrinsics and the names of a Window proxy object. The ES intrinsics set remains the common point between any hosts, including those that are not part of the Web Platform.

## Challenge: Separate Module Graph

Each new Realm should have a separate module graph. For the same reason the API will not provide any access to non-primitive values, we believe it's very important to not leak global values through realms using modules.

A shared module graph would potentially introduce a place to leak identity discontinuity we are trying to avoid, as the Realms essentially have a separate set of globals.

## Naming (Bikeshed, mostly)

- `Realm` could be renamed to something else that translates it's only a Callable Boundary. I still can't think of a better name for the Realms constructor other than Realm, but I want to make sure we exhaust the options.
- `Realm.prototype.importValue`: This method is called this way as it captures a value from a dynamic `import`, and this captured value is not a dynamic binding, as it would be if placed in a module namespace.




-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/542#issuecomment-825314747