►
From YouTube: SES-mtg: Scoping of host hooks
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
Okay,
good
I
guess
he
is
now
implementing
the
compartment
ship,
the
the
compartment
shown
as
it
had
been
implemented
till
now,
as
well
as
the
way
in
which
we
conceived
that
the
department
spec
until
now
was
that
it
was
that
both
of
them
were
set
specific
and
the
operation
that
that
takes
your
environment.
The
realm
urine
and
and
changes
it
from
being
a
normal
JavaScript
I'm
realm
to
being
a
sus
realm
is
called
lockdown.
A
However,
the
we
have
since
divorced
the
two
in
the
spec
as
we
needed
to
so
Bradley's
draft
spec
has
the
part:
has
the
compartment
proposal
be
independent,
assess
we
need
to
adjust
the
shim
to
do
likewise
and
then,
but
this
range
is
this-
raises
a
bunch
of
questions
about
what
does
lockdown
do,
given
that
compartments
already
existed
before
lockdown
got
called,
but
after
lockdown
gets
called
everything
needs
to
have
safety,
how
it
needs
to
obsess
safety
properties
covered.
Is
that
a
good
summary
I
believe.
B
C
A
A
It's
simply
a
right
now,
at
least
it's
simply
a
separate
API.
It's
sort
of
at
this
point
the
defining
API
for
sess.
Now
that
compartment
has
been
removed
from
sess
and
whether
it
gets
bundled
in
with
something
else.
For
example,
bundling
lockdown
together
with
hardened
I,
think,
could
make
a
lot
of
sense,
but
no
second
decision
has
been
made
right
now.
Lockdown
is
simply
a
separate
one
function,
API
yeah.
B
A
Good
point
about
realms,
not
existing,
so
I
think
the
excess
case
establishes
that
it
should
not
be
in
realm,
because
the
way
that
you
should
test
that
your
honor
virtual
machine
does
not
support
multiple,
realms
or
yearning
environment
things
not
support.
Multiple
realms
is
the
absence
of
the
realm
door.
Hi
Sala.
B
A
Yeah,
so
the
the
other
thing
that's
interesting
about
lockdown.
Is
that
it's
not
we
can.
We
can
make
some
further
distinctions
here
than
just
a
transition
from
normal,
JavaScript
I
think
we
need
to
make
some
more
distinctions
than
just
the
transition
from
normal
JavaScript
to
full
cess,
and
this
was
driven
by
an
insight
from
Michael
hunters
velocity
c-53
meeting,
which
is
the
you
can
be
on
a
something
that
is
a
machine,
tended
to
be
assess
machine
with
that,
but
in
which
the
primordial
czar
not
frozen.
A
A
The
IO
to
the
outside
world
would
only
be
enabled
on
the
other
side
of
the
snapshot
and
as
I'm
saying
all
this,
that's
not
really
a
JavaScript
concept
either.
This
was
not
I.
Did
I
went
down
this
without
having
thought
it
through
well,
I.
Suppose
the
main
JavaScript
significance,
significant
thing
is
that
there
is
taking
the
JavaScript
environment
and
making
it
sus
safe
in
terms
of
all
of
the
repairs
and
then
there's
a
separate
separable
transition
from
actually
freezing
the
prime
organism.
A
C
The
way
it's
supposed
to
be
like
we
wished,
it
had
been
from
the
very
beginning,
stuff,
there's
there's
a
sort
of
shimmy
and
poly
filling,
which
is
make
the
environment
behave
in
a
particular
way,
because
we're
trying
to
be
compatible
with
some
future
version
of
language
standard
which
this
engine
that's
the
yet
support,
or
something
like
that
right
and
then
there
is
environment
customization
which
is
I'm
going
to
set
up
an
environment.
That's
designed
for
this.
You
know
this
application
domain
that
has
some
stuff
that
it's
sort
of
pre
provision
with
and
I.
C
When
we
talking
about
locking
down
all
the
compartments,
that
seems
like
there's
a
presumption
they're
that
once
locked
out
has
happened.
You
can't
create
more
compartments,
no,
no,
not
wrong,
not
at
all
okay.
So
what?
If
you
want
to
create
a
new
compartment?
That's
customized
differently
than
the
existing
ones
after
you've
done
lockdown.
How.
A
Does
that
work?
No,
it's!
Okay!
The
the
purpose
of
customization
is
not
to
before
you
call.
Lockdown
is
not
to
customize
compartments.
It's
to
customize
the
realm
as
a
whole.
I
need
to
customize
the
shared
core
morning's
okay,
okay,
all
the
customization
that
is,
that
is
just
customizing.
The
compartment,
that's
just
normal
stuff
that
you
do
with
the
compartments
with
you,
I.
A
B
A
A
Those
can
you
can
just
run
those
and
they
can
modify.
The
primordial
is
by
modifying
anything,
that's
on
something.
That's
per
compartment
once
the
primordial
is
a
frozen,
would
either
only
be
modifying
global
variables,
rather
than
modifying
the
primordial
objects,
or
it
would
be
something
that
was
written
with
knowledge
of
compartment
search
sets.
A
D
So
I
just
wanted
to
thread
the
when
you
were
trying
to
reach
on
how
to
describe
a
snapshot
and
I
just
wanted
to
maybe
say
that
it's
what's
not
in
this
spec
is
what
came
to
my
mind
and
the
spec
does
not
talk
about
FS
as
an
I/o
of
modules
from
disk
or
wet
it,
basically
just
talks
of
them
as
being
a
host
supplied
source
text
of
a
particular
key
of
a
particular
location.
Somehow
so
so
I
think
it's.
D
What
not
what's
not
in
this
pack
is
where
a
snapshot
in
my
opinion
could
could
really
relate
to.
At
this
point,
I'm,
not
sure,
if
that's
how
you
know,
you
meant
it
it's
it's
literally
just
these
particular
paths
on
virtual
file
concept
has
not
been
articulated
in
this
pack,
because
the
concept
of
the
file
has
not
and.
A
The
console
file
won't
won't
be
part
of
the
action,
script,
spec
or
accessor
compartments
back,
because
that's
a
host
concept
yeah,
but
the
general
issue
of
how
host
powers
manifest
incest
yeah
without
is
a
cess
issue
for
force
us
to
talk
about
yeah
as
long
as
it's
talking
about
it
in
a
way
that's
neutral
across
hosts
yeah.
D
I
think
it's
gonna
have
to
tread
a
little
bit
deeper
into
the
abstract
not
mentioned
before.
But
it's
it
doesn't
have
say
file,
but
it
kinda
has
to
say
any
host
operations
on
that
location.
So
so
you're
gonna
have
to
I
guess,
add
clarity
that
it's
not
like
anything
can
come
from
any
location
at
any
I'm.
But
what.
D
So,
if
we're
a
snapshot
in
particular
module
map-
and
in
you
know
in
my
understanding
and
I-
was
late,
a
bit
and
I
could
be
completely
off.
But
that
means
that
particular
path
is
basically
sealed,
like
we
don't
call
it
path
in
ACMA
script,
because
that
implies
file
system.
But
we
just
call
it
a
specifier
location
like
that,
like
a
resolved
location
relative
to
a
particular
compartment
which
did
not
exist
when
we
talked
about
module
map
in
you
know,
abstract
sorry
in
more
general
Priya,
realm
spec
language,
so.
A
D
A
A
Yeah
so
I
think
that
the
way
we're
approaching
this
spec
wise,
if
I,
understand
as
first
of
all,
this
solid
distinction
that
we're
making
that's
holding
up
well
between
compartment
and
the
importer
that
plugs
into
the
compartment
and
I.
Don't
remember:
we've
changed
the
name
of
it
so
many
times
they
don't
remember.
A
This
were
still
calling
it
the
importer,
but
the
thing
that
plugs
into
the
to
the
to
the
import
hooks
that
you
give
it
a
modular
location,
I'm
starting
you
give
it
a
there's,
not
a
modulation,
give
it
a
full
specifier
and
it
gives
you
back
a
module
of
static
record
and
how
it
does
that
is
up
to
it
and
there
it
doesn't.
There
isn't
necessarily
any
file
system,
abstraction
from
which
one
can
build
such
an
import.
A
D
Yeah
and
about
lockdown
I,
just
for
a
second
everyone,
we
said
you
would
prepare
your
realm
and
lock
it
down.
So
so
with
that,
would
that
basically
say
and
if
you're
in
a
browser-
and
you
want
to
you-
know-
have
another
shim
or
a
polyfill
or
whatever
make
sure
you
load
those
before
you
start
loading
your
application,
not
after,
and
then
this
way
they
would
basically
traverse
into
the
realm.
A
Yeah
one
of
the
things
that
I
want
us
to
be
sure
to
explain
very
very
clearly
is
the
division
between
what
you
do
before
lockdown
versus
what
you
can
do
after
lockdown,
such
that
all
untrusted
code
should
only
ever
run
after
lockdown
and
analogy
that
is
appealing
to
me.
But
I,
don't
know
if
it
appeals
to
anybody
else
is
just
thinking
about
like
a
read
hell,
storing
her
or
in
an
puttering
around
his
shop
before
he
opens
the
door
and
he
might
have
the
cash
register
open
in
the
walk
they
might
have
money
lying
around.
A
A
So
I
see
lockdown
as
kind
of
that
transition
we're
familiar
with
that
transition.
Other
areas
of
software
engineering,
like
a
UNIX
single
user
mode.
You
do
thinks
in
single
you,
the
everything
you're
doing
in
single
user
mode,
you're
doing
this
route
and
you're
doing
it
in
order
to
prepare
to
go
into
multiple
user
mode.
Multi-User
mode
is
is
when
you
start
admitting
things
you
don't
fully
trust
I.
Think.
C
Run
a
grocery
store
once
upon
a
time
that
metaphor
mostly
works
the
the
main
issue.
There's
there
aren't
actually
that
many
things
that
fall
into
that
category
of
untrusted
were
potentially
risky
exposure
or
opportunity
things.
Well,
though,
it's
certainly
very
true.
The
other
thought
that
occurred
to
me
was.
C
B
C
B
Everyone
I
want
to
walk
a
little
bit
back.
The
metaphors
are
fantastic.
I
think
that
there
are
I
think
that
what
we
are
setting
ourselves
up
with
for
with
the
separation
of
lockdown
and
compartment
is
we
want
to
enable
two
sensible
scenarios,
one
of
which
is
where
an
application
creates
compartments
and
never
locks
down,
and
those
compartments
need
to
be
able
to
behave
in
an
unlock
down
way.
We
also
want
to
see.
B
We
also
want
to
realize
a
system
where
you
have
you
call
lockdown,
be
you
as
you
set
up
your
world,
you
call
lockdown
and
then
you
create
compartments
and
those
compartments
need
to
exist
in
a
in
a
in
a
lockdown
environment,
but
because,
because
we
have
a
cross
product
of
compartment
and
lockdown
bits,
I
think
that
the
question
that
I
have
for
this
group
is:
what
do
we
do
in
the
cases
that
we
don't
intentionally
reveal?
And
that
is
the
case
where
you
have
compartments
that
are
constructed
before
and
after
lockdown
so
Oh.
B
A
After
compartments
are
created
before
lockdown,
we
walked
on
itself
remains
enabled,
and
then
after
lockdown,
you
can
now
still
create
more
compartments
and
I'm
still
not
yet
separating
two
aspects
of
lockdown,
which
we
should
separate
one
is
all
of
the
repairs
so
that
the
primordial
objects
themselves.
Apart
from
there
they're
frozen
this
or
malleability
have
good
Oh
cap
security
properties
and
then
the
vs.
A
A
So
I
would
so
if
we
separate
them,
then
we
have
potentially
three
phases.
We
have
compartments
used
in
normal
JavaScript
compartments
used
in
repaired,
JavaScript
and
compartments
used
in
prepared
and
repaired
and
locked
down
JavaScript,
and
what
I
would
like
to
examine
is
that
the
safety
on
the
other
side
of
the
repair
transition
and
the
safety
on
the
other
side
of
the
lockdown
transition
is
a
realm
wide
safety
and
therefore
grandfathers
in
any
needed
safety
properties
into
the
already
created
compartments
that
were
created
before
that
transition.
A
E
A
E
A
E
So
one
of
the
requests
at
TC
39
was
for
us
to
go
back
and
evaluate
how
we
could
avoid
reentrant
C
into
JavaScript
itself,
exposing
the
ability
to
call
JavaScript
in
these
locations,
and
it
turns
out
that
the
way
they
are
set
up
a
lot
of
these
shared
primordial
x'
are
not
done
on
a
call
site,
location
basis.
In
fact,
the
engines
only
v8
allows
the
theoretical
possibility
of
having
two
realms
and
spec
terms
to
be
in
two
different
locales
and
time
zones.
E
We
need
a
location
separate
from
the
compartment
that
covers
all
compartments
at
once,
all
related
compartments
at
once,
such
that,
if
you
assign
a
time
zone
or
a
locale,
all
the
compartments
are
updated,
and
my
initial
thoughts,
I
haven't
heard
back
from
Mozilla
on
this-
is
that
it
would
have
to
live
on
something
that
looks
reminiscent
at
least
of
the
realms
proposal.
It's.
B
A
Value
for
the
timezone
and
locale,
or
potentially
a
set
of
the
location
for
the
time
zone
in
locale
if
it
needs
to
be
changed
dynamically
for
compartment
lists,
but
let's
examine
the
first
one
first,
so
it
just
becomes.
When
you
create
a
compartment,
you
can
say
what
the
time
zone
and
locale
is
and
then
that
times,
then
that
compartment
is
stuck
in
that
time
zone,
but
it
doesn't
affect
any
other
compartments.
That's
that's!
That
would
be
yes
on
scoping,
no
wandering
entrance'.
So.
E
Yes,
I
started
taking
a
look
at
this.
This
comes
down
to
a
bit
about
how
primordial
propagate
through
execution
contexts.
So
if
you
perform
a
look
up
whenever
you
call
an
intrinsic
function,
that
gets
access
to
these
values
and
it
has
to
look
it
up
on
its
execution
context
to
get
the
compartment
it
is
currently
running
in
that
seems
difficult
and
I
am
NOT.
Yeah.
A
A
A
E
A
A
A
Somehow
stocks
are
about
a
realm
wide
primordial
set
and
Bradley
is
point
just
now,
because
it
included
the
two
locale
string.
Behavior
I
think
is
compelling
to
say
that
those
host
hooks
are
scoped
to
the
realm
and
then,
for
example,
the
the
scheduling
decisions
about
which
job
comes
next,
those
are
scoped
to
the
agent
because
the
various
job
cubes,
like
the
promise
job
queue
these
those
those
go
between
realms
and
between
compartments,
they're,
an
agent
wide
thing,
so
those
would
could
only
be
virtualized
at
the
agent
scope
now.
E
The
nodes
agree:
this
feedback
does
absolutely
agree
with
some
things
we're
hearing
from
implementation
about
we,
we
do
need
to
make
a
little
bit
more
clarity
and
in
this,
so
we
should
likely
call
out
what
the
scope
of
virtualization
is
on
each
proposal.
As
we
talk
about
them.
Yeah
four
compartments,
like
I,
said
it
like
Mark,
said
it's
roughly.
The
compartment
hooks
relate
to
execution
context
right
and
so
in
particular,
we
need
to
document
how
they
propagate
through
execution
context.
E
A
E
A
Yeah,
so
here's
the
thing
that
I,
that
was
the
agreement
and
previous
meeting
with
kriti,
that
I
think
we
will
need
to
revisit,
which
was
that
even
the
host
hooks
that
are
logically
scoped
to
the
realm
that
the
API
for
providing
those
host
hooks
were
still
to
be
provided
by
the
compartment,
API
and
I.
Think
there's
another
way
to
cut
that
which
fits
the
motivation
for
that
agreement,
which
is
that
the
current
realm
proposal
proceeds
without
those
host
hooks
and
it's
a
later
proposal
that
adds
the
realm
scoped
host
hooks
to
the
realm
API.
A
And
it
might
very
well
be
the
compartment
proposal
that
does
that,
but
which
proposal
does
it
is
not
necessarily
tied
one
to
one
to
what
API
those
proposed
operations
go
on
and
I.
Think
kriti
was
really
motivated
to
try
to
keep
them
out
of
the
realm
proposal
to
unburden
the
number
of
controversies
that
had
to
be
simultaneously
settled
for
the
round
proposal
to
go
forward.
A
E
Think
that's
perfectly
fine.
I
know.
Godaddy
is
interested
in
particularly
locale
and
time
zone
for
some
of
our
rendering,
so
we
definitely
should
eventually
move
forward
with
it.
We
have
an
open
issue
on
compartments,
describing
a
need
to
clarify
execution
context.
Propagation
most
discussions
have
been
light
and
back-channel
so
far,
and
hopefully
that'll
change
as
we
get
more
space
between
the
tc39
meeting
in
the
next.
E
A
E
A
E
A
Okay,
so
yeah,
so
that
so
so
the
time,
the
current
time,
the
date
dot
now
issue
and
the
math.random
issue.
This
is
actually
a
good
one
for
examining
the
issue
the
cavern
started
with,
which
is
the
distinction
between
the
world
of
compartments
in
normal
JavaScript
and
the
world
of
compartments
incest
and
how
we
can
have
them
smoothly
coexist
for
cess.
A
A
A
A
Prototype
property
points
that
the
shared
date
prototype,
but
the
all
of,
but
whenever
you,
whenever,
another
compartment
is
created,
but
it's
always
created
by
default
with
its
binding
of
the
global
date
property
for
its
global
bound
to
the
safe
they
constructor,
so
that,
if
so,
that
it's
up
to
the
code
and
start
compartment
in
creating
a
new
compartment
whether
to
provide
the
date
constructor
that
it
has
the
powerful
date
constructor.
It
can
easily
provide
that
as
an
endowment
if
it
wishes,
in
which
case
the
compartment
that
gets
created
also
gets
the
powerful
date
constructor.
A
E
Okay,
I'd
agree
with
that.
I
think
we
need
to
will
likely
get
pushback
if
we
ever
try
to
expose
those
direct
hooks.
Though,
and
particularly
there
has
been
previous
feedback
about
the
viability
of
removing
all
random
locations
from
host
API,
which
is
something
the
web
was
stating
they
thought
would
be
infeasible
as
well
as
time.
I'm.
Sorry.
E
A
So
what
so?
The
thing
that
I
just
explained
with
regard
to
date,
I
would
also
do
for
math
dot
random
it's
simpler
because
there
is
no
a
math
dot
prototype,
but
basically
there's
a
shared,
safe,
math
object
that
has
no
random
property.
This
is
under
stuff
and
new
compartments
get
the
safe
math
as
their
global
binding
by
default.
The
star
compartment
has
the
fully
powered
math
object
and
it
can
endow
it
forward,
but
if
it
doesn't
then
doubt
it
forward,
then
the
other
compartment
just
gets
safe,
math,
not
math,
not
math
with
random.
A
B
I
think
that
you
clarified
something
from
the
implementation.
For
me,
that's
very
useful
in
that.
It's
that
the
repair
functionality
that
we
can
layer,
this
API
in
terms
of
repairs,
first
and
then
compartment
and
then
lockdown,
because
compartment
does
depend
on
repair,
even
though
it's
not
repairing
the
content
to
start
it,
even
though
you
don't
use
repair
to
on
the
start,
compartment
is
that
Chris.
A
B
B
A
Constructor,
there's
one
day
construct
with
her
realm.
It's
on
the
global,
the
global
that
will
be
the
global
of
the
start,
compartment
and
the
dot
constructor
property
on
the
date.
The
shared
a
prototype
points
at
that
powerful
date
global.
So
there
still,
even
if
compartments,
have
been
created,
there's
still
this
distinct
preparer
that
can't
simply
be
implied
by
the
existence
of
compartments,
which
is
to
have
the
powerful
date
constructor
beyond
the
global
of
the
star
compartment.
Mm-Hmm.
E
B
My
under
impression
from
hearing
what
you're
saying
Bradley
is
that
there
are
implementation
there
are.
There
are
issues
with
the
implementation
factoring
on
everything,
but
v8,
presumably
where
there
isn't
an
opportunity
to
have
a
different
time
zone
in
a
different
in
different
compartments,
because
all
of
these
are
just
passing
through
to
an
underlying
system
host
level
time
zone
library.
Presumably
it
is
that,
does
that.
Does
that
reflect
what
you're
trying
to
tell
us
so.
E
This
is
a
bit
interesting.
Most
of
them.
Don't
actually
do
sis
calls
directly
into
the
OS.
They
are
doing
a
variety
of
things.
In
particular,
it
appears
at
a
glance
that
they
don't
let
you
swap
time
zones
while
a
realm
is
alive
because
they
are
caching
values
and
it
is
very
expensive
to
blow
that
away.
V8
does
allow
you
to
do
that
destruction
of
the
cache
and
it
has
the
ability
for
multiple
caches
which
the
others
do
not
readily
have.
I.
A
So
I
want
to
make
it
make
sure
that
we're
not
confusing
two
things.
The
with
timezone
and
locale
I
think
Bradley's
argument
that
that
needs
to
be
a
realm
scoped
hook
rather
than
the
Department
scoped
is
compelling
like,
except
that
the
issue
that
I
was
raising
with
regard
to
the
safe
and
unsafe
date.
Constructors
was
with
regard
to
time,
not
with
regard
to
time
zone.
One
cow.
B
Concretely,
what
you're,
proposing
what
you,
what
mark
and
Brad
will
you
appear
to
agree,
is
that
we
can
remove
the
hooks
from
the
compartment
of
the
partner,
specifically
the
time
hook
from
the
compartment
proposal
and
still
have
the
cess
features
that
we
need,
because
we
can
inject
an
alternate
date.
Correct.
A
B
A
A
Have
the
same
status
and
the
same
danger
as
the
start
compartment
and
the
so
you're
still
in
a
Oh
cap
system
after
repair,
even
start
compartment
is,
but
the
start
compartment
has
a
bunch
of
powers
that
are
denied
to
safe
compartments
by
default.
If
you've
made
other
compartments
before
repair,
then
those
other
compartments,
for
example,
they
also
get
a
date
global
that
points
that
the
very
same
date
constructor
object
as
the
one
that
start
compartment
point
set.
A
What
repair
then
does
is
it
creates
the
a
new
object
which
is
the
safe
date
constructor.
It
changes
the
shared
date
prototype
so
that
it's
not
constructive
property
points
at
the
safe
date.
It
updates
it
stable.
It's.
You
know
the
internal
table
inside
the
compartment
implementation.
It
updates
that
table
of
what
are
the
global,
the
default
Global's
to
put
on
the
global
object
of
a
new
compartment.
You
know
that
the
the
the
ACMA
script
standard
safe
Global's.
B
Okay,
so
the
idea
is
in
general
that
compartments
created
before
repair
are
different
in
behavior,
from
compartments
created
after
and
since
we
don't
ik
and
since
that
is
a
scenario
which
we
that
isn't
in
the
sensible
that
we
either
put
compartments
before
or
after
then
we're
not
going
to
worry
too
much
about
how
they
mix.
Does
that
sound,
sensible.
A
Yeah,
it's
a
little
bit
more,
it's
a
little
bit
stronger
than
that,
which
is
it's
not
that
they're
not
safe.
It's
that
they
have
the
same
status
as
the
start.
Compartment
mm-hmm,
which
is
there
they're
still
constrained
to
play
by
oh
cap
rules,
but
they've
already
gotten
powers
which
they
keep
I
find.
E
B
Yeah
yeah
creating
a
compartment,
is
analogous
to
for
effectively
that
you
inherit
the
UUID,
my
love,
the
not
the
UUID
that
you
want
ideas,
the
the
owner
of
the
process
and
and
and
then
after
you
de-escalate,
you
inherit
the
the
new
owner
of
the
process.
That
makes
sense
by
metaphor
sure
I
love
it
and
thanks
mark,
I
think
that
you've
clarified
for
me
how
to
how
to
refactor
it
to,
of
course,
I'll
have
many
more
questions
now.
A
A
A
One
is
that
we
want
to
unburden
the
realm
proposal
itself,
so
that
it
can
face
as
few
controversies
as
needed
to
go
forward
by
postponing
all
of
those
host
hook.
Issues
and
I
think
the
way
we
can
deal
with,
that
is
to
say
that
the
realm
proposal
doesn't
carry
those
host
hooks,
but
a
later
proposal
may
be
the
compartment
proposal.
F
So
one
of
the
reason
we
make
the
decision
was
also
the
fact
that
is
easy
to
teach
people
that
the
hooks
are
in
a
compartment.
And
if
you
want
to
control
what
a
wrong
will
do
in
terms
of
hose
interaction,
you
create
a
compartment
for
it
and
then
you
go
and
create
realms
out
of
it
because
it's
easier
to
teach.
Otherwise,
you
have
to
teach
that
some
of
these
folks
will
go
here.
Some
of
these
hooks
will
go
there
and
then
more
difficult
for
people
to
understand
that
so.
F
F
Now
welcome
back
right.
It
was
an
important
important
point
there
about
why
we
move
it
into
ou
the
fact
that
mass
of
these
operations
that
we
talked
about
there
are
not
operations
that
are
carry
on
when
you
need
the
value.
There
are
operations
that
are
carry
on
when
you
construct
around
the
case
of
the
locale.
F
A
A
That's
in
the
French
locale.
The
fact
that
the
new
realm
is
in
the
French
floral
is
not
confusing.
The
fact
that
the
compartment
that
I
created
I
used
French
locale
as
an
option
to
the
compartment
constructor
and
the
compartment
that
it
made
is
not
in
the
French
locale
I.
Think
that's
going
to
create
a
lot
confusion
than
whatever
confusion
were
worried
about.
E
A
Okay,
so,
whether
that's
done
by
changing
an
observed
location
or
it's
done
by
a
callback-
we
can
worry
about
what
the
specific
API
is.
But
right
now,
I
want
to
stay
focused
on
the
scope,
we're
also
you
know.
The
different
host
hooks
are
associated
logically
with
different
scopes
and
the
scheduling
your
control
of
job
scheduling
has
to
be
associated
with
an
agent
API,
and
if
the
agent
API
follows
the
same
pattern,
there
will
be
an
agent
constructor
that
makes
a
new
agent
it'll
have
an
options
bag
on
which
you
provide
a
hook
for
scheduling.
A
A
E
Maybe
I
can
share
screen
for
a
second
I
need
some
clarity.
F
A
I'm
being
neutral
with
regard
to
whether
you're
providing
value,
whether
you're
providing
a
set
of
a
location
or
whether
you're
providing
a
callback
hook
in
all
cases,
it
would
be
a
and
options
in
an
option
bag
and
and
it
would
be
an
option-
an
option
bag
provided
to
some
constructor
by
the
by
the
previous
agreement.
It
would
be
an
option
in
an
option
bag
provided
to
the
compartment
constructor,
but
it
doesn't
apply
to
that
compartment.
A
It
only
applies
to
the
realm
constructor,
that's
created
as
part
of
creating
that
compartment
in
the
proposal
that
I'm
making
now
it
would
be
in
the
options
bag
provided
in
very
much
the
same
way,
with
a
with
a
suggestively,
similar
shape
of
the
API,
but
it'll
be
in
the
options
bag
to
the
realm
constructor,
rather
than
the
options
bag
to
the
compartment.
Constructor.
A
Yes,
it
goes
up
to
the
previous,
but
now
the
previous,
what
it
would
actually
be
the
previous
realm,
because
the
only
previous
would
still
be
a
realm
wide
setting,
not
a
compartment
wide
setting,
and
if
we
do
it
this
way,
then
it
does.
Then,
when
you
create
a
new
co-parent,
the
the
creating
of
the
new
compartment
doesn't
have
to
create
a
new
realm
constructor.
The
realm
constructor,
like
you,
know
the
the
rednecks
constructor
or
anything
else,
that's
safe.
The
rom
constructor
can
just
be
a
shared,
primordial
constructor.
That.
F
A
F
Right,
that's
that's
the
problem
that
I'm
trying
to
explain
like
in
order
for
me
to
create
a
system
that
contains
that
that
allow
me
to
create
multiple,
realms
I
have
to
create
intermediate
realm.
That
does
nothing
other
than
providing
that
default.
Behavior
in
the
previous
schema.
You
just
need
a
compartment
live
way,
compartment
that
defines
the
hook
for
returning
the
the
appropriate
locale
in
this
case
French,
and
then
you
can
create
as
many
realms
you
want
inside
that
compartment
that
are
all
French.
So.
E
Maybe
we
can
walk
through
this
example
to
kind
of
explain
how
that
simply
isn't
possible.
Given
some
constraints,
we've
been
handed
down
at
EC
39
we're
given
a
constraint
that
we
not
introduce
new
effectively
JavaScript
hook
sites
for
engines
to
instrument
in
particular
JavaScript
engines
do
not
provide
re-entrance
e
during
a
time
zone
or
locale
specific
API
so
currently,
and
they
do
not
want
to
introduced
it.
So
I
call
back
off.
A
E
They
share
the
same
number
dot
prototype
effectively.
Here
is
the
important
thing
I
just
used
number
but
number
dot.
Prototype
is
the
real
thing
that
matters
here
when
you
actually
go
and
have
compartment
a
create,
a
function
that
returns
some
localized
string
and
you
have
compartment
B
call
that
function.
E
We
have
to
define
the
behavior
here
and
there's
if
there's
three
possible
options
that
I've
identified,
they
get
it
from
their
call
site,
meaning
that
this
locale
string
is
indeed
going
to
be
in
English
because
they
look
up
the
locale
from
their
call
site.
This
means
looking
it
up
off
the
execution
context
to
find
the
current
compartment
therein.
E
E
That
would
be
very,
not
good
and
then
the
third
is
compartments
are
not
the
right
layer
for
this.
Basically,
because
they
share
the
same
prototype,
the
same
two
locale
string.
They
they
cannot
actually
have
any
variation
except
based
upon
the
call
site,
and
so
this
somewhat
matches
some
clarification
points
that
yulia
was
trying
to
ask
for
about
what
is
the
exact
scoping
difference
of
realms
and
compartments?
So
this
is
trying
to
bring
about
even
if
we
created
a
hook
and
we
convinced
the
engines
that
they
wanted
the
ability
to
call
out
to
javascript.
E
A
So,
first
of
all,
let
me
just
state
the
constraint,
then
I
think
the
sides,
but
I
think
this
qualifies
most
of
the
choices
that
are
written
down
here.
The
constraint
that
is
followed
absolutely
in
the
language
is
that
the
behavior
of
a
function-
I'm,
sorry,
it's
absolutely
a
language
ignoring
sloppy
code-
is
that
the
behavior
of
a
function
never
depends
on
the
execution
context
from
which
it
is
called.
It
never
depends
on
the
caller
that
all
of
these
context
issues
are
structural
they're.
All
they
all
fall
all
those
sort
of
the
the
lexical
scoping.
A
F
I
mean
the
I,
don't
have
any
issue
with
I
mean
I
assure
the
same
concerned.
That
marks
you
mentioned.
The
hook
in
the
compartment
is
not
for
the
code
is
not
in
this
particular
case
for
the
locale,
it's
not
worth
the
to
local
string
to
hit
it
does
not
hit
the
hook.
The
hook
is
only
going
to
be
hit
it
when
we
create
a
new
realm
that
needs
that
information
in
order
to
building
transics
right.
A
So
my
problem
is
that
okay,
so
first
of
all
to
get
the
real
currency
issue
off
the
table,
let's
assume,
let's
just
assume,
that
the
locale
and
timezone
is
provided
as
a
static
value
and
I
understand
that
there's
this
web
requirement
to
be
able
to
change
it
dynamically.
Let's
just
ignore
that
for
the
moment.
So
it's
so
there's
some
options:
bag
on
some
constructor
somewhere.
A
Where
you
can
say
you
know,
look
Hal,
:
quote
French,
unquote
or,
however,
you
say
it,
and
that
creates
a
new
something
that
knows
about
the
French
locale
and
then
the
problem
with
that
being
in
the
options
bag
for
the
constructor
is
it
does
not
apply
to
the
community
to
the
I'm,
sorry
to
the
compartment
constructor.
The
options
back
to
the
compartment
destructor
is
that
the
compartment
constructor
creates
a
compartment
and
that
compared
meant
is
in
the
realm.
A
You
know
that
is
in
the
realm
that
the
compartment
constructor
itself
is
from
and
therefore
it
is
not
in
the
French
locale.
It
is,
let's
say
in
the
English
locale
and
that
the
effect
of
providing
the
option
was
only
indirect
by
requiring
that
each
new
compartment
get
a
new
realm
constructor,
as
well
as
a
new
compartment
destructor
only
for
the
purpose
of
enabling
the
realm
specific
hooks
to
be
provided
indirectly
to
the
compartment.
A
A
F
And
if
you,
if
you,
if
you
want
I,
can
give
you
a
concrete
example
when
that
is
needed.
Okay,
so
I,
don't
know.
If
this
example
is
representative
I
haven't
tested,
but
I
have
an
application
whose
whose
settings
are
defined
as
a
French
and
I
create
a
same
domain
iframes
on
that
and
what
will
be
the
behavior
of
the
iframe
that
you
create
and
I
I,
don't
know
what?
What
level
of
propagation
we
have
there,
but
we
can
find
out.
Okay,.
A
D
D
Created
a
function
called
realm,
hi
say
call
the
original,
I
or
I
call.
You
defaults,
the
French
realm
as
a
new
function,
I
called
the
original
round
constructor,
with
the
same
arguments
that
I'm
given
except
I,
override
the
default
to
be
French,
go
Cal
to
be
French
I,
provide
that
realm
new
realm
with
French
realm,
with
French
constructor
as
an
endowment
to
a
compartment
that
it
becomes
the
realm
constructor
and
then
I
use
it
there.
Okay.
E
Somewhat
similar
to
what
we
were
talking
about
with
math
dot,
random
and
date,
except
instead
of
replacing
the
constructor
for
the
purposes
of
censorship,
we're
doing
it
to
change
a
default
value.
Well,
we're
talking
about
within
the
compartment
API.
We
do
have
this
endowments
option
and
within
endowments
you
could
provide
a
wrapping
of
your
realms
global
realm
constructor
and
that
wrapper,
although
not
referentially,
equal
to
all
the
compartments,
can
change
the
options
bag
on
your
realm
to
have
French
within
it.
That.
A
B
F
F
A
F
B
F
What
we're
saying,
if
you
create
a
compartment-
and
you
can
do
something
in
that
compartment-
I-
guarantees
that
the
default
behavior
from
that
point
on
it's
all
French
by
default.
I'm
content
with
that.
But
in
this
particular
case,
is
not
because
if
you
create
another
compartment
inside
from
that
point
on
is
not
endow
anymore.
E
A
Expectation
is
that
is,
endowments
are
assumed
to
be
powerful
and
therefore
they're
only
passed
forward
explicitly
that,
in
the
absence
of
explicitly
passing
them
forward,
what
you
get
is
a
safe
compartment.
Now,
in
this
case,
it's
not
a
question
of
safety
because
there's
nothing
less
safe
about
being
French
than
being
English.
A
C
D
D
A
Yeah
so
so
our
assumption
has
been
that
we've
been
thinking
in
terms
of
what
we
mean
by
power.
Is
the
Oh
cap
notion
of
power,
as
in
the
ability
to
cause
effects
and
locale?
It's
certainly
not
that,
but
under
that
notion
of
power,
the
assumption
has
been
that
the
default
compartment
in
the
absence
of
providing
an
explicit
endowments
is
that
it's
a
is
that
it's
powerless
that
all
the
powers
have
to
be
provided
explicitly.
E
D
I
think
I
had
a
question
also
that
is
treading
on
that.
So
we're
saying
a
compartment
will
have
a
virtual
realm
constructor
or
you
know,
like
a
proxy
somehow
constructor
overwhelm.
Does
that
mean
that
the
trickle
down
restrictions
on
that
compartment
can
suddenly
be
circumvented
by
having
more
closer
to
the
realm
access
to
whatever
constructs
the
realm?
Because
if
a
realm
can
still
inherit,
you
know
on
a
more
global
level,
not
just
in
doubt,
then
then
I
think
if
you
leak
some
things
that
don't
pass
through
the
the
same
distortions.
D
A
Compartments
are
mostly
they're,
just
nested
directly
under
their
realm
there's
only
one
way
in
which
there's
only
currently
there's
only
one
way
in
which
they're
nested
directly
within
each
other.
According
to
the
creation
tree,
which
is
the
module
map,
module
map,
is
specifically
a
mapping
from
try
named
apparent
name
and
that
maps,
and
then
the
parents
module
map
maps
from
its
names
to
its
to
the
grandparent.
A
D
So
the
environments
object,
since
you
know
we
get
to
deploy
that
it
could
be
used
to
imperative
ly
mimic
the
idea
that
you're
taking
Global's
and
you're
restricting
them
and
then
you're
passing
them
down.
So
you
wrap
your
Global's
and
you're,
starting
to
you,
know,
put
put
constraints
on
them
and
you're
creating
compartments
that
are
logically,
not
in
you
know,
nested
but
functionally.
D
They
are
because
that's
how
you've
constructed
them
now,
if
that
one
of
those
compartments
can
now
create
a
realm,
then
that
trickle
down
that
you've,
programmatically
enforced
on
the
compartment
could
technically
be
circumvented
by
running
code
in
that
realm.
That
would
not
have
you
know
the
same
restrictions
on
endowment
and
I.
Don't
I'm
not
sure
that
or
at
that
I'm
thinking,
it's
a
different
kinds
of
dinner
endowment.
So
we're
trying
to
talk
about
its
the
concept
of
restrictions
or
defaults
or
something
then
we
want.
D
A
F
F
F
F
A
How
to
add
realm
scoped
hooks
to
the
spec
and
that,
whether
that's
done
by
options
to
the
compartment
or
it's
done
by
options
to
the
round
constructor
is
to
be
determined.
But
it
is
not
the
case
that
the
round
constructor
proposal
goes
forward
in
a
way
that
locks
in
an
assumption
that
later
proposals
cannot
add
options
to
the
realm
constructor
options
by.
E
A
B
A
D
F
D
C
A
E
E
Personally,
do
not
have
the
strong
opinion,
but
they
must
be
separate
if
they
have
separate
behavior.
So,
let's
be
separated.
You
have
the
ability
to
configure
a
realm
constructor
within
your
compartment,
yeah
an
option
to
the
compartment
API.
That
means
you
need
a
new
realm
constructor
within
that
compartment
anywhere
yeah.
D
A
A
A
The
thing
is,
it's:
it's,
it's
yet
another
thing
to
explain
right
now.
The
the
things
that
are
on
it
that
are
on
a
created
per
compartment
by
default
is
the
function.
Constructor,
the
eval
function,
the
date
object,
the
math
object
and
the
compartment
constructor
itself,
and
the
compartment
constructor
itself
is
because
of
this,
a
multi-level
mapping
of
the
important
problem
so
and.
A
Yes,
it's
each
one
is,
is
expensive,
it's
expensive,
just
in
terms
of
being
another
thing
to
explain
so
I
would
I'm
sorry,
I'm,
sorry,
I'm,
sorry,
this
wrong.
The
only
ones
that
are
created
by
default,
created
by
default
on
a
per
compartment
basis,
is
function,
constructor,
eval
function
and
compartment
constructor
the
date
and
math
thing
is
only
a
distinction
of
the
start.
Compartment
versus
other
compartments
they're
not
created
on
a
prairie
compartment
basis.
So
it's
really
only
three
right
now
and
four
is
a
lot
more
than
three.
E
So
my
key
takeaway
isn't
actually
the
three
to
four:
it's
the
we.
We
have
a
desire
for
these
Taming
of
math
and
date.
Potentially
temporal
coming
up,
it
seems
like
adding
a
very
specific
hook
might
not
be
the
right
approach.
These
are.
This
is
somewhat
a
symptom,
we're
starting
to
see,
as
the
number
of
cases
expands
and
so
having
a
specific
call
out
to
customize.
The
realm
constructor
without
having
call-outs
to
any
of
the
other
ones,
is
something
that
doesn't
seem
like
we've
properly
described
the
problem
so
isn't.
F
E
I
would
argue
no
because
the
key
takeaway
of
everything
is
that
things
within
a
compartment
are
being
hooked
on
an
execution
context
basis,
and
when
you
create
an
evaluator,
you
do
actually
create
an
execution
context
within
the
compartment
and
when
you
create
a
realm
you're
creating
an
execution
context
not
within
the
compartment
itself,
but
a
separate
one
well
with
the
ability
to
create
execution
context
outside
not
you're,
not
actually
creating
a
single
execution
context.
With
the
notion
of
this
direction.
D
D
D
D
D
F
I
know
what
probably
mention
about
the
change
language,
locale
I,
don't
think
I
just
want
to
clarify
that
I.
Don't
thing
is
what
Marx
thinks
it
is.
So
this
is
an
event
that
is
happening
at
the
window
level
in
browsers
that
triggers
when
the
user
changes
the
settings
I
do
not
think
that
he
has
any
material
effect
on
the
realm
itself.
Having
tested
the
spec
doesn't
say
anything
about
that,
but
I
do
not
think
he
changed
it
round
in
there.
No.
F
E
A
C
A
I'm,
a
C++,
probably
second,
only
to
the
details
to
do
to,
to
which
I
know
JavaScript
and
Java.
It's
probably
the
language
in
which
I've
had
the
third
greatest
expertise
as
well
and
probably
second
most
in
terms
of
total
hours.
Programming
and
I
would
like
to
never
read
another
line
of
C++
for
the
rest
of
my
life.
B
F
B
I'm
have
is
that
we
want
to
fully
separate
the
load
and
execute
phases
of
the
module
system
and
the
most
compelling
reason
I
can
think
of
for
wanting
to
do
this
and
for
the
reason
why
I
did
it
in
previous
module.
Loader
implementations
was
so
that
the
same
system
could
be
used
to
load
the
transitive
dependencies
of
a
particular
program
without
executing
any
of
it
as
a
preface
to
building
a
bundle
and.
B
To
that
end,
I
think
that
we
will
need
to
add
some
features
to
the
compartment
proposal.
I'm
not
exactly
sure
what
they
are
yet.
But
one
of
them
is
that
I
think
that
we
will
want
to
be
able
to
thread
a
linkage
record
through
the
module
map
instead
of
instead
of
the
instead
of
a
module
instance,
so
that
we
can
defer
execution
and
then
and
then
consequently
have
some
way
of
getting
linkage
records
out
of
a
compartment.
So
they
can
be
threaded
through
to
depend
the
compartments
that
depend
upon
them.
Go
ahead
and
mark
so.
A
B
So
that
is
where
we
left
off
from
our
previous
conversation
for
sure.
The
question,
then,
is
suppose
that
you
have
suppose
that
you
have
after
load
what
you
have
is
a
graph
of
linked
module
locations.
Two
linkage
records
internal
to
one
compartment
right
and
each
compartment
has
its
own
graph
of
module
location.
Two
linkage
record
because
they
don't
necessarily
keys,
are
refer
to
different
values
in
each
of
in
each
of
those
compartments.
B
So
the
question
becomes
how
to.
Since
we
have
deferred
execution,
how
do
we
then,
how
that
went?
How
do
we
then
actually
link
all
of
these
namespaces
and
begin
execution,
and
an
execution
is
dependent
on
the
compartment
from
which
the
linkage
record
was
created
right
because
we
have
to
thread
the
compartment
evaluate
for
each
individual
linkage
record.
E
I
think
this
is
a
very
long
discussion
that
we
don't
have
time
for
in
this
meeting.
You
could
set
up
a
rough
outline
of
what
you
want
to
do.
It
sounds
very
similar
to
actually
what
we've
talked
about
previously
with
the
ability
to
set
up
import.
Now.
Look
where
you
you
can
roughly
pre
initialize
some
data,
including
the
full
linkage,
is
being
set
up,
and
necessarily
we
might
just
need
to
tweak
our
api's
around
that
yeah
I.
Don't
know
we
actually
need
to
separate
out
the
two
phases
we
already
have.
E
E
B
A
E
E
B
Just
to
double
check
that
this
is
also
related
to
another
issue
that
I
need
to
address.
With
the
implementation
we
have
in
place.
We
need
to
have
a
resolve
function
that
is
purely
logical
and
usable
from
any
node
style.
Namespace,
specifically,
that's
like
the
the
the
shim
we
have
right
now
has
a
make
rooted,
resolve
or
make
rooted,
resolver
function
which
takes
a
location
as
a
root
as
an
argument
which
we
need
to
take
out,
because
we
need
to
separate
the
concern
of
having
a
root.
B
Location
like
resolve
should
be
purely
logical
from
the
names
from
the
full
specifying
namespace
of
a
particular
component,
and
anything
dealing
with
locations
must
be
a
product
of
the
locate
function
and
the
good
the
the
the
nice
thing
about
this
is
that
nodes,
specifically
nodes
resolution
and
semantics
require
us
to
have.
It
is
possible
to
write
one
all
function
that
behaves
that
is
sufficient
for
every
come
every
node
style
compartment
that
just
does
logical
resolution
and
separates
relative
relative.
Full
specifiers
from
apartment,
relative
specifiers
from
full
specifies
I'm,
not
exactly
right.
B
I,
don't
know
if
I've
got
the
notation
exactly
the
terminology
exactly
right,
but
if
you
have,
if
you
have
a
specifier
that
starts
with
dot
dot
dot
as
its
past
component.
The
resolution
of
any
of
the
resolution
of
from
any
of
those
specifiers
must
result
also
in
another
specifier
that
begins
with
dot
dot
in
order
to
distinguish
the
internal
from
external
namespaces
and
node.
B
So
I
need
to
write
that
at
some
point
in
probably,
and
then
the
next
week
in
or
in
order
to
do
a
faithful
emulation
of
node
semantics.
So
it's
a
slightly
different
result
function
than
the
one
we
have
SPECT
right
now,
but
with
which
I
say
mostly
because
I
think
that
it's
important
for
us
to
it
to
clearly
differentiate
what
resolve
and
locate
are
going
to
do
for
us,
because
locate
is
going
to
be
compartment
specific
but
resolved
while
being
huggable
is
going
to
almost
always
be
the
same
function.
A
The
resolve
is
to
go
from
refer
relative
specifiers
to
two
full
specifiers,
which
are
still
only
meaningful
regarding
the
compartment,
but
but
at
least
refer
independent,
and
it's
really
just
about
things
like
lee,
slash,
algebra
and
resolving
all
those
things.
Yes,
then,
there's
a
separate
mechanism
to
go
from
full
specifiers
to
module
locations
where
module
locations
are
really
for
retrieving.
B
Yeah
but
Bradley
I
think
that
you
were
trying
to
make
a
point
that
we
don't
yet
have
a
mechanism
for
exposing
a
compartments,
internal
resolver,
locate
abilities
which
might
need
to
be
used
from
outside
of
the
compartment.
In
order
to
do
linkage,
I'm
I'm,
not
exactly
I,
don't
have
a
precise
idea
of
what
that
needs
to
be,
but
but
I
gear
go
in.
E
E
The
node
has
a
default
resolver
if
you
perform
a
loader
hook
on
it,
so
you
have
now
changed
the
behavior
of
result.
You
still
often
almost
always
want
to
have
the
ability
to
perform
the
more
powerful
hook,
the
original
one
before
adding
a
loader
hook
in
order
to
resolve
to
certain
api's.
That
is
what
I'm
saying
you
will
most
likely
need
to
do
in
order
to
do
this.
Iger
graph
creation.
E
Okay,
Chris
also,
can
you
just
go
and
clarify
the
terms
that
you
were
using
on
the
compartments
proposal?
We
might
need
to
rename
hooks
because
it
seems
like
me
using
different
terms.
E
Proposal
compartments
readme
on
the
bottom.
There
is
in
compartment,
constructor
options.
Mm-Hmm
there
is
an
import
hook,
which
returns
effectively
a
promise
from
any
full
specifier,
and
the
promise
result
is
a
static
module
record
which
can
be
used
to
create
a
new
module
record,
a
new
module
instance.
My.