Distinct usecases from realms #1
Comments
|
Hiya! So, Realms introduce an entirely new set of global intrinsics, which are likely not what people want in all situations. For some cases like : limiting the access to importable resource denoland/deno#2768 , or in the case of hot reloading like nodejs/node#49442 creating a new Realm would actually be harmful. A new Realm would have distinctly different Arrays, Objects, etc. with different prototypes and fail A compartment as has been previously talked about, is purely a manipulation of host behaviors which does not actually cause a "identity discontinuity". That is the important difference. If you were only able to abstract host behaviors using Realms, you would not be able to address a variety of use cases where identity discontinuity is problematic. For ongoing efforts in this space, test runners like Mocha have tried to create entirely isolated workers for doing things like ESM cache invalidation (by destroying the entire Realm) but decided to back out of that approach due to it not working with the existing expectations of running in the same Realm as the test harness. Therefore, this difference seems important to keep as a separate API than Realms, and hence the extraction of Realms from SES and Compartments from SES are separate. |
|
great. It is a little hard to wrap my head around both of these proposals and their implications. I were to massively simplify -- and use the list of use cases from the realms proposal, would this cover the following cases? or more or less of them?
|
|
When you say "plugin mechanisms", i think that's a broader category that might include react and other components? |
|
@codehag likely there is overlap to a lot of these, but they differ in actual usages on if you would want both or just 1. The answer likely is things want to be able to do both behaviors usually but in a 1 Realm to many Compartments potentially with some number of 1 Realm to 1 Compartment usages as well.
Likely this would only use compartments and not realms if the intrinsics are safe to share (freeze them and remove action at a distance vectors [roughly what SES tries to do]). However, it isn't possible to completely "virtualize" all host behavior purely by creating new Realms due to
Likely since Fiddlers are running as a sandbox, but not having multi-tenancy or any sort, purely having Realms might work, but lack of Web APIs would be problematic. Keep using the existing
Likely Realms are all that is desired here since they are trying to isolate the code, but not change host behaviors. This is a little bit misleading though since if they wanted to manipulate how
Likely they want Compartments more than Realms if they are already using
Likely they want both for the same reason as test frameworks. In particular, mocking really wants to be able to have multiple imports of the same target to potentially resolve to different modules.
You likely want both, in particular to censor host behaviors and ban importing arbitrary things which can be used for tracking purposes and/or can load problematic code (this does not stop all vectors). Even if you isolate an address space with the status quo techniques, you still want to prevent some host behaviors (to some extent CSP does allow this in the Web in a non-programmatic fashion).
https://github.com/tildeio/oasis.js ? I am less familiar with that project than current SES / Lightning Web Components / etc. It might be useful with Realms, but it seems it does use some
For ahead of time rendering absolutely since it would isolate things without worries. Would want to see benchmarks for on-demand rendering. We have had a few minor bugs from Isolation problems in production but only a handful over a few years at 1200 builds per deploy at work. For us, the bigger thing we run all our builds in a locale matrix, and being able to properly interact with such a thing in an isolated way is what we want. We don't really need the address space isolation given our work experience and probably don't want it so that our render cache can be shared during all the builds..
I am unsure if this needs Compartments, I don't see a need to isolate the host behaviors unless the editor is trying to emulate things that differ from the current page. They could want to emulate things like import maps, partial evaluation, a REPL etc. So if they want those things, they likely want a Realm, but I don't see the direct need for compartments outside of specific features that might not apply to all editors. Things like the TypeScript compiler can run without either of these proposals which likely is more important.
They both could be used for this. In particular being able to create a way to instrument code is not supported in browsers via intercepting |
|
Thank you for the detailed write up, this helps a lot |
|
@codehag , think of compartments as further subdivisions within a single realm. The similarities between both realms and compartment are indeed confusing. Here is a quick way to tell them apart:
You can also see compartments as an extra construct on the scope chain, which is typically (but not always): |
Hi, I am wondering about what kind of user stories we are thinking about here, and how they differ from realms. This seems like a more light weight solution for things like testing and tooling, but these were also strong arguments for realms. Could you clearly distinguish the unique roles that these two proposals have somehow?
The text was updated successfully, but these errors were encountered: