►
From YouTube: SES Meeting: Realms strategy
Description
Leo Balter discusses options to present to TC-39 the following week toward asking for Stage 3 advancement.
B
But
we
discussed
the
the
idea
that
that's
been
previously
discussed
in
this
call
about
having
moving
from
a
model
of
module,
fragments
identified
with
strings
that
would
be,
you
know,
url
fragments
they
would
instead
be
with
lexically
scoped
variables,
which
would
be
special
if
declared
that
would
be
available
a
bit
earlier.
You
know
with
static
semantics
around
them
identifying
which
they
are
so
this
would
be
a
correspondence
between
this
subset
of
lexically
scoped
variables
and
the
the
the
variables
that
are
likely
scoped
and
available
at
runtime.
B
So
it's
issue
number
five
on
the
the
repository
and
there
are
notes
taken
from
the
from
the
incubator
call
given
the
the
time
sensitivity
of
the
realms
topic.
I'd
rather
not
give
a
self-contained
presentation
of
this
today
yeah,
I
don't.
I
don't
have
great
slides
written,
and
I
want
to
suggest
that
we
that
we
shift
more
discussion
of
this
to
a
future
ses
call,
okay
or
or
a
future
call
that's
dedicated
to
this
particular
topic.
B
D
D
D
D
D
D
D
D
E
D
D
And
therefore
shu
is
through
the
repo
in
an
issue.
Triad
is
proposing
to
extend
the
module
map
to
have
a
separate
instantiation
of
the
same
module
source
against
the
the
matching
realms
global.
But
that
means
reusing
the
same
module
map
that
we
have
in
the
page
realm,
but
having
separate
instantiation
of
each
module
for
each
realm.
F
I
have
a
pretty
clear
understanding
of
what
this
is
so
similar
to
how
they
added
a
two-tiered
cache
system
for
import
assertions.
It
looks
like
they
want
to
do
the
same
thing
except
on
the
realm
level,
so
adding
another
tier
or
component
key
to
the
lookup
and
then
when
it
doesn't
exist,
you
instantiate
a
new
one.
F
So,
basically,
within
your
module
map,
you're
going
to
have
a
unique
location
for
any
given
thing,
it's
going
to
be
pointing
to
some
kind
of
source,
and
then
it's
up
to
you
to
point
at
that
location
properly,
using
your
hooks
so
in
direction
of
a
kind.
And
then,
when
you
have
that
location
point
to
by
your
loading
hook,
it
instantiated
it
instantiates
it
off
the
same
host
underlying
backing
storage
of
that
source.
F
So
for
node,
for
to
be
a
more
concrete
example,
we
read
files
off
disk.
Let's
say
we
had
a
set
of
two
realms.
You
have
a
backing
storage
of
a
not
fully
populated
file,
yet
it's
still
reading.
Maybe
it's
big.
They
both
point
at
that
storage
and
it
is
up
to
that
storage
completion
to
provide
the
source
text
for
both
load
operations.
F
E
E
It
was
always
the
goal
that
a
module
intense
is
internship
or
close
over
there.
The
global
object
of
the
realm
was
always
the
intent
was
never
different
from
that.
It's
just
that
when
it
comes
to
the
web,
they
have
all
these
different
complexities
that
has
to
be
solved,
and
so
that
that's
one
suggestion
like
highlight
that
this
is
a
problem
that
does
not
concern
tc39
at
all.
E
It
will
not
be
in
the
spec
by
any
means,
it's
just
going
to
be
the
implementation
of
of
this
for
the
web,
so
everyone
is
tuning
into
that
and
then
the
the
fact
that
he's
proposing
this
solution
that
introduces
other
kind
of
problems.
It's
fine.
We
can.
We
can
look
at
those
problems,
but
this
is
fine
to
me
that
this
is
now
different
from
what
we
were
proposing.
Initially,
I
don't
remember
what
danielle
did
in
the
integration,
but
I
don't
suspect
that
is
very
different
from
this.
B
I
could
speak
to
that
a
little
bit.
I
I
is
brett,
go
ahead,
so,
as
bradley
was
saying
dominic,
I
guess
is
proposing
that
it'd
be
from
the
same
fetch,
whereas
with
when
you,
when
you
import
the
same
module
multiple
routes,
whereas
for
import
assertions,
dominic
specifically
insisted
that
the
html
assertion
can
use
multiple
fetches.
B
I
have
quite
a
hard
time
understanding
the
motivation
for
this
and
I
think
in
practice,
there's
no
observable
difference.
I
say
in
practice
because
in
theory
these
multiple
fetches
could
occur,
but
in
practice
browsers
will
probably
cache
the
the
results
in
their
internal
in-memory
http
cache
and
not
make
a
second
request,
even
if
they,
even
in
the
import
assertions
case,.
B
B
The
difference
here
is
also
not
going
to
come
up
in
practice.
The
the
changes
are
according
to
dominic,
not
just
editorial,
because
they
theoretically
change
the
number
of
fetches
in
some
cases
so
in
in.
I
think
it
mostly
amounts
to
sort
of
a
transposed
representation
where,
instead
of
having
it
be
that
you
have
the
module
map
hanging
off
the
realm,
which
is
simpler,
you
have
this
more
complex
representation
of
this.
C
C
E
And
that's
why
I
wanted
to
be
clear
in
the
slide
that
it's
not
about
e39-
and
I
know
also
maybe
adding
to
this
slide,
who
is
defining
the
constraint
and
who
is
proposing
the
solution
in
this
case
chrome
team
through
shu,
so
we
should
have
it
there.
So
it's
not
we're
not
introducing
and
constraining
the
champion
group
we're
just
saying
this
is
what
they
are
saying.
We
we
can
align
with
that
with
this
constraint.
D
E
D
Around
no,
it
wasn't
no
sorry,
I
I'm
sorry
to
interrupt.
We
have
a
concern
that
relates
to
this
in
the
next
slides,
I'm
going
to
show
the
code
that
brings
a
problem
here.
This
code
here
today
is
working
fine,
but
we
have
an
illustration
going
next.
There
is
actually
the
next
constraint
over
this,
because
first
we
have
one
constraint
that
works
for
us
that
totally
works
for
us,
but
we
have
the
same.
D
D
This
is
what
is
saying
today
and
reflects
the
multiple
module
graph
already
exposing
on
iframes.
I
just
wrote
some
examples
in
in
iframes
showing
the
iframes
do
have
like
separate
global.
We
cannot
observe
like
utilization
of
evaluated
modules
in
iframes,
like
for
for
another
brown,
for
what
this
proposed
separation
means.
D
Yes,
we
still
use
a
single
module
map,
because
the
network
and
parse
syntax
cache
of
this
map
is
going
to
be
reused
from
the
parent
realms
child
realms
can
read
from
it
and
it
extends
the
module
map
to
create
separate
instantiations
of
the
module
source
from
the
respect
of
that
respective
realm.
That
is
important.
Importing
the
module
okay,
but.
C
D
I
can
just
remove
the
problem
with
iframes.
We
I
can
I
even
not
trying
to
to
go
deep
in
the
iframes
problem.
I'm
just
saying,
like
I'm
using
these
iframes
context,
saying
like
this
is
already
reality
of
the
web.
The
iframes
like,
even
if
we
say
something
is
tied
to
this,
is
the
reality
of
the
web.
Today
we
already
have
the
different
module
map
with
iframes.
D
D
D
F
D
D
D
B
D
C
F
C
B
Constraint
was
really
an
editorial
constraint
and
the
second
constraint
is
just
you
know:
if
if
the
child
realm
can
do
network
fetches,
these
things
will
be
cached
in
a
common
network.
Cache
nobody's
proposing
cash
partitioning
between
the
two
realms
mechanisms
for
for
fetching
the
contents
of
the
modules,
so
the
whole
timing
attack
concern
no
matter
what
we
decided
any
of
these
levels.
B
D
Know
it
makes
no
sense,
but
let
me
tell
you
one
thing
sure,
and
the
chrome
team
wants
this
discussion
to
be
resolved.
My
goal
is
for
to
come
to
the
stage
three
up
to
the
tc29
meetings
requesting
for
stage
three
with
this
discussion
resolved
in
a
path
that
we
provide
like
what
that
we
suggest,
and
we
need
to
consider
this,
even
if
it
looks
like
something
that
we
don't
believe.
Well,
I
have
a
different
technical.
E
We
always
thought
about
these
a
different
layer
of
control
at
the
component
level,
where
you
can
control
what
can
be
loaded.
What
cannot
be
loaded,
how
it
be
loaded
and
data
data,
so
we
always
thought
about
this
as
a
layering
issue,
rather
than
providing
that
level
of
control
at
the
realm
level,
and
just
do
it
at
a
compartment
level
where
you
can
do
all
all
sort
of
virtualization
on
the
module
graph,
so
it
was
never.
E
It
would
never
intend
to
be
in
the
realm,
but
this
this
idea
of
controlling
what
do
you
load
has
always
been
in
the
back
of
our
heads
in
terms
of
compartments
and
other
things,
and
mark
probably
can
assert
that.
So
this
is
not
new
for
me.
I
I
see
two
ways
of
pushing
back
on
this.
One
way
is
it
belong
to
a
different
layer.
You
might
want
to
do
that
a
different
level.
E
Maybe
we
can
use
very
similar
thing
to
what
we
do
with
assertions
where
you
can
say,
import
assertions
will
have
a
a
list
of
things
that
can
be
loaded.
Okay,
I
don't
know
thinking
right
now,
but
or
could
be
a
api
that
allows
you
virtualizing
the
the
module
graph
and
and
so
on
so
pushing
back,
and
this
does
not
belong
to
the
round.
The
realm
is
just
for
the
global.
We
focus
on
the
global
and
the
intrinsics.
It's
a
new
set
of
global
new
set
of
intrinsic
new
monument
and
whatever
happens
from
there.
B
Then
I
don't
think
I
don't
think
this
line
of
argument
will
be
very
effective
because
you're
saying
we
have
these
other
goals,
we
really
want
those
other
goals
to
happen.
They
will
require
this
other
stuff
to
happen
and
dabbing
is
saying
yeah
you
have
these
other
goals.
This
proposal
doesn't
achieve
them,
so
you
know
what
are
we
doing
and
that's
a
valid
argument
and
I
think
the
only
way
through
is
to
say
actually
we
don't
need
that
other
stuff
to
happen.
B
B
Is
this
actually
what
we
want
to
be
shipping
on
the
web?
That
that
would
be
the
question.
So
I
think
if
I
you
know
this
feels
like
an
effort
where
it's
like
saying,
because
you've
articulated
these
broader
goals.
You
can't
have
this
simpler
version.
It
seems
like
that's.
The
purpose
of
raising
this
particular
concern.
E
Yeah,
I
want
to
make
sure
that,
because
well,
you
mentioned
what
daniel
mentioned
that
this
is
a
thing.
That's
not
real!
That's
not
useful
yada
yada.
We
wanted
to
make
sure
that
we
agree
that
this
is
a
thing
that
we
have
looked
at
in
the
past
and
it's
something
that
we
would
like
to
have
control
in
the
future.
B
E
G
Charity
there
there's
there,
I
don't
think,
there's
any
dispute
about
this
group
and
the
efforts
that
have
been
put
forth
on
on
trying
to
make
secure
and
isolated
and
changing
environments
through
a
variety
of
means.
What
were
what
you
you're?
The
argument
that
you
were
making-
and
I
know
you
said
throughout
the
argument
it
doesn't
matter.
G
I
totally
agree
with
you,
I'm
not
one
of
the
folks
that
thinks
that,
like
disjoint
module
map
is
a
problem,
I
honestly
think
that
the
realms
every
channel
realm
should
have
its
own
module
map
full
stop.
I
don't
know
why
that's
a
problem,
but
that
being
one
of
shu's
requirements
makes
it
completely
at
odds
with
dominic's
requirement.
That's
right.
G
G
Not
a
real
thing,
because
you
can't
have
both
of
those
things.
You
can
absolutely
do
what
dominic
wants
to
do.
If,
if
we
can
have
destroy
module
graphs,
you
know,
but
anyway,
I
just
want
to
say,
like
I
agree
with
you,
but
we
need
to
make
sure
that
we
call
out
that
specific
detail
when,
when
bringing
our
arguments
daily,
they
can't
just
have
both
of
those
things,
or
else
we
get
a
useless
realms,
become
useless
after
that
yeah.
I.
B
Important
how
we,
how
we
frame
this
you
know,
we've
we've
made
these
advances
about
talking
about
isolation
rather
than
security,
and
that
was
really
important
to
to
getting
this
acceptable,
and
this
is
another
one
of
those
things
and
so,
if
you,
if
you
talk
about
how
you
want
this
thing
later,
but
you
don't
mention
how
you
believe
you
can
already
completely
achieve
it
in
user
space,
that's
gonna!
You
know
that
that
second
part
is
a
part
that
most
people
will
not
have
the
context
of
without
using.
A
F
E
It's
not
only
that
it
could
be
other
problems
like
some
sort
of
timing
issue,
because
the
rom
is
loading
a
module.
Now
the
pattern
might
get
some
weird
behavior
there,
because
it's
expecting
some
timing
to
be
different
or
something
like
that,
but
it
all
boils
down
to
who
populates
the
the
the
source
cash.
F
G
That
is
at
odds
with
another
concern
that
they
have
right,
they're
saying
we
don't
want
it
to
mutate.
We
don't
want
a
child
to
mutate.
The
parent
they're
also
saying
we
don't
want
to
have
separate
modulographs,
but
but
like
what
they're.
What
that
leaves
us
with
is
that
a
parent
needs
to
know
every
module
that
the
child
might
ever
possibly
want
want
to
load
and
preload
it
for
them
to
allow
the
child
so
that
there's
no,
so
that
there's
a
the
shared
module
graph,
doesn't
it
doesn't
get
tainted
or
whatever,
because.
F
G
F
You
have
to
create
a
globally
referenceable
instance
in
these
global
module
maps
on
the
web,
so
you
actually
have
to
create
basically
a
component
key
based
upon
the
absolute
url,
the
assertions
in
place
and
the
realm
if
it's
a
single
module
map
doing
so,
if
you're
preventing
mutation
of
the
module
map,
it
doesn't
make
sense,
because
when
you
instantiate
a
new
module
in
a
realm,
it
has
a
new
realm
id.
So
it
also
gets
inserted
into
that
module
map
regardless.
F
E
E
C
Yeah,
I
I
have
one
one
question
I'd
like
to
insert.
It
seems
to
me
that
the
the
overall
shape
of
this
discussion
is
there's
a
controversy
about
web
integration.
Let's
just
say,
between
positions,
a
b
and
c
doesn't
matter
what
those
positions
are.
None
of
the
choices
would
affect
the
contents
of
the
tc39
spec
tc39
does
not
have
jurisdiction
on
deciding
a
web
integration
controversy
between
a
b
and
c
and
the
web
folk
are
insisting
that
tc39
resolve
the
controversy.
D
D
D
This
one
would
actually
fail,
because
this
page
realm
is
not
important.
The
module
file-
and
this
would
like
this
side
effect,
is
something
that
I
I
think
it's
a
big
compromise
for
me
like
this
is
not
my.
This
is
my
main,
my
page
realm,
failing
because
I'm
trying
to
import
a
module
inside
the
realm,
but
this
import
is
being
rejected
because
by
only
the
fact
that
module
was
not
imported,
we
have
some
solutions.
We
have
some.
We
have
some
things
that
were
proposed
and.
D
But
one
of
the
things
that
the
the
word
proposed
here
as
like
shu
brought
in
this
idea,
and
it's
like
we
could
actually
one
of
the
things
that
we
try.
I
have
five
options.
I
have
five
alternatives
and
I
want
to
minimize
them
like
one
of
the
things
that
I
want
to
make
sure
here
in
the
sas
meeting,
that
we
have
less
options
to
present
to
c39.
D
D
D
This
is
something
that
dominic
is
proposing,
so
he
wants
the
nomination,
but
he
would
be
okay.
If
the
realm
construction
constructor
would
have
a
like
new
realm
and
give
an
argument
with
an
opt-in
like
with
an
object
saying
like
a
low
mutation
of
the
module
map,
true
with
value
2.,
I
I
think
that's
weak,
because
I
see
like
a
massive
use
case
of
realms
just
go
in
for
this
opt-in
and
like
hey,
use
this
up
team,
if
you're
using
realms,
because
it
makes
no
sense
to
have
this
sort
of
problem
in
your
code.
D
If
you're,
gonna,
import
modules,
option
c
is
basically
a
graceful
known.
Caching
module
map
module
loaded.
This
is
weird.
This
is
weak,
but
it's
actually
like
if
the
child
rounds
tries
to
find
a
page
module
map,
a
cached,
a
cache
for
network
and
syntax.
If
they
were
not
there,
they
still
fast
fetch
powers
and
makes
everything
work,
but
does
not
cache
anything,
but
that
does
not
mutate
the
the
page
module
map.
This
is
one
of
the
options
that
is
a
bit
weird.
D
I
so
talking
through
this
with
jordan,
just
to
make
sure,
like
he's,
also
like
in
the
loop
of
this
jordan
support.
Jordan
also
suggested
having
the
option
d
extended.
With
this
thing.
This
is
just
like
having
a
option.
E
means
the
same
thing
that
I
said
on
option
d,
but
actually
adding
an
option
to
the
constructor
to
this
low
mutation.
D
D
D
In
the
first
box,
I
have
my
actual
program:
loading
importing
the
module
first
in
the
page
realm
and
then
in
the
chat
realm
that
doesn't
create
a
problem
that
doesn't
create
an
error,
but
then
in
the
second
box
I
just
change
the
position
of
the
lines,
and
then
I
have
a
type
error.
This
is
for
me.
This
is
like
a
big
compromise
that
I
don't
want
to
in
my
code.
D
And
we
also
have
race
conditions.
If
I
just
have
these
two
promises
here,
I
might
have.
I
might
have
my
my
code
like
being
dependent
of
what
the
host
does
first
like
if
the
host
like
I
cannot
tell
here
in
the
promises
by
the
time
they
look.
If
the
net
network
is
going
to
be
cached,
if
the
syntax
is
going
to
be
parsed.
D
Is
that,
like
this
is
a
low
mutation,
because
I
think
these
sort
of
problems
need
to
be
well
specified
by
users
or
like
hey?
I
want
to
have
this
race
condition
here,
and
so
I
want
to
have,
because
if
I
want
to
have
no
mutation,
if
I
want
to
block
mutation,
I
need
to
be
aware
this
race
condition
might
happen,
because
this
promise,
all
here
might
work
on
just
my
omar-
might
not
work.
D
E
I
think
that's
that
that's
the
the
the
argument
that
we
should
make
like
the
failing
at
any
given
time
is
not
really
an
option,
because
it
makes
this
problem
to
be
a
real
problem
for
developers
yeah.
I
think
we
should
have
that
up
front
when
they,
when,
when
the
proposed
solution
is
described
from
dominic,
we
could.
We
should
jump
into
this
one
directly
saying
that
seems
like
a
pretty
bad
thing
to
happen.
D
Yeah
yeah,
the
idea
was
to
present
the
options
here
to
this
discussion,
but
I'm
actually
presenting
the
slides
after
the
discussion
and
the
idea
was
to
present
the
options
here
for,
as
I
said
at
the
beginning,
I
want
to
reduce
these
options
into
things
that
we
like
in
the
paths
that
we
want
to
go.
I
wanted
to
consume
with
this
group
like
if
option
a
because
that's
choose
a
suggestion.
Like
can
we
go
with
the
enumeration?
D
E
I
made
them
it's
my
opinion
that
enumeration
is
going
to
be
a
lot
more
difficult,
because
you
have
the
issue
with
the
blocks:
it's
basically
what
happened
with
csp
that
they
keep
adding
things
to
csp
in
order
to
allow
new
things.
What
about
blocks?
What
about
all
the
other
forms
of
modules
that
you
allow
that
it's
kind
of
you
need
to
expand
that
configuration
to
have
a
lot
more
flexibility
for
the
web
that
do
not
apply
to
other
environments.
E
So
having
enumeration
seems
like
a
pretty
bad
thing
for
tg39,
because
if
you
have
enumeration,
it
means
that
it's
api.
It
means
that
goes
into
into
tc39.
For
for
the
definition
of
that
configuration.
So
for
those
reasons
I
believe
option
option
a
is
not
really
an
option.
Another
thing
that
my
recommendation
is
that
don't
come
to
the
committee
with
multiple
options
expecting
the
committee
to
decide
come
to
the
committee
with
the
option
and
the
other
consider
options
in
case.
You
want
to
go
into
the
details
of
that.
D
Just
yes,
and
let
me
tell
you
one
thing
again:
yeah
the
idea
is
this
is
to
come
to
the
tc39,
with
with
the
option.
Although
shu
and
dominic
suggest
me
option
a
and
b,
and
I
want
to
give
them
to
say
then
no,
but
with
an
informed
decision
that
is
actually
like
what
the
feedback
that
you're
providing
me
yeah,
similar
to
what
we're
doing
in
the.
E
E
It
might
be
that
we
also
have
an
option
in
the
future
to
allow
access
to
the
other
global
object
could
be
that
as
a
option
that
we
decide
basically
not
wrapping
the
the
callables
anymore,
just
giving
you
access
direct
access
to
the
thing,
because
there's
a
camp
of
people
asking
for
that.
Another
camp
asking
for
not
intertwine,
object,
graph,
different
use
cases,
care
or
not
care
about
that
particular
topic.
E
D
Well,
it's
it's
ironic
because,
from
my
point
of
view,
from
my
perspective,
people
ask
like
w3c
tech
review
and
it
feels
some
way
people
want
to
take
reveal
to
actually
say
this
cross
realm
object.
Asses
to
say
that
to
detect
to
say
this
axis
object,
access
would
be
a
bad
thing,
but
it
would
turn
out
to
be
the
opposite
and
then
now
they
want
it,
because
they
actually
have
use
cases
like
two
of
the
reviewers,
not
three
of
the
reviewers.
D
C
A
A
lot,
a
lot
of
the
shape
of
this
argument,
looks
like
they're
attempting
to
set
up
a
proof
by
contradiction
where
we
do
the
exploration
or
leo,
where
your
group
does
the
exploration
to
figure
out
where
the
absurdity
lies
and
that
it
feels
like
they're
trying
to
prove
trying
to
exercise
to
to
create
effort
that
reproduces
the
effect
that
we
realize
of
our
own
accord.
That
realms
are
not
feasible.
A
A
But
I
I
also
what
what
daniel
was
saying
about
leading
with
your
conclusion
is
really
important
there,
because
if,
if,
if
the
argument
is
a
conclusion
sandwich,
then
it
isn't
in
bad
faith.
If
you,
if
you
lead
with,
we
think
that
realms
are
infeasible,
because
it
is
impossible
to
create
realms
that
satisfy
both
of
our
requirements.
A
E
Every
time
that
a
dependency
of
view
changes,
so
you
have
to
do
build
time,
compilation
of
those
things.
So
when
you
do
roll
ups-
and
you
do
things
like
that,
you
just
don't
have
a
way
to
really
define
what
are
the
things
that
you're
allowing
to
import.
This
is
that
makes
it
not
not
really
feasible.
A
Yeah
that
also
reduces
to
the
absurd,
as
you
say,
it's,
that
the
point
of
a
module
system
is
to
be
flexible,
against
changes
to
your
transitive
dependencies
and
and
to
not
have
that
flexibility
is
equivalent
to
having
a
build
step
that
reduces
your
entire
transitive
working
set
to
a
simple
file
and
just
owling.
It
yep.