►
From YouTube: SES-mtg: Draft Compartment API spec
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
A
B
We
did
also
see
some
resurgence
of
that
shared
ROM
intrinsics
on
the
language
repo.
We
probably
discussed
that
briefly.
A
Okay,
well,
I
am
going
to
find
that
document
I
mentioned
and
bring
it
up
on
the
shared
screen.
A
C
D
C
C
Various
folks,
particularly
Gus
Kaplan
I,
think
expressing
skepticism
about
promise
pipelining
that
seem
to
be
rooted
in
in
in
not
in
the
eye.
You
know,
I
think
there's
a
better
way
to
do
this
or
well.
He
kind
of
does
say
that
a
little
bit
but
but
more
into
well
I,
don't
see
what
the
point
of
this
is.
C
Therefore-
and
you
know
I-
think
it's
one
thing
to
to
be
opposed
to
something
on
rounds
that
you
have
a
you
have
a
reasoned
argument
where
you
think
some
other
approach
is
better
or
you
think
it
will
do
harm
in
some
way.
You
have
some
some
concept
of
what
it
is.
You
don't
want,
but
there's
a
there's
another
kind
of
war.
C
A
A
And
let's
only
move
forward
on
something,
if
there's
a
strong
case
that
it
serves
uses
that
are
worth
serving
righteous,
which
is
which
is
different
than
I
have
a
use
for
it.
But
but
as
long
as
they're
open
to
argument
that
other
people
have
a
use
for
it
sufficiently
strong
to
be
compelling.
I
think
that's!
You
know
that,
and
that
is
something
that
we
should
need
to
satisfy
the
month
and.
C
That
that
that
may
be,
in
fact,
the
proper
rhetorical
approach
here,
which
is
not
to
attempt
to
you,
know,
explain
in
more
detail
and
with
more
earnestness,
how
this
works
and
and
and
so
forth,
and
what
it
is,
but
rather
to
have
a
better
explanation
of
use,
cases
or
potential
use
cases,
or
you
know,
going
into
more
depth
about
what
things
this
empowers
or
enables
that
weren't
previously
available
or
were
available.
Only
at
enormous
effort.
D
E
D
Think
something
died
here
too.
Is
that
there's
a
healthy
disregard
me,
an
unhealthy
disregard
for
history
in
the
JavaScript
world
and
I
think
the
past
couple
presentations.
We
focused
mostly
on
the
history
of
how
problems
pipelining
came
to
be
and
I
think
to
some
people.
That'll
just
go
right
over
their
heads
and
they
be
immediately
disregard
stuff
like
that.
Well,.
C
A
C
Bar
on
that
I
share
that
that
perspective,
more
generally,
in
the
sense
that
I
see
a
lot
of
stuff
brought
before
the
committee
that
are
like
something
which
would
be
a
minor
convenience
for
somebody
at
the
expense
of
further
complication
of
the
language
and
and
and
therefore
this
you
know
well,
that's
great
and
all
but
does
is
the
carry
its
weight.
I
think
is
a
perfectly
legitimate
pushback
on
any
proposal
and
I
think
it.
C
A
A
C
A
C
C
A
So
yeah
we,
you
know
what
michael
has
created,
not
just
a
shim
of
the
event,
the
proposal,
but
also
a
shim
of
the
captain,
not
shim,
but
has
created
the
cap,
teepee
library
that
sits
on
top
of
our
Marshall
library,
that
does
the
serialization
on
serialization
of
messages
on
top
of
a
transport
to
bring
about
the
remote
communication,
but
for
actual
industrial
used
without
weak
references,
it
will
run
into
the
same
roadblock
that
connection
went
into
right,
which
is
just
you
know.
After
a
while,
it
just
leaks
too
many
table
entries.
A
C
C
D
E
Yeah
I
said
yeah
I,
said
benefit
with
to
power.
What
has
been
done
by
the
media
freely,
which
is
to
have
a
persistent
connection
between
the
client
and
the
server
and
try
to
do
that
with
where
the
two
system,
the
client
in
the
server
basically
appear
to
work
as
one
unit,
and
there
is
no
there's.
No,
the
the
space
between
the
two
is
tried
to
be
abstracted
so
yeah.
Maybe
there's
something
to
that's.
E
That's
why
I
was
asking
if
something
like
meteor,
which
you
know,
is
very
novel
in
the
terms
still
today
in
terms
of
single
web
application.
If
it
was
a
revolution
when
it
came
out
and
but
I
think
that
the
technology
that
they're
using
might
not
be
might
not
have
progressed
to
other
framework
because
it's
hard
to
obstruct
it
for
MIDI
or
if.
E
A
C
A
D
Okay,
I
guess
I
see
I'm.
The
only
downside
with
captain
proto
is
that
sandstorm
being
the
main
client
that
was
using
it
Bailey
developed
the
libraries
to
the
extent
that
they
actually
need
it,
and
it's
it's
good.
But,
as
you
know,
there
is
no
JavaScript
implementation
of
it
because
it's
got
too
much
bookkeeping.
A
Many
industrial
uses
of
distributed
objects
don't
need
full
three-party
handoff.
They
can
continue
to
just
proxy
through
the
introducers
and
for
many
many
uses
that'll
be
fine,
just
not
further,
but
you
know,
gorrik
will
need
something
more
because
we
need
to
get
checkable
object,
identity
of
objects
arriving
through
multiple
connections.
For
that
you
need.
You
need
the
three
full
three
party
handoff
I.
A
D
D
A
Okay,
so
let
me
make
sure
I
understand
that
the
language
element
of
creating
the
sandbox,
leaving
aside
the
browser
API
just
creating
the
language
sandbox,
that's
working
for
you,
but
in
order
to
make
use
of
the
language
sandbox
the
way
you
want
to
in
the
browser
you
need
to
do
a
safe
interface
to
the
to
the
functionality
of
Dom
API.
Yes,
okay,
so
the
kaha
project
was
the
first
to
do
that.
That's
where
that's!
Where
cess
was
born
back
in
the
atmosphere
five
days,
we
did
a.
F
E
E
So
in
terms
of
open
source,
we
never
got
the
approval
to
publish
Locker
by
itself.
However,
you
can
still
because
of
the
way
things
were
published
at
the
time.
If
you
go
to
the
or
a
framework
repository
which
is
which
is
closed,
it's
all
private
static.
You
can
still
get
at
the
the
build
of
that
of
that
code
and
it's
published
under
the
Apache
License.
So
you
it's
on
github.
D
D
The
code
running
the
sandbox
are
assumed
to
be
safe
and
the
code
outside
of
the
sandbox
are
dangerous.
So
my
in
my
use
case
I
want
to
ensure
that
the
code
outside
the
sandbox
cannot
pollute
the
sandbox
framework
itself
and
the
nor
nots
pollutes
the
Dom
prototype
to
attacked
the
code
inside
of
the
sandbox.
E
E
You
should
see
the
link
there
of
the
bill.
You
completed
the
library,
so
this
is
a
standalone
file.
If
it
still
has
some
API
tell
are
wrapping
it
and
making
it
making
the
facade
or
the
interface
to
Ora
to
the
old
framework.
But
in
it
you
will
see
the
secure
window,
the
secure
document
and
all
of
these
biggest
object
that
were
reified
as
as
an
attenuator
over
the
non
secure.
E
A
F
D
F
D
C
A
Okay,
so
jf
and
I
have
been
working
on
this
document.
That's
titled,
compartment,
spec
experiment
and
the
origin
of
this
is
the
excess
compartment
API,
which
was
a
simplified
API
for
doing
SAS,
with
safe
modules
simplified
in
the
sense
that
that
the
that
the
ability
of
it
to
flexibly
express
various
considering
configurations
of
safe
modules.
It's
not
intended
to
be
fully
expressive,
but
rather
it's
intended
to
cover
the
95
percent
case
with
a
simple
declarative
interface.
I,
don't
think
we're
quite
there
yet.
A
E
We're
also
doing
this
using
a
language
that
is
our
pseudo
code
as
very
similar
to
this
language
respects
writer
of
the
ACMA
that
allows
us
to
reuse
or
try
to
use
concepts
that
are
familiar
to
anybody
all
right
suspects
and
much
easier
detection
of
where
we
could
see
similarities
and
the
current
system
and
where
we
we
need
to
be
careful
of
semantics.
That
could
change
as
clear
ball.
A
Yeah,
so
so
the
document
that
that
jf
had
done
before
I
got
in
there
and
fiddled.
It
was
much
closer
to
actual
spec
language
and
right
as
I
evolved
it
into
what
I'm
about
to
talk
about
you'll,
see
some
places
where
I
just
took
shortcuts,
rather
than
staying
with
the
spec
language,
but
but
yeah.
The
intention
of
this
is
that
what
it
specifies-
and
it
does
in
a
way
that
you're
inspect
language
such
that
at
the
upcoming
tc39
meeting.
A
If
this
is
stable
well
before
then,
and
if
moddable
agrees
that
this
is
implementable
within
their
system
within
their
direct
assess
implementation,
then
I'm
hoping
to
propose
that
SES
with
this
API
and
with
this
language
move
to
stage
two.
So
this
is
a
candidate
they
draft
for
a
candidate
stage
2.
So
the
key
insight
here
is,
that
is,
to
make
the
compartment
constructor
sorry
to
make
the
compartment
instance.
A
A
Sometimes
it
uses
the
term
realm
for
what
we
read
currently
talked
of
as
an
evaluator
or
as
a
compartment,
and
sometimes
it
uses
it
for
what
we
would
currently
call
a
round
so
over
here.
The
only
round
wide
concept
is
the
one
that's
shown
as
the
internal
slot
named
intrinsics,
which
is
the
shared
intrinsics,
which
is
also
an
internal
slot
of
the
realm
record
of
the
five
internal
slots
shown
here
for
a
compartment
instance,
the
first
four
of
them
are
all
internal
slots
of
what
the
spec
calls
a
realm
record.
A
We've
we've
added
to
it
this
concept
of
an
import
map,
but
haven't
said
much
concrete
in
this
document
as
to
what
we
mean
by
an
important,
and
it
could
be
as
simple
as
a
mapping
from
string
name
to
string
name
or
it
could
be.
It
could
potentially
be
something
that
grows
more
into
Michael's,
flexible
loader
concept.
What
would
be
incrementally
adoptable
by
XS
would
be
something
much
closer
to
just
a
simple
string
to
string
map
currently.
A
The
before
any
compartments
are
created,
so
that
so
there's
sort
of
this.
This
prior
configuration
step
that
has
named
all
of
the
modules
that
might
ever
be
instantiated
and
linked
together.
So
the
compartment
API
is
there
to
create
support
for
least
Authority
instantiation
and
linkage
of
modules
by
controlling
the
global
namespace
and
the
import
namespace
that
each
module
sees
and
controlling
how
they're
wired
to
each
other.
A
A
We
think
of
that,
as
going
through
a
map
and
a
mapping
to
some
more
original
set
of
absolute
specifiers
in
very
much
the
same
way
that
an
MMU
maps
from
virtual
addresses
to
physical
addresses,
the
mapping
also
controls
what
you
can
address,
because
you
can
only
address
those
physical
addresses
that
for
which
you
know
that
are
in
the
range
of
that
mapping.
Also
like
an
MMU,
you
don't
know
what
the
physical
addresses
are.
You
just
know
what
virtual
addresses
you
can
say.
C
A
Right,
that's
right!
So
the
way
to
think
about
that
analogy
is
nested:
virtual
machines,
okay!
Okay,
if
you
run,
if
you
run
and
operate,
if
you
run
a
operating
system
on
top
of
a
virtual
machine
running
on
an
operating
system,
then
you've
got
an
emulated
MMU
running
on
top
of
the
physical
enemy,
where
the
emulated
MMU.
What
it
thinks
of
as
a
physical
address
is
actually
another
level
of
virtual
address.
C
A
F
A
No
problem,
okay,
so
that's
that's
I!
Think
the
distinction
between
global
environment
and
global
object
exists
in
the
spec,
given
the
use
for
making
of
it.
We
I
don't
I,
didn't
see
if
there
was
anything
we
needed
to
change
about
that,
we
just
needed
to
adopt
it
in
the
right
place
so
and
the
difference
is
that
when
you
say
global
this,
the
thing
the
object
that
you're
getting
is
the
global
object.
Whereas
when
you
dereference
a
free
variable
name,
the
global
environment
is
the
lexical
environment
object.
A
That's
the
you
know
the
internal
spec
concept
of
what
it
is:
that's
responsible
for
dereferencing,
the
variable
okay
and
then
it's
within
the
logic
of
the
global
environment
that
the
means
by
which
global
variables
are
aliased
to
properties
of
the
global
object.
That's
all
magic
performed
by
the
global
environment,
contract.
C
So
it's
more
like
the
global
object
is
a
data
structure.
A
global
environment
is
an
object
that
does
things
that's
right,
that's
right,
and
so
one
of
the
things
here,
there's
sort
of
you've
got
kind
of
two
different
concurrent
refactorings
going
on.
You've
got
the
realms
two
realms
and
compartments
transition
and
then
you've
got
whatever
it
is.
You're
you're
doing
that's
a
delta
from
the
XS
spec
right.
C
A
A
So
the
other,
so
the
third
element
of
the
refactoring
is
to
bring
more
of
the
mechanics
of
the
import
namespace
into
the
spec,
as
well
as
into
the
API,
because
the
notion
and
import
map
doesn't
correspond
to
anything
in
the
spec,
because
the
spec
is
really
silent
on
how
relative
specifiers
get
turned
into
modules.
They
leave
all
of
that
to
the
host,
and
in
order
to
so
we're
trying
to
do
the
minimal
there.
A
That
still
enables
us
to
meet
the
security
goals.
Obsessed.
The
security
goals
of
says
really
require
enough
control
of
remapping
that
namespace
that
compartment,
a
can
create
compartment,
be
aware,
compartment
be,
is
completely
confined,
and
its
import
namespace
is
you
know,
is
I
can't
contain
anything
that
a
did
not
already
have,
or
that
a
was
not
able
to
get
and
can
use
whatever
names
a
determines.
B
B
should
see
it
through.
A
The
she
went
went
further
held
of
the
simultaneous
solution.
We're
trying
for
here
is
I.
Think
Michael,
with
his
make
importer
that
we've
touched
on
in
previous
meetings,
is
doing
a
great
job
and
coming
up
with
kind
of
the
minimal
necessary
set
of
composable
concepts.
To
give
us
the
full
expressivity
that
you
want
for
safe
modules,
this
one's
trying
to
do
a
90
percent
k,
95
percent
case
I,
actually.
D
A
Will
just
attribute
it
to
both
of
you,
but
any
case,
so
that's
trying
to
cover
the
hundred
percent
case,
the
the
the
full
expressiveness
of
all
of
the
knobs
you'd
like
to
be
able
to
turn
programmatically.
What
this
is
trying
to
express
is
the
and
when
I
say
95
percent
case
I
mean
that
is
a
metaphor.
I
don't
mean
that
as
something
that
was
measured,
but
so
the
other
thing
that's
trying
to
do.
A
A
declarative
covering
of
the
95
percent
case
are
the
tofu
based
configuration
tools
that
Bradley
has
been
working
on
for
node
and
that
Dan
and
kuma
vas
I've
been
working
on
for
meta,
mask
they're,
very
similar
forms
of
configuration
file,
also
tape
and
I
had
a
manual
sketch
of
something
that
we
did
for
the
to
do.
List
example,
and
that
also
tries
to
use
jason,
has
a
data
declaration,
a
set
of
mappings
that
our
programmer
customizable
to
express
least
Authority
decisions,
and
which
are
again
only
intended
to
cover
the
95
percent
case.
A
So
one
of
the
goals
here
is
that
they
be
the
same
95
percent
case,
in
other
words,
that
a
program
that
interprets
one
of
those
configuration
files
that
we
should
be
able
to
write
that
program
so
that
it
acts
on
those
configuration
files
using
nothing
more
than
this
API.
In
order
to
set
up
the
execution
environment
that
those
configuration
files
describe
because.
E
E
Well,
I
would
say
that
I
I
think
we
I
would
say
that
the
refinement
of
the
module
spec
is
a
euphemism
in
the
way
that
the
modules
practice
is
quite
confusing.
The
way
it
is
and
it
might
not
even
be
implemented
the
way
it
specified
I'm,
currently
taking
a
look
at
what
the
model
is
doing,
because
I
believe
that
their
specs
cannot
be
implemented.
E
In
my
considering
the
frozen
aspect
that
the
introduced
and
one
thing
that
Michael
and
saw
the
module
system
is
trying
to
do,
is
separate
a
static
record
versus
a
linkage
record
record
and
so
far
my
understanding
of
excess
is.
They
have
come
to
realization
that
it's
necessary
and
I'm
doing
the
same
exercise
for
that
that
I've
done
for
for
the
compartment
API.
Trying
to
express
that
aspects
and
I
believe
that
they're
in
a
subsequently
meeting
will
have
a
clearer
picture
of
that.
But
it's
most
likely
that
we
will
have
to
evolve
the
module
specs
yeah.
C
E
E
One
example
of
those
kind
of
shortcut
is
the
idea
that
we
were
discussing
owned
on
the
specs
website,
with
which
regards
to
Bradley's
proposal,
to
allow
reusing
a
realm
record
for
compartment
and
making
an
adjustment
on
the
lookup
of
the
intrinsic.
It's
something
that
by
accident
or
by
reading
to
Bradley
access
has
done
and
in
their
world
compartment
is
complete,
backed
up
by
a
realm
record.
E
It
has
its
own
realm
record
I
accept
that
their
realm
record
doesn't
have
an
intrinsic
slot
and
the
reason
that
doesn't
exist
at
all
in
excess
is
that
intrinsic
there's
only
one
set
of
into
existing
the
whole
engine
and
each
item,
there's
no
intrinsic
bank
and
each
item
is
a
is
a
global.
Each
one
of
the
name
intrinsic
is
a
global
object
to
all
modules.
So
it's
it's
imagine
that
X
we
were
to
follow
Bradley's
proposal.
E
C
Leeway
left
to
the
host
implementers
in
in
the
module
spec,
and
you
know,
on
the
one
hand,
sort
of
narrowing
that
down
and
kind
of
being
a
little
bit
more
prescriptive,
a
little
bit
more
rigorous
kind
of
constrains
their
options.
But,
on
the
other
hand,
it
may
also
they
are
also
in
a
situation
where
they
would
like
their
options
to
be
constrained.
In
order
to
have
to
know
that
they
can,
they
can
correctly
employ
various
optimization
strategies
and
and
therefore
being
more
precise
about
what
exactly
is
going
on
actually
makes
their
lives
easier.
C
E
And
I
would
add.
The
third
concern
there,
which
I,
which
was
discussed
on
that
thread,
would
would
Bradley.
Is
that,
if,
though,
all
of
those
separations
I
said
do
some
kind
of
magic
in
the
host
in
order
to
achieve
end
result,
it's
very
difficult
to
reason
along
those
holes
provided
operation
in
terms
of
security
parameters,
because
we
don't
know
what
the
implementation
is
and.
C
C
The
security
analysis
is
clearly
central
to
our
own
interests.
I
think,
there's
also
I
suspect
the
test
two
six
two
people
may
have
some
opinions
here,
just
in
terms
of
to
the
more
the
equator.
The
extent
that
the
behavior
can
be
characterized
precisely
the
greater
the
extent
to
which
tests
can
be
constructed,
which
will
yeah
yeah.
D
A
D
A
In
the
same
way
that
that
you
know
you
can
potentially
load,
you
know,
you
can
certainly
you
in
the
same
way,
you
can
load
different
modules
into
different
compartments.
You
should
be
able
to
load
different
scripts
into
different
compartments,
the
nether
the
said,
but
but
so
okay,
so
so
this
conversation
brings
some
more
constraints
on
the
design
that
are
worth
studying.
A
There's
the
the
the
big
one
that
got
us
here,
which
is
the
separation
of
the
notion
of
multiple
realms
from
the
notion
of
multiple
compartments.
When
we
first
proposed
realms
and
compartments,
we
did
it
in
such
a
way
where
the
notion
of
multiple
compartments
depended
on
underlying
mechanisms
and
API
supporting
multiple
realms.
A
These
are
now
completely
separated,
cominius
separately
working
on
the
realms
proposal,
which
is
only
about
mental
realms
and,
as
jf
mentioned
in
this
proposal,
the
Rome
concept
only
shows
up
as
the
intrinsics
and
there's
only
and
there's
nothing
here
that
introduces
a
new
intrinsic
set.
It's
just
reusing
some
intrinsic
set
that
came
in
so
in
that
sense,
the
realm
API
should
be
in
order
for
moddable
not
to
have
to
create
multiple
root
realms,
which
is
quite
a
burden
just
to
conform
to
the
spec.
C
Yeah
I
think
that's
very
clean,
well,
I
think
the
whole
realm
versus
compartment
distinction
is
very
clean.
Well,
which
and
clarifies
many
things.
I
am
wondering,
though,
how
much
work
is
going
to
be
involved
in
in
patching
all
of
the
other
parts
of
the
spec
that
just
make
reference
to
realm
or
to
the
realm
record
in
in
various
different
places.
C
E
Many
play
the
places
where
the
realm
record
is
used
is
like
in
function.
Evaluation
in
in
the
eval
function,
sorry
in
a
constructor,
so
there's
always
a
reference
to
a
REM
record
there.
It
might
it
told
me
it
doesn't
mean
it's
a
realm.
It
means
it's
a
it's
a
bag
of
things
that
travel
together,
and
this
is
where
you
can
get
it.
So
they
used
a
rubber
record
in
order
to
in
order
to
get
to
the
global
object
and
so
on.
E
C
A
Yeah,
so
let
me
propose,
let
me
propose
quite
explicitly,
but
since
this
compartment
object
has
all
of
the
internal
slots
of
the
realm
of
what
is
currently
called
the
realm
record,
that
when
we,
what
we
should
be
explicitly
proposing
is
that
all
occurrences
of
the
term
realm
record
in
the
spec
get
renamed
into
compartment
exotic
object.
We
don't
need
a
separate
internal
spec
record
concept.
We
can
just
say
the
the
compartment
exotic
object.
Has
these
fields,
and
it
now
serves
the
role
that
round
record
observed.
E
C
In
essence,
all
of
the
places
which
are
talking
about
the
realm
are
talking
about
the
realm
and
yes,
and
instead
they
could
talk
about
the
compartment
and
they
have
essentially
the
same
meaning
and
anything
which
was
dealing
with
some
concept
of
having
multiple
round
and
managing
them.
That
would
all
be
new
API
anyway,
with
its
own
new
set
of
stuff
to
go
with
it.
That
doesn't
doesn't
impinge
on
the
present
state
of
the
world.
Yeah.
A
I
think
I
think
the
the
way
to
go
about
this
is
for
each
such
yeah.
We
have
to
examine
each
concept
individually
and
each
occurrence
of
these
terms
in
the
spec
to
see
you
know
for
each
such
occurrence.
There's
there's
just
one
simple
question
to
ask:
is:
is
there
one
of
these
per
realm
or
is
there
one
of
these
per
compartment?
I?
Think
the
better
question
yeah.
That's
the.
C
D
C
C
E
And
it's
possible
that
we
don't
know
what
those
are
I
would
expect
that
something
like
import
map,
which
is
something,
and
then
there
are
other
slots
that
that
access
it,
as
has
the
realm
record,
has
nine
slots.
So
there's
so
I'll
dig
deeper
and
I'll
come
back
to
this,
but
I
believe
that
this
is
an
area
where
split
between
whole
specific.
A
E
A
E
D
A
What
what's
shown
here
can
be
implemented
securely
with
high
confidence
by
a
shim
on
top
of
today's
javascript
and
in
fact,
the
subset
of
this
that
that
does
not
include
modules.
The
subset
of
this
that's
just
about
evaluable
scripts
is
we're
going
to
we're,
trying
to
put
together
a
really
hardcore
security
review
of
the
evaluator
shim.
Basically,
if
you
take
this
thing
and
you
remove
all
the
module
concepts,
anger
remove
the
host
defined
field,
what
you're
left
with
is
essentially
the
evaluator
shop.
Now.
A
So
I
think
the
evaluators
room
should
be
made
to
conform.
I
mean
this.
This
document
and
the
evaluator
shim
should
be
brought
into
alignment
and
then
that's
what
we're
going
into
the
security
review,
with
the
reason
why
we're
emitting
modules
from
the
security
review
is
that
the
only
way
we
know
of
to
get
high
confidence
of
security
properties
on
top
of
today's
JavaScript
is
the
eight
magic
lines
of
code
that
only
works
with
the
valuable
scripts,
and
so
in
order
to
securely
work
with
module
source
text.
A
A
A
Did
the
Jas
writing
down
the
semantics
of
the
excess
compartments?
Is
that
the
compartment
constructor
is
not
per
realm?
It's
not
a
member
of
the
intrinsics
they're.
Rather,
the
compartment
constructor
is
in
the
category
of
evaluator,
which
are
per
compartment,
and,
and
that
means
that
compared
it
used
to
be
the
case.
The
compartments
didn't
have
a
notion
of
being
in
any
tree
like
relationship
to
each
other.
They
were
just
directly
contained
within
their
realm.
A
It
was
basically
just
a
two-level
tree
with
with
the
compartments
being
the
leaves
on
and
and
just
delegating
to
their
realm
for
the
intrinsics.
Now
a
compartment
constructor
is
treated
like
the
function
constructor
or
like
the
eval
function.
We
make
a
new
one.
Every
time
we
make
a
new
compartment,
a
new
compartment
instance
so
that
that
instance
create
contains
a
new
compartment
constructor
and
where
this
parent
concept
concept
shows
up
as
significant
is
the
tree
of
import.
A
Mappings
is
that
the
child
constructor
is
constructed
with
a
mapping
mapping
the
import
namespace
that
it
is
providing
to
code
run
in
the
compartment.
It
creates
that
the
import
map
maps
those
to
the
import
namespace
of
the
parent
compartment,
the
compartment
that
that
in
which
that
compartment
constructor
was
found
and
by
treating
it
as
by
treating
the
compartment
constructor
as
as
itself
something
that's
created
per
compartment.
We
keep
that
concept
lexical
and
first-class.
A
There
is
a
temptation
to
specify
this
inheriting
of
context
as
caller
sensitivity,
which
would
be
dynamic,
scoping,
which
we
must
not
do
ever
and
rather
use
lexical
capture,
and
this
keeps
the
lexical
capture
nature
doesn't
matter
who
calls
the
compartment
constructor.
The
question
is
which
compartment
digit
compartment
constructor
come
from.
E
E
A
E
So
you
don't
have
a
surprise
exactly
that's
nice,
yeah
and
that's
interesting,
because
in
a
way
we
didn't
have
that
type
of
inheritance,
but
in
the
realms
three
missions
and
and
what
we
were
trying
to
do.
Any
new
realm
would
have
all
the
sims
of
its
current
be
applied
first
before
it
begins
any
or
new
evaluation
as
a
way
to
preserve
the
how
the
language
was
implemented.
E
What
kind
of
authority
was
given
to
a
new
realm
and
so
that
the
child
could
not
start
over
from
from
from
zero
from
what
the
platform
was
providing
and
the
pattern
parent
was
trying
to
achieve
it
now
doing
do
this
on
the
compartment.
Make
sure
that
a
compartment
created
inside
of
a
compartment
cannot
has
more
authority
than
then
and
then
then,
its
parent
right.
A
If
the
primordial
czar
not
I,
want
to
discuss
here,
deleting
that
line
I
think
we
should
delete
it,
which
will
make
more
work
for
the
XS
guys,
because
then,
if
this
whole
thing
becomes
normative,
they
would
have
to
support
the
compartment
API
both
for
full
JavaScript,
as
well
as
for
SES,
but
I.
Think
that
there's
really
nothing
else
in
this
proposal
that
depends
on
the
intrinsics
being
frozen.
I
think.
C
And
maybe
I've
lost
part
of
the
threat
of
the
narrative
here,
but
we
had
this
notion
and
it's
one
of
the
things
that
kicked
us
out
of
the
sort
of
track.
We
were
on
with
the
original
frozen
realms
proposal,
which
was
the
notion
of
you
want
to
apply
your
various
polyfills
and
shims
and
whatnot,
and
then
lock
the
environment
down
before
you
launch
the
application
code
and.
D
A
C
Three,
yes,
respect
was
was
derived
from
the
notes
from
Microsoft's
reverse
engineering
of
the
netscape
browser
script
implementations.
So
the
spec
started
out
as
a
description
of
the
implementation
as
it
existed
and
then
was
kind
of
massaged
to
to
to
try
to
take
out
the
things
which
were
merely
artifacts
of
implementation
and
to
just
retain
the
things
which
were
fundamental.
E
Are
we
I
see
this,
as
maybe
some
kind
of
invariant,
that
a
component
can
only
be
used
in
a
I'm,
a
frozen
environment
a
little
bit
like
an
environment
that
is
impose
on
the
proxy
just
to
present
misuse
or
prevent
a
proxy
to
be
lying?
In
this
case,
I
don't
want
to
maybe
I
don't
want
to
have
a
compartment.
It
could
be
lying
about
its
capacity
to
isolate
I.
C
E
E
A
A
E
A
D
A
Right,
so
that's
so
good
I'm
glad
you
mentioned
that
because
that's
a
big
big
thing
that
I
completely
forgot
to
talk
about,
which
is
the
full
proposal
for
tc39,
has
to
explain
how
a
JavaScript
realm
becomes
assess
realm
and
therefore
has
to
explain
how
the
intrinsics,
how
you
come
to
have
a
frozen
set
of
intrinsics
and
whatever
else
the
properties
are.
That
distinguish
a
JavaScript,
a
normal
JavaScript
realm
from
assess
around
and
since
assess
no
longer
depends
on
the
concept
of
multiple
realms.
A
That
has
to
be
an
explanation
of
how
you
do
that
transformation
from
the
inside,
rather
than
how
JavaScript
code
creates
a
separate
sass
realm.
So
none
of
that
is
covered
in
this
API
and
the
reason
none
of
that
is
covered
in
this
API
is
again
because
of
the
modularity
of
concepts
that
we
inherited
from
XS
that
we
like,
which
is
there's
really
two
separable
issues,
which
is,
if
you're
starting
with
JavaScript.
How
do
you?
How
do
you
come
to
be
incest?
C
E
Believe
that
the
cess
has
a
mode
where
you
don't
have
to
be
frozen,
so
that's
something
I'm
quickly.
Looking
at
this
deeper
into
their
system
and
I
have
to
do
the
groundwork,
because
we,
the
folks
at
Volvo,
I,
assume
busy
these
days,
but
there
is
in
their
marginal
system
and
everything
is
based
on
module.
They
have
evaluators,
they
have
precompiled
binary
modules,
but
they
also
have
the
capacity
to
Hugh
so
scope.
E
What
we
thought
of
doing
in
the
in
the
in
the
in
our
implementation,
success
is
only
put
the
compartment
constructor
on
the
global
once
the
intrinsic
sub
in
frozen
as
a
way
to
achieve
the
same
benefit
of
not
having
a
compartment
use
when
something
is
not
frozen.
When
the
center
in
the
world
suck
for.
F
Would
it
make
sense
to
say
that
across
compartments,
you
might
want
a
built-in
normative
approach
to
take
the
same
internals
and
wrap
them
with
a
new
version
of
the
prototype?
So
so
it's
it's.
What
gets
wrapped
around
the
the
internal
constructor
itself
so
that
two
compartments?
We
have
to
object
instructors
referring
to
the
same
internal
constructor,
but
the
prototypes
for
both
are
completely
separate.
F
F
A
No,
what
I'm
proposing
here
is
that
we
just
have
a
new
exposed
objects
which
we're
defining
there,
which
is
that
the
compartment
constructor
is
a
an
exotic
object
with
that,
whose
only
special
thing
is
this
internal
parent
slot
and
then
a
compartment
instance
is
an
exotic
object
with
with
these
six
slots
finals,
which
are
barred
from
the
existing
realm
record
that
and
then
it's
we
just
substitute
the
the
compartment
instance
exotic
object
for
all
occurrences
of
realm
records,
so
it
just
becomes
the
new
realm
record.
It's
not
wrapping
anything.
Okay,.
F
A
With
regard
to
prototypes,
one
of
the
things
I
did
here
is
I,
followed
sort
of
the
standard
pattern
which
is
there's
also
and
in
a
intrinsic
object.
That
comes
in
with
this
proposal
called
compartment
prototype.
That's
not
exotic.
It's
a
plane
object,
but
the
compartment
Constructors
dot
prototype
is
that
that
prototype
object
when
the
compartment
constructor
makes
a
compartment
instance,
it
makes
the
compartment
instance
inheritance
in
the
karo
type,
so
just
the
normal
wiring
there
and
then
the
further
part
of
that
normal
wiring
is
the
compartment.
A
Prototype
object
has
the
new
built
in
methods
that
are
built
in
access
or
properties
that
are
coming
in
with
this
proposal.
So
this
is
where
the
remainder
of
the
API
of
this
proposal
comes
in.
So
it's
worth
going
through
that
which
is
from
a
compartment
instance,
just
provide
directly
provided
access
of
property
for
getting
at
its
global
object.
That's
pretty
much
always
been
part
of
our
notion
of
a
compartment
of
a
realm
instance
API
now
compartment
instance
API.
F
A
The
global
the
global
this
does
get
populated
and
where
it
gets
populated,
is
starting
at
line
11
here
in
the
constructor.
So
we
make
the
new
global
over
here
with
you
know,
object
create,
create
an
object
that
inherits
from
object,
prototype
and
then
in
line
11
we
basically
go
through
all
of
the
normal
global
intrinsic
the
global
named
intrinsics.
That's
how
I'm
interpreting
line
11,
also,
all
the
global
names
intrinsic
switch
are
per
realm
rather
than
per
compartment,
and
therefore
excluding
global.
A
This
eval
the
function
constructor
and
the
compartment
constructor
itself,
and
so
we
just
initialize
those,
and
then
we
do
the
further
initialization
of
the
things
that
are
per
compartment,
the
eval
function
and
the
eval
function
and
the
functioning
apart,
reconstructors
and
then
finally,
the
global.
This
object
just
pointing
at
itself.
A
F
And
that
that's
a
global
object
of
this
particular
compartment
that
does
not
get
like
any
kind
of
shared
state
other
than
the
fact
that
sorry,
so
to
clarify
the
object
constructor
itself
in
that
global.
This
will
be
wrapping
the
realms
internal
object
constructor,
but
it
will
have
a
separate
prototype
at
this
point.
Brno
from
another
car
I.
E
E
E
E
Yeah,
so
one
of
the
one
of
the
also
one
of
the
other
constraint
on
the
assess
world-
and
it's
something
I
haven't
looked
deeply
into
how
it's
done
in
excess
is
that
the
prototype
constructor
cannot
be
called,
cannot
be
called
ball
because
there's
only
one
set
of
prototype
for
for
those
things.
So
for
the
four
items
we
were
concerned
with
the
four
for
constructors,
one
of
the
things
that
we've
always
done
in
our
sins-
and
this
should
be
part
of
the
proposals
in
some
way-
is
that
those
things
are
not
callable.
E
F
A
So
I'll
tell
you
where
this
comes
up,
that
I
completely
overlooked
comes
up
into
it.
That
needed
to
come
up
in
this
document,
but
I
completely
overlooked,
which
is
the
compartment
prototype
object,
is
the
the
prototype
object
itself
is
per
realm.
Not
per
compartment.
I
have
stated
that
explicitly
because
we're
creating
a
compartment
constructor
per
compartment,
but
they
all
point
at
the
same
compartment.
Prototype
object,
but
the
additional
thing
that
was
the
more
egregious
omission
is
on
the
compartment.
Prototype
object.
A
F
E
C
D
A
A
Target
hasn't
been
defined
anywhere
in
this
algorithm,
so
that
is
jf
correct
me
if
I
got
this
wrong,
but
I
believe
that
there's
boilerplate
text
or
there's
text
explains
the
boilerplate
in
the
equi
script
spec
such
that
within
the
documentation
of
any
constructor
new
target.
Is
this
weird
special
thing
and
the
real
special
thing
it
refers
to
is
the
constructor
that
that
it
was
originally
invoked
on
or
in
the
case
of
the
reflect
construct?
The
third
argument
to
reflect
that
construct.
A
E
De
Janerio
that
the
spec
is
is
a
recluse.
Sometimes
the
target
is
passed
in
as
a
parameter.
Sometimes
it's
a
slot,
and
sometimes
it's
it's
something.
That's
using
a
parameter
like
when
we,
when
we
see
here
when
the
component
constructors
construct
is
call
with
Amara,
there's,
usually
a
mention
with
what
new
target
is
at
that
point.
But
it's
it's
usually
a
something
that
doesn't
need
to
be
specified
because
we
all
know
whether
it's.
E
A
E
E
D
E
E
E
F
F
A
A
A
You
know
by
whether
I
get
a
page
fault
or
not
or
whatever,
and
adding
a
query
for
that,
doesn't
violate
any
important
principle
but
being
able
to
know
what
physical
address
is.
Those
virtual
address
is
mapped
to
is
just
a
complete
abstraction
violation
and
it
kills
virtualize
ability,
because
then,
if
I'm
run
in
a
an
equivalent
virtual
machine,
that's
mapped
to
an
underlying
machine
differently.
Suddenly,
I
can
detect
that
so
I
think
the
same
thing
comes
up
here
in
exposing
the
important
map.
A
E
B
A
That's
that's
definitely
a
something
that
we
need
to
do
as
part
of
this.
We
need
to
figure
out
where
the
resolve
API
goes
and
the
way
the
way
the
absence
of
that
shows
up
here
is
that
this
spec
only
talks
about
absolute
specifiers.
It's
completely
silent
on
any
control
of
how
relative
specifiers
are
mapped
to
absolute
specifiers,
yeah.
E
A
E
B
B
E
B
A
F
One
question
about
the
resolve
and
compartment
specifically
are
we
saying
resolved
is
something
that
happens
on
behalf
of
the
compartment
or
through
the
converting,
because
I
believe
a
compartment.
Is
you
know
something
that
you
put
together
for
a
function?
Then
you
you,
you
know
it
supersedes
it
that
you
resolve
on
its
behalf,
like
that's
an
external
look
like
an
eye
cream,
you
know
you
resolve
what
the
iframe
is
requesting.
You
don't
let
the
iframe
handle
its
own
resolution.
F
You
know
here
we're
talking
about
the
serviceworker
perpetrate,
so
I
think
it
helps
to
want
to
say
whether
or
not
you
want
the
compartment
itself
to
be
aware
of
the
resolve
happening
or
for
it
to
actually
be
the
external
facing
API
that
that
gets
called.
But
you
know
on
behalf
of
the
compartment
not
not
from
within
it.
So.
A
A
A
B
B
B
A
Certainly,
certainly
this
spec,
even
with
the
resolve
hook,
remains
silent
on
non-ethnic,
script,
modules
and
I.
Think
that's
fine
I
think
I
think
to
go
to
propose
something
for
states
to.
We
should
have
the
resolve
hook,
but
I
think
it's
fine
for
stage
two
at
this
point
still
be
silent
on
coexistence
with
Monaco
script
modules.
D
E
A
E
And
this
there's
a
fair
there's
been
there's
been
it's
an
evolution.
This
is
simplification
of
realm
at
the
first
stage
and
then
this
about
motivated
another
refactor,
which
was
to
get
into
a
carapace
split
between
RAM
record
and
anybody
and
getting
closer
to
the
specs
in
terms
of
performing
well
and
all
of
that.
So
we
have
fewer
concept
like
a
factory
of
factories
and
things
like
that.
So
it's
a
lot
simpler.
A
But
then
there
is
the
various
things
that
cause
evaluation
and
there
are
three
different,
distinct
dimensions,
variation,
two
of
which
are
orthogonal
to
each
other.
That
I
was
trying
to
capture
here
and
I
was
trying
to
capture
it,
not
with
parameters.
Even
though
there's
some
there's
some
orthogonal
T,
because
they're
static
concepts,
it
doesn't
make
sense
for
one
string
to
evaluate
one
way,
sometimes
and
another
way,
another
time
so
I
wanted
a
separate
method
name
for
each
kind
of
evaluation,
but
I
wanted
a
naming
convention
to
show
what
the
relationships
are.
A
That
means
you
know
the
problem
with
that,
especially
when
you
look
at
access
is
that
that
requires
the
virtual
machine
to
support
sloppy
mode,
at
least
to
the
extent
of
running
until
yeah
or
or
rather
of
parsing
and
recognizing
the
directive
and
if
you're,
just
trying
to
build
a
strict,
only
machine.
You
shouldn't
need
to
do
that.
So
so,
there's
sloppy
versus
strict
there's.
A
Something
that's
very
obscure
that
I
have
generally
forgotten
in
previous
generations
of
this,
which
is
running
curve
al
you
ating
code
as
what
the
spec
calls
eval
code
versus
running
the
code
as
global
code,
so
in
the
brown,
so
so
the
so.
The
only
reflective
way
of
running
tired
that
language
provides
for
is
running
code
as
eval
code
using
eval
or
the
function
constructor.
A
However,
when
when
you
have,
let's
say
a
script
tag
with
the
script
in
the
browser
or
a
dot
JS
file
that
actually
I
don't
know
what
the
situation
of
nodes
I
won't
speak
to
that,
but
but
the
script
and
the
browser
it's
not
running
as
if
it's
a
it's
a
string
being
evaluated
by
eval.
The
difference
is
what
happens
to
top-level
variable
and
function,
declarations.
A
A
A
F
F
F
So
so,
there's
a
that.
That's
from
the
script
tag
when
I
give
it
an
SRC
attribute,
I
believe
that
actors
into
the
relative
dynamic
import
calls
from
this
SRC
location.
Basically,
so
so,
if
we're
going
to
be
synthesizing
this
by
a
function
call,
then
it
probably
should
be
able
to
emil
ate
the
script
tag.
C
That
I
I
think
the
factoring
out
is,
is
so
much
of
separate
methods
is,
it
might
be
the
best
of
a
bad
set
of
alternatives.
I
will
acknowledge
it
is
but
ugly
and
I'm
very
concerned
about
the
difficulty
of
explaining
it,
and
part
of
the
problem
is
what
you're
capturing
is
a
bunch
of
underlying
subtle
distinctions,
and
the
problem
is
that
those
distinctions,
first
of
all
that
they
exist,
but
then,
second
of
all,
they
need
to
be
explained.
C
I
think
that
particular
name
a
bunch
of
different
non-orthogonal
ease
in
it
that
make
it
additionally
confusing
and
perhaps
unnecessarily
so
you've
got
run
versus
he
valued
that
script
versus
module
person's
expression,
you've
got
sloppy
versus
strict
versus,
doesn't
say
anything
about
it
and
it.
It
feels
like
a
a
muddled
jumble
yeah.
C
E
D
E
D
C
C
I
am
a
little
nervous
about
support
and
whether
whether
whether
running
legacy
code
is
gonna
even
be
a
thing
in
this
world,
because
this
world
is
going
to
be
have
so
many
other
things
that
are
new,
that
we
might
as
well
do
just
what
you
said.
On
the
other
hand,
Marquess
is
pushing
for
being
more
and
more
rigorous
about
virtualize
ability
and
I'm
wondering
if
that
might
enter
into
into
this
discussion
as
well.
So.
A
The
test
of
virtualize
ability
is
whether
on
one
host,
you
can
emulate
another
host
such
that
code
running
under
the
emulated
host
really
for
most
purposes
thinks
it's
code
running
on.
You
know
running
on
the
host
being
emulated.
So
if
you're
going
to,
for
example,
emulate
a
browser,
then
you
would
like
some
straightforward
straightforwardly,
correct
thing
to
do
with
the
content.
Contents
of
script
tags
and.