►
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
Alright,
well,
let's,
let's
do
this
I
have
an
agenda
on
one
of
these,
so
does
anybody
have
any
topics
that
they
wish
to
bring
up
for
this
meeting?
A
Can
I
can
give
a
summary
on
that
one,
and
then
an
issue
that
it
would
be
great
to
discuss
with
this
group
of
folks
would
be
whether
whether
we
can
or
should
introduce
a
new
method
to
the
compartment
API
that
gives
us
the
module
name.
Space
object
for
the
module
exports.
Namespace
object
for
a
particular
specified
module
before
having
imported
it.
A
C
A
As
indeed
and
soaking
soaking
is
the
right
word:
yeah,
okay,
so
the
first
one
is
the
specification
of
a
global
global
lexical.
Z'
I
think
that
what
we
would
like
to
do
is
add
an
option
to
the
options
bag
for
the
compartment
constructor.
That
allows
us
to
introduce
global
lexical
that
are
not
fields
of
the
global
scope,
and
the
reasoning
behind
this
is
that
there
are
certain
motivating
cases
like
instrumentation
like
go.
C
A
Right,
yeah
yeah,
so
the
to
clarify
what
we
have
so
far
is
that
the
compartments
or
the
compartments
constructor
accepts
an
endowment
object.
The
endowments
object
contains
properties
that
are
copied
onto
the
global.
This
object
as
part
of
the
construction
of
the
compartment,
and
this
is
not
sufficient
for
certain
motivating
cases
like
instrumentation
and
metering,
because
those
need
to
be
able
to
introduce
certain
functions
or
objects
into
the
low
global
lexical
scope
that
are
not
just
that
are
not
discoverable
or
enumerable
on
the
global.
A
This
in
that
compartment,
and
the
reason
for
this
is
that
these
features
have
two
parts,
one
of
which
is
a
transform
which
rewrites
the
code
so
that,
based
off
of
aesthetic
analysis,
they
can
verify
or
prevent
the
that
contained
the
compartmentalised
code
from
accessing
certain
variables
that
are
in
the
lexical
scope
and
then
the
other
part
of
that
is
that
they
also
need
those
things
to
be
in
a
lexical
scope
and
all,
and
definitely
not
on
the
global.
This,
because
if
it
were
on
the
global
at
this,
they
could
defeat
the
they
could
defeat.
D
I
ask
that
question
because
it
would
be
helpful.
Can
we
point
to
one
or
two
examples
available
like
today
that
that,
basically,
you
know
if
you
refer
to
test
as
a
has
a
lexically
available
function
in
your
yeah?
So
is
that
never
sorry
is
that
traditionally
or
is
it
just
in
certain
frameworks,
or
you
know,
testing
libraries
that
they
don't
in
tree?
They
don't
add
it
to
the
global
this
yeah.
D
A
A
E
A
Every
expression
is
expanded
to
have
two
parts,
one
of
which
is
to
increment
a
coverage
counter
for
that
particular
part
of
the
code
and
then
to
do
the
thing
that
was
originally
written
in
the
source
is
like
parenthesized,
comma
expressions,
and
what
this
allows
you
to
do
is
without
modifying
any
of
your
sources.
You
can
measure
the
coverage
of
particular
lines
and
expressions
inside
of
your
code
and
then
do
like
cyclomatic
complexity,
analysis
and
things
like
that.
A
D
D
It
is
counterintuitive
to
say
that
we
created
a
module
system,
let's
bring
stuff
and
and
and
in
ways
we
did
it
before
the
module
system
and
let's
take
modules
and
make
them
know
modules.
And
then,
let's
tell
people
that,
okay,
you
know
I
use,
stores,
math
mojo,
and
then
this
is
where
the
coverage
was,
and
this
is
I
I,
really
believe
that
we
encourage
legacy
and
legacy
if
it
doesn't
stay
up
to
date
with
features
of
the
language
it
creates,
like,
in
my
opinion,
I'm.
D
B
But
so
so
sorry
to
interrupt,
because
so
so
there
had
been
I
sent
a
link
to
the
issue,
the
you're
talking
about
the
use
case,
one
of
the
use
cases,
but
there
are
many
other
use
cases
for
controlling
the
contour.
That's
the
name
that
we
use
sometimes
in
PG
39-foot.
For
this
thing,
and
it's
not
only
that
kind
of
use
cases
in
general,
it
is
a
there
is
a
desire
to
control
the
contour
for
certain
things
that
you
want
to
do
in
a
compartment
and
and
yeah
I've
been
historically
Dave.
B
Herman
had
some
ideas
around
what
that
API
looked
like
this.
Is
this
Romana?
He
he
sent
it
a
while
back,
that's
probably
four
years
ago,
a
long
time
ago,
but
basically
the
fact
that
sometimes
you
do
want
to
control
the
contour.
Especially
around
directive
are
indirect
eval.
There
are
certain
subtleties
there
that
you
might
want
to
prevent
people
from
accessing
certain
values,
or
even
your
writing
example
that
he
always
used
was
monster
out.
What?
If
we
write
a
new
grammar
for
the
language
you're
trying
to
do
something
new
in
the
language?
D
D
We
need
a
feature
of
the
language
that
allows
us
to
say,
listen,
there's
this
global
property,
but
if
you
call
it
I
can
shatter
this
and
give
it
a
different
behavior
somewhere,
and
you
know
so
definitely
this
kind
of
feature
should
be
part
of
the
language,
and
you
know
the
fact
that
it
about
has
that
magic
is
absolutely
so
so
yeah,
sorry,
sorry
to
tangent
on,
but
but
yeah
like
definitely,
you
know
completely
calm
now.
Thank
you.
C
Right,
that's
going
to
say
tooling,
is,
is
kind
of
the
the
essential
point
here,
which
is
without
the
ability
to
do
this
kind
of
manipulation
to
the
the
global
namespace.
The
something
like
that
code
coverage
thing
that
Chris
was
talking
about
just
isn't
possible
at
all
and
there's
nothing,
since
it's
kind
of
its
very
nature
is
to
violate
the
the
semantics
of
the
module
framework.
C
D
So
in
that
case,
though,
like
III
considered
for
for
tooling
specifically
I
want
to
import
from
bear
specifier
and
be
able
to
take
that
in
the
browser
run
in
a
note,
bear
specifier
has
a
meaning
defined
somewhere
any
module
importing
from
that
bear
specifier.
It
gets
an
instance
of
those
functions
that
it
could
then
say
this
instance
was
given
to
that
module.
That
is
it.
So
that's
an
air
you
I
believe
on
a
module
level
makes
makes
you
know
an
exciting
future
for
writing.
Tests.
I.
D
C
Think
we're
talking
at
cross-purposes
here
part
of
the
the
challenge
that
with
something
like
code
coverage
or
even
more
significantly
metering
is
you.
You
need
to
be
able
to
impose
the
analysis
or
control
mechanism
without
the
the
code,
that's
being
being
analyzed
or
metered,
to
be
able
to
determine
that
this
is
happening
and
to
change
its
behavior
accordingly,
either
to
manipulate
the
the
mechanisms
directly
or
or
to
change
its
behavior
to
give
a
Alti
reading.
E
E
E
F
Right,
yeah
actually
does
this
right
now,
when
you
generate
anonymous
modules,
you
can
see
this
in
browsers.
If
you
put
a
debugger
statement
and
your
repo,
for
example,
the
only
way
that
you
can
prevent
people
from
obtaining
this
is
basically
the
same
thing
that
browsers
and
no
does.
Is
we
don't
let
you
directly
get
a
hold
of
that?
It's
a
similar
idea
here.
F
So
a
similar
idea
is
going
on
here
where
we
have
these
Global's
and
we
want
them
to
truly
not
exist
within
a
way
that
the
code
inside
of
a
realm
or
compartment
is
able
to
access
something
they're
not
supposed
to
be
able
to
get
to.
But
the
idea
is
sound.
What
you're
saying
where,
if
we
put
it
to
a
module
specifier,
we
can
hide
things,
but
even
that
it
just
mirrors
what
we're
talking
about
right
now,.
D
C
Well,
let's
say
you
just
you
want
to
count
the
number
of
times
the
code
does
something,
and
so
you
you
transform
the
code,
do
something
which
will
increment
a
counter
every
time
it
does
whatever
the
something
is
you
want
to
count.
You
want
the
code
itself
not
to
be
able
to
know
the
name
of
that
counter
variable,
because
otherwise
it
could
manipulate
it.
D
Yeah,
but
a
bound
closure
like
like
a
width
with
proxy
statement
inside
wherever
part.
That
means
that
variable
doesn't
even
get
defined
in
the
scope
of
that
code.
It
gets
defined
in
the
width
statement
as
long
as
you
can
pass
the
proxy
to
it
without
making
it
accessible
to
the
code
through
an
eval.
Exactly.
A
D
E
For
me
and
I'm
wondering
if
there's
going
to
be
resistance
to
adding
this
as
a
feature
and
if
there
really
exists
ways
of
achieving
is
whether
it's
through
you
know,
like
you're,
saying
like
wrapping
in
a
closure.
You
know
injecting
injecting
names
like
they
like
require
and
module
are
done
in
commonjs
transformation.
Yeah.
E
If
I
can
bring
up
one
more
and
paste
something
into
the
chat
here,
I
this
well
this.
This
is
an
issue
on
the
JC
on
the
JC
repository
and
it's
talking
about
importing.
This
protects
and
suspects
methods
for
controlling
the
boundary
between
modules
and
there's,
a
and
I'm
just
wondering
if
there's,
perhaps
an
overlap
yeah
in
that
you
know,
this
is
importing
from
a
module,
something
that
you
know
might
be
better
represents
it
as
well
as
a
console
variable
and
just
another
scenario:
yeah.
B
And
doesn't
make
that
we
using
the
same
technique
and
based
on
and
also
what
Chris
was
saying,
the
fact
that
it
is
a
module
and
you
can
do
a
static
analysis
on
what
they
access
from
the
the
the
code
that
they
have
and
importing
things
with
names.
You
know
they
are
not
trying
to
access.
We
are
the
bindings
of
the
module.
B
Then
it
is
easy
to
implement
something
like
this,
where
you
don't
really
care
much
about
then
trying
to
access
it
and
if
they
try
to
use
a
directly
well,
they
do
have
access
to
it
as
the
main
problem
here.
I
have
an
eval
in
line
in
in
line
after
the
Khans
foo
have
an
eval
there
that
access
protect
on
suspect
I
will
be
able
to
access
that.
That's
the
main
situation
and
I.
B
What
Chris
and
chip
were
trying
to
say
that
there
are
fundamental
issues
today
to
achieve
that,
and
but
but
but
the
same,
the
same
applies
to
the
contour
I,
like
you
have
an
eval
there,
the
contour
who
had
the
exact
same
problem.
So
this
solution
is
equivalent
to
control
the
contour.
Why
bring
in
bindings
that
are
specific
as
a
result
of
the
computation
process?
Yeah
agreed
the.
A
Backup
I
brought
up
the
code
coverage
analysis
as
a
sort
of
introductory
example
for
its
understandability.
But
what
we're
trying
to
get
to
is
something
more
like
metering
or
or
related
features,
and
for
those
unguessable
'ti
is,
is
not
sufficient.
It
is
necessary,
but
not
sufficient.
Unforgeable
'ti
is
necessary
for
those
cases
it
shouldn't.
B
B
But
I'm
not
sure
what
I'm
saying
is
I'd,
be
the
example
in
the
screen
right
now.
Well,
in
my
screen
at
least
the
import
protected
suspect
from
Jessie
standard.
That's
the
one
I
look
nice
on
the
child,
the
example
there
were
used
transportation
sources
source
to
bring
a
new
binding,
the
binding
that
you're
bringing
is
not
for
durable.
You
cannot
change
that
in
a
way
that
will
affect
anyone
or
anything,
and
it
is
discoverable.
C
C
B
D
Can
I
throw
a
like
a
wrench
into
this?
The
way
we're
visualizing,
it
is,
let's
say,
I,
make
a
function
called
function.
A
and
I
want
that
to
be
a
privileged
thing
that
only
code
that
I
inject
into
the
source
can
call
it,
but
I'm
actually
running
it
on
a
source
that
calls
their
own
function
a
mm-hmm.
D
Once
once
you
clash
with
a
variable
name
and
the
argument
whether
or
not
you
can
rename
variable
names,
you
can't
people
do
it,
but
you
can't.
You
know
you
can't
safely.
Do
it
unless
you
analyze
so
much
code
and
by
the
end
you're
done
it's
basically
going
to
be
an
issue
that
is
opened
on
your
repo.
After
you
release-
and
it
will
be
patched
somehow
so
if
you're
not
gonna
rename
function
a
and
you
have,
your
own
version
of
function
function
a
that,
nobody
else
should
call,
because
it's
different
well.
Are
you
proposing
that.
A
G
So
I
want
to
jump
in
here
with
how
the
metering
actually
works
right
now
is
we
are
using
we're
using
a
symbol
that
no
sane
person
would
actually
use
it
has
as
they're
with
Joyner,
and
it
has
very
rich
prefix
on
it.
If
we
detect
this
variable
and
in
the
user
source
code,
we
simply
reject
the
source
code.
We
do
not
do
any
rewriting.
We
do
not
try
to
be
fancy
in
that
sense.
E
E
A
H
The
Sun
jumping
in
the
middle
here
trip
dude
did
a
brief
chat
for
me.
So
I
don't
know
if
what
I'm
saying
fits
the
conversation,
but
the
key
thing
about
the
the
JavaScript
global
lexical
scope,
as
opposed
to
the
JavaScript
global
scope,
is
if
a
value
is
bound
to
a
variable
in
the
JavaScript
global
lexical
scope.
H
The
only
way
that
that
that
code
can
access
that
variable
in
order
to
introduce
that
value
into
computation
is
by
mentioning
the
name
of
the
variable
for
the
global
scope,
because
the
global
variable
names
are
alias
to
properties
on
the
calab
jecht,
and
you
can
look
up
properties
of
the
global
object
by
a
computed
name
in
square
brackets.
We
can
that
same
safety.
Property
does
not
exist.
H
B
H
H
B
But
so,
just
to
clarify
word
for
I
mean
my
perception
is
that
we
jump
in
between
what
what
we
want
to
propose
and
how
and
the
current
the
qiime
implementation
how
you
can
achieve
something
today,
similar
to
when
you
try
to
propose
my
out
I
also
mentioned
mark
just
to
get
you
out
to
a
speed
that
in
the
past
we
did
talk
about
controlling
the
controller.
That's
something
that
Dave
Herman
wanted
to
have.
B
We
even
have
an
issue
that
we
closed,
saying
that
the
issue
and
the
run
proposal
should
be
on
the
compartments
and
four
years
ago,
when
we
talked
about
it,
there
were
some
people
who
entertained
the
idea,
and
there
were
some
concerns
about
the
semantics
of
controlling
are
removing,
especially
on
removing
things
from
the
contour
from
the
lexical
scope,
and
we
never
really
got
an
infraction
there,
but
this
is
definitely
something
that
we
want
to
to
to
have
now.
That
being
said,
I
think
we
need
to
be
very,
very
careful.
B
We
want
to
advance
advance
the
common
API.
We
don't
want
to
make
the
same
mistakes
that
decorators
propose
somewhat.
A
proposal
have
fallen
into
it
device
and
we
don't
go
with
something
that
is
simple
enough
and
then
having
a
Avenue
for
adding
more
features
to
it
in
the
future.
We're
going
to
have
a
very
hard
time
getting
this
into
the
language.
That's
just
a
tactical
aspect
of
these
and
the
contour
seems
to
be
something
that
we
could
achieve
today
via
sound
translation
and
some
other
things
that
we
could
do.
I.
B
Imagine
that
if
we
do
translation
source-to-source,
we
bring
a
binding.
The
binding
is
in
the
module
scope,
it's
not
for
chable.
You
cannot
change
it,
but
it's
discoverable.
We
are
directly
valve
and
then
we
can
play
with
the
hooks
that
we
have
for
directive
R
to
disable
access
to
those
by
maybe
I
think
if
we
replace
evolve
with
a
new
function.
That
is
also
directly
well.
We
we
can
add
some
bits
at
the
beginning
saying
this
is
a.
B
There
are
some
lets
and
some
cons
here,
some
constants
at
to
undefined
that
you
would
not
be
able
to
access
from
within
the
code
that
you
are
evaluating.
So
there
are
a
bunch
of
things
that
we
could
do
if
we
do
in
transportation
to
disable
the
discoverability
of
these
bindings.
That
will
get
out
very
far
and
the.
H
Key
the
key
thing
about
what
you
said
is
that
the
bindings
are
in
lexical
scope,
not
global
lexical
scope
by
a
mechanism,
but
from
what
you
said
introduced
a
lexical
scope
by
rewriting.
But
nevertheless
the
key
thing
is
that
they're
in
lexical
scope,
they're
not
in
the
scope,
that's
aliased
to
global
property
names
right.
B
A
B
That
doesn't
preclude
us
from
having
a
discussion
around
it
and
maybe
even
describe
a
potential
solution
that
is
equivalent
in
functionality
like
the
transportation
plus
eval
direct
eval
monkey
patch,
which
should
be
possible
in
the
compartment
API
to
have
all
the
properties
of
what
we
want,
which
is
known
for
the
role,
not
scoreboard,
not
callable.
Three,
and
only
you
can
use
that
thing.
H
H
So
the
so
leaving
out
a
concrete
API
from
the
stage
two
proposal,
but
I'm,
not
okay,
leaving
out
the
clear
statement
that
we
intend
to
include
the
functionality
in
the
proposal
before
stage
three
or
really
in
order
to
go
for
Stage
three.
And
the
reason
is
that
a
major
motivating
stated
motivating
goal
for
compartments
and
a
criteria
to
hold
up
any
compartment.
H
Design
against
is
host
virtualize
ability
and
since
the
global
lexical
scope
is
an
inescapable
part
of
the
host
first,
a
lot
of
its
ability
without
rewrite
with
rewrite
you
can
achieve
anything
by
deterring
crap
and,
as
you
know,
and
it's
the
without
rewrite.
That
was
also
know
the
thing
that
enabled
the
hardware
designers
ages
ago
to
say
precisely
what
it
means
to
have
a
virtual
izybelle
architecture.
H
H
The
static
check
is
that
it
simply
looks
like
a
direct
eval
so
to
a
first
approximation.
The
identify
or
eval
open
paren
arguments
are
just
a
simple
function.
Call
it's
not
quite
so
simple,
because
lexical
variations
like
surrounding
the
name
Val
directly
in
parens,
still
leaves
it
as
the
syntactic
form
of
a
direct
eval,
but
surrounding
it.
For
example,
an
open,
paren,
1,
comma,
even
I'll,
close
paren
means
that
it
no
longer
qualifies
as
directive
a
so
that's
the
static
criteria.
H
H
Then
the
function
is
invoked
as
if,
with
a
normal,
indirect,
valid,
simply
invoked
as
the
function
call
that
it
looks
like
it
is
whatever
was
between
the
parens
just
gets
passed
to
it
as
function
arguments,
so
we
do
need
to
revive
the
is
directive,
a
look,
but
that's
not
adequate
as
you
point
out,
because
that
doesn't
give
us
the
rewrite.
So
there
is
another
part
of
the
proposal
that
I
think
goes.
H
All
the
way
back
to
Dave
Herman,
which
is
any
stray
that
would
have
been
direct
eval,
is
first
handed
to
a
rewrite
hook,
which
gives
it
the
chance
to
rewrite
it,
and
only
then
the
rewritten
string
gets
directly
valid.
Now.
At
that
point
we
have
fallen
off
the
criteria
of
virtualizing
without
rewrite,
but
that
would
allow
at
least
censoring
any
code
that
mentions
this.
These
funny
names.
B
Yes,
so
the.
B
Mas
evade
was
a
spec,
it
was
deleted
from
their
own
proposal,
but
we
can
go
back
in
history
and
see
the
two
hooks
that
we
have
and
the
specification
for
them.
So
we
should
bring
it
up
easily
into
the
compartments
back
and
and
and
the
rewrite
part
of
a
we
never
did
they
rewrite
of
the
source,
but
it
was
definitely
possible
with
the
way
they
hook
stuff
that
we
had
at
some
point.
We
would
look,
we
just
go
ahead
and
do
that
again.
That's
be
easy.
Yeah.
D
Just
just
as
we
were
talking,
I
remembered
the
word
zones
that
way
yeah
but
forget
about
what
what
what
and
who
and
all
of
that
you
know.
Let's
talk.
Practicality,
like
I've
I've
thought
of
of
the
way
you
know
you
would
shim
this
today
is
basically
and
if
he
called
but
like
you
somehow
endow
that
if
he
functioned
and
I
I
think
it
really
should
not
clash
with
the
scope.
So
you're
going
to
be
pre
fixing
any
references
to
those.
D
H
H
H
Yeah
the
reason
I
say
that
the
Reg
X
is
adequate
is
because
Michael
is
proposing
to
combine
two
safeguards.
One
safeguard
is
placing
the
variable
in
the
global
lexical
scope.
The
other
safeguard
is
spelling
it
in
a
way
that
you
really
never
have
to
worry
about
an
innocent,
accidental
collision
even
appearing
in
a
literal
string
or
a
comment,
and
that's
why
we
can
that?
That's
why
rejecting
it
based
on
our
eggs
in
a
full
parse
is
a
reasonable
piece
of
engineering
here,
whereas
the
correct
things
that
we
reject,
reject
with
reg
X
like
HTML
comments.
H
G
G
E
G
H
H
H
H
A
H
H
H
You
anything
fed
to
eval
is
only
evaluated
as
eval
code
and
for
the
TC,
53
and
moddable
use
cases
for
SES.
We
decided
that
we
do
not
need
for
for
SES
used.
Specifically,
we
do
not
need
to
support
evaluating
code
as
global
code
and
for
code
that's
executed
as
eval
code.
If
it's
evaluated
sloppy,
then
a
top-level
consulate
or
class
will
still
populate
the
global
lexical
scope,
but
again
for
the
TC
53
embedded
use
case.
We're
definitely
not
proposing
to
support
sloppy.
On
the
other
hand,
for
the
compartment
proposal.
H
B
B
You
were
saying
that
you
absolutely
see
the
necessity
to
have
these
as
part
of
the
stage
three
ways
to
control
the
the
contour
lexical
scope,
the
global
lexical
scope,
and
then
you
were
talking
also
about
the
possibility
that
they
hooks
for
eval
and
search
time
take
goes
very
far
and
you
can
do
a
lot
of
things
that
you
control
the
direct
evolve.
I
assume
that
you're
talking
now
about
the
Korean
implementation
that
you
could
achieve
by
doing
some
of
these,
but
I'm
still
confused.
No.
B
H
So
in
order
to
virtualize
the
entire
language
or
in
order
to
in
order
to
virtualize,
to
have
fervor
to
full
virtualize
ability
of
interaction
with
the
host,
while
preserving
the
semantics
of
the
language.
I
think
you
we
have
to
do
both,
but
the
shin
doesn't
have
to
do
both
and
you
know
we
don't
need
it
doesn't
have
to
do
either.
H
H
A
H
G
B
B
Compare
me
in
a
companion
that
is
a
lot
more
closer
than
what
we
want
from
the
from
the
language.
Without
sacrifice
sacrifice
you
directly
well
and
a
bunch
of
other
features.
Work
example
is
that
what
we
do
today
for
the
the
the
things
that
we
are
exploring,
we
have
sloppy
strict
mode.
We
have
directive
all
indirect
eval.
We
have
no
issues.
No
issues
are
all
with
any
of
that.
So.
H
So
pretty
this
is
definitely
in
scope
for
these
meetings
and
we
spent
you
know
many
a
lot
of
time
in
these
meetings,
exploring
exactly
that
and
I'm
happy
to
continue
to
do
that,
including
the
question
you're
raising,
but
from
everything
I've
understood
about
it.
So
far
that
the
mere
membrane
mechanism
is
useful
and
I
look
forward
to
exploring
it.
But
it
does
not
seem
to
me
that
it
that
it's
subsumes
the
functionality
of
compartments
or
even
close
I
think
we
still
need
compartments.
I.
Think
I
think
these
are
just
very
different.
B
For
the
current
implementation
of
what
are
you
doing,
I
believe
you
could
get
very
far
too
much.
What
we
are
asking
by
using
the
membrane
is
obviously
we
do
want
the
components
or
the
language
that's
going
to
be
the
full
range
of
features
plus
it
will
be
a
lot
faster
than
doing
a
membrane
near
membrane,
implantation
and
the
saying
that,
as
today,
you
continue
exploring
a
thing
you're
still
using
the
width
with
a
proxy
I.
Guess,
yes,.
A
We
have
some
discussion
amongst
us
at
a
gorrik
about
an
API
for
endowments
to
propagate
to
child
compartments.
This
is
related
to
the
motivation
for
the
first
topic.
We
have
convinced
ourselves
that
the
compartment
API
is.
It
is
sufficient
for
us
to
have
a
compartment
API,
where
the
only
kind
of
endowment
is
the
kind
of
endowment
that
is
not
implicitly
inherited
by
any
child
compartment.
A
H
H
B
H
H
The
so
the
so
first
of
all
after
the
compartment
is
created,
the
Creator
has
access
to
the
global
before
any
code
runs
within
the
compartment.
So
this
mechanism
of
replacing
it
with
a
self-propagating
wrapper
could
certainly
do
removals
as
well
as
additions
with
regard
to
what
the
compartment
api
itself
directly
supports.
G
To
clarify
the
direction
for
this
is
basically
we
want
to
come
up
with
the
library
function
that
could
be
widely
used,
that
we
just
say
here's
the
way
that
I
want
to
transform
my
compartment
construct
lectures
in
the
future,
and
that
could
do
censorship
where
it
could
do
injection
of
variables
or
even
changing
up
some
of
the
defaults
and
stuff
like
that.
So
it
would
be
kind
of
like
a
general
membrane
mechanism,
except
specifically
for
compartments
yeah.
A
F
Are
not
are
part
of
nodes,
loader
hook
API,
you
can
achieve
it
with
what
is
in
the
compartment
API.
It
is
prohibitively
difficult
is
what
we
found
and
nodes
litter
API
that
we
had
to
provide
a
transform.
Unfortunately,
a
lot
of
people
use
in
the
transform
hook
do
a
naive
transform
and
they
get
bugs,
but
that's
somewhat
expected.
Mm-Hmm.
A
A
Yeah,
okay,
the
next
topic
was
I,
have
a
proposal
that
I've
made
on
Bradley's
repository
for
adding
a
module
method
to
the
compartment
API.
That
would
allow
us
to
obtain
a
module
namespace
instance
for
a
module
that
has
not
yet
loaded
such
that
a
library
could
assemble
a
graph
of
compartments
without
executing
any
of
their
modules.
A
F
We
might
get
into
some
oddities
here
between
the
false
pacifier
and
using
the
first-class
module.
Namespace
objects
for
similar
purposes,
at
least
when
I
was
writing.
It
I
was
writing
out
full
specifiers
as
it
means
to
identify
an
exact
module
instance.
There
may
be
mole
more
than
one
full
specifier
that
points
to
a
single
module
instance,
but
there
was
never
more
than
one
module
instance
per
pole
specified
like.
H
These
things
appear
in
the
ranged
part
of
the
module
map,
not
the
domain
part.
The
the
module
map
is
mapping
from
fill
specifiers
to
something
and
the
something
after
we.
We
went
through
rounds
in
this
meeting
and
is
the
is
either
the
parent
full
specifier,
in
which
case
you're
only
using
the
static
information
from
the
parent
and
we
instantiate
it
in
the
current
module
or
a
module.
Namespace
object,
but
you're
still
locally,
naming
that
module
namespace
with
a
local
full
specified.
H
You
should
never
be
absolutely.
You
should
never
be
able
to
add
a
property
to
the
the
module
name.
Space
object
is
already
in
the
spec
read-only,
not
immutable
because
of
live
bindings
but
friendly
object.
You
can
only
read,
you
cannot
modify
a
property
and
certainly
can't
add
new
prior
Bertie's.
Yes,.
F
My
concern
is
you
would,
with
this
and
cycles,
you
can
necessarily
encounter
a
case
where
you're
obtained
in
modules
namespace
before
any
bindings
for
its
exports
have
been
resolved.
Therefore,
you
have
essentially
a
module
namespace
object
that
does
not
have
the
binding
properties
on
it.
Yet
that's.
G
F
It
it's
not
problematic
if
that
is
actually
checked,
but
if
you're
able
to
pass
these
two
different
areas
in
particular
I'm
concerned
with,
if
you
encounter
a
case
where
you
have
two
parallel
graphs,
loading
and
the
unpopulated
module
namespace
is
granted
is
somehow
referenceable
from
the
other
graph.
Then
you
could
see
it.
Yes,.
H
F
A
A
Linking
compartments
by
full
specifier
there,
a
reason
that
that
isn't
sufficient
is
that
full
specifiers
are
not
universally
unique,
that
they
can
be
reused
between
compartments
and
refer
to
different
module
instances
from
different
compartments
and
because
of
that,
I
was
my
first
draft
on
this
idea
was
to
introduce
another
argument
on
the
options
bag
that
is,
that
contains
inter
compartmental
linkage
as
as
tuples
as
two
as
they
call
it.
Aliases,
for
example,
that
contains
tuples
of
compartment
and
full
specifier
in
the
target
compartment.
A
So
it's
a
map
of
the
full,
the
local
full
specifier
to
the
remote
compartment
and
the
remote
full
specifier,
which
achieves
the
same
thing
but
requires
the
addition
of
more
API
and
also
the
sum
a
drawback.
Another
drawback
of
that
approach
is
that
then
there
becomes.
It
introduces
the
possibility
of
a
precedence
issue
between
between
the
module
map
and
the
alias
map.
F
F
I'll
need
to
think
on
this
I
I
think
there
might
be
an
alternative
design.
The
problem,
like
you,
said
about
a
full
specifier
not
being
crossed
compartment
is
interesting
to
me,
because
that
would
just
mean
compartment
needs
to
be
paired
with
full
specifier,
potentially
or
some
other
thing
like
you
were
talking
about,
but
I
need
to
think
on
it,
but
so
far,
if
you
do
not
need
anything
to
run
ahead
of
time,
this
seems
okay.
H
Yeah
there's
another
there's
another
thing
that
came
up
when
we
first
started
examining.
It
was
actually
in
one
of
these
meetings.
First
saw
examined
using
the
module
name.
Space
object
for
this
purpose
is
that
it's
clear
what
use
of
the
module
name
space,
deep,
sorry,
the
module
map,
it's
clear.
What
use
of
the
module
map
involves,
granting
Authority
and
what
authority
it
grants
if
you
use
a
parent
full
specifier
name,
you're,
only
mentioning
the
static
module
to
be
reinstated
from
scratch
in
the
new
compartment.
H
F
F
F
A
So
I
have
I've
implemented
this
in
the
shim
and
the
way
that
we
ended
up
doing
it
was
with
more
trickery,
with
leak
maps
behind
the
scenes
so
well.
The
proposal
I
described
where
the
module
map
was
a
map
of
full
specifiers
to
a
tagged.
Union
is
effectively
what
the
implementation
is
doing
behind
the
scenes.
It's
looking
at
these
tuples
of
compartment
and
Aelita
a
compartment
and
full
specifier.
A
Do
pools
and
the
way
it
obtains
the
duple
for
a
module
namespace
object
is
by
reaching
into
the
week
map
behind
the
scenes,
so
every
every
module
namespace
object,
that's
instantiated
gets
associated
with
its
compartment
and
full
specifier
through
this
week.
Map
and
this
week
map
is
how
the
compartment
constructors
communicate
to
each
other
about
how
to
link
the
cloud.
How
to
interlink.
F
A
Yeah
the
which
has
some
downsides
right,
because
if,
if
you
have
compartments
from
separate
realms
that
do
not
share
or
multiple
instances
of
the
same
gem
button
from
different
realms
they're,
not
going
to
close
over
the
same
week,
map
which
will
mean
that
they
can't
they
don't
recognize
each
other's
module,
name,
space
objects
as
being
valid
links.
A
F
F
C
A
As
I
was
describing
the
tag
union
approach
that
occurred
to
me
that,
while
I
was
implementing
this
and
to
be
clear
mark,
we
already
landed
a
mistake
of
mine.
I've
realized
I'm
at
it
that
I
misinterpreted
the
full
specifier
to
full
specifier
on
module
map
to
mean
an
alias
within
the
app
within
itself
and
did
not
implement
the
reinstate,
create
a
module
from
the
parent
compartment
because
we
don't
have
parent
compartments
yet
in
the
shim
which,
but
but
in
in
my
defense.
A
H
A
Would
have
been
in
the
module
load
phase
where
all
of
the
aliases,
but
it's
fine
I'll,
make
a
note
of
it
and
come
back
and
just
remove
it
until
we
need
to
until
we
can
add
the
feature,
but
but
that
comes
but
the,
but
the
reason
I
bring
it
up
is
because
I
think
it's
a
valid
feature
to
have,
and
we
don't
have
a
means
to
introduce
it,
because
we
would
need
to
be
able
to
distinguish
a
string.
That
means
from
parent
compartment
and
string.
A
That
means
in
same
compartment
and
in
same
compartment,
isn't
expressible
with
the
module
namespace
trick,
because
one
must
have
the
compartment
object
in
order
to
create
it,
which
might
turn
the
which
might
turn
the
course
of
this
conversation,
because
if
we
have
to
revisit
the
API
of
module
map
name
in
order
to
enable
both
of
those
features,
it
might
be
an
opportunity
to
visit
other
design,
design
ideas.
Yeah.
A
And
then
there's
also
the
case
that
we
might
also
want
to
be
able
to
inject
a
host
object
as
a
module,
because
we
also
need
to
have
a
story
for
how
to
and
how
to
introduce
something
like
an
attenuated
file
system.
An
attenuated
version
of
the
note
FS
module
into
a
compartment
and
I.
Don't
think
we
have
a
story
for
that.
Yet
I.
H
Am
confused
on
this?
What
is
the
need,
where
we
decided
that
we're
okay
having
the
import
names
that
the
full
specifier
import
namespace
for
a
compartment
the
compartment
wide,
so
that
individual,
so
that
we're
not
controlling
the
import
namespace
on
a
module
by
module
basis,
we're
only
controlling
it
on
a
compartment
basis.
So
what
is
the
case
that
we're
missing.
A
A
A
H
That
one's
straightforward,
the
the
attenuator,
is
in
a
namespace
where,
when
it
imports
FS,
it
gets
the
more
powerful
FS,
not
necessarily
the
real,
just
a
more
powerful
one
that
it's
attenuating,
because
the
the
this
logic
composes
and
it
itself
produces
a
namespace
by
which
the
name
SF
in
some
other
compartment
is
populated.
So
when
compartment
a
uses,
the
name
efforts,
it's
referring
to
the
module
name,
space,
attenuator,
a
module,
D.
Okay,
when
yeah,
how.
H
A
H
The
start
compartment
is
running
in
the
world
as
it
as
it
exists
without
compartments
and
has
access
you
know
can
can
be
born
or
with
with
all
of
the
access
that
it
would
normally
have.
So,
let's
start
off
by
set
by
hypothesizing.
How
does
the
code
in
this
third
compartment
have
the
power
to
interact
with
the
MOT
with
the
file
system.
H
Okay,
so
the
code
in
the
store
compartment
is
in
a
name
space
where
the
Nate,
where,
if
it
imports
the
name
FS,
it
gets
the
power
to
manipulate
the
file
system.
Therefore
it
can
import
star
as
X
from
FS
and
reify,
that
is
a
module,
namespace
object
and
then
it
can
take
that
module
names
of
the
base,
object
and
use
it
to
set
up
the
module
map
for
compartment.
A
mm-hmm.
H
H
A
The
implication
for
the
shim
code
is
that
the
shim
will
to
be
able
to
take
on
an
arbitrary
real
object
that
it
is
received
in
the
module
map
and
not
recognizing
it
as
a
module
namespace
of
its
own
kind,
because
it's
not
the
same
kind
of
module.
Namespace
of
the
compartment
constructs
be
able
to
treat
that
as
a
module
name,
stay
static
and
then
introduce
two
other
modules
inside
of
the
container
inside
all.
H
A
F
There
are
ways
you
can
try
to
detect.
If
something
is
a
module
object,
are
we
seeking
to
load
that,
or
are
we
just
seeking
to
allow
conversion
from
an
object
into
a
module
namespace?
So
we
added
synthetic
modules
roughly
to
various
parts
of
stuff
when
looking
at
web
assembly,
which
roughly
do
that
they
take
an
object
and
convert
it
into
a
module
namespace.
E
A
Think
that
we
need
to
have
a
facility
for
creating
synthetic
module,
namespaces
specifically
as
well
for
enter
in
if
we're
linking
with
wasm.
In
particular,
question,
though,
then,
is
how
much
of
the
special
the
module
names
base
needs
to
be
expressible
for
for
Azzam.
They,
for
example,
like
does
wasm
need
to
be
able
to
to
propagate
a
live
binding
into
a
into
a
node
interment
into
a
compartment
module
name
space.
A
E
E
Sorry,
this
bears
a
little
bit
to
last
week's
discussion.
We're
talking
about
the
exoticness
of
module,
name,
space
objects
and
as
the
approach
XO
can
macro,
VM
was
just
to
say
a
module
name.
Space
object
is
any
object,
so
there's
not
there's
not
it.
There's
not
really.
A
distinction
between
there's
no
need
to
turn
an
object
into
a
module
name,
space
object.
So
if
you
wanted
to
attenuate
the
FS
module,
for
example,
you
could
you
can
do
that
just
by
a
simple
object.
Object,
transformation
and
the
result
is
an
arm.
E
C
A
In
the
Contin,
this
is
perhaps
particular
to
our
sim
implementation,
but
module
name,
a
module
instances
which
contain
module
namespaces
internally
to
our
sim
have
some
capabilities
that
a
plane
object
would
not
have,
particularly
that
they
can
project
live
bindings
out
into
other
modules
that
import
them,
which
is
necessary
for
our
implementation,
because
a
a
live,
binding
isn't
just
a
shared
memory
slot
between
multiple
modules.
It's
actually
something
where
we
observe
the
mutation
in
the
originating
mod
module
and
then
propagate
it
out
with
the
callback
to
all
of
the
all
of
the
modules
that
import.
A
E
H
H
E
I'm
just
trying
to
understand
this
distinction
for
ahead
of
time,
we're
saying
for
like
binding
in
that
that
you
I
mean
for
any
well
if
a
module,
if,
if
a
module
in
a
compartment
imports,
another
module
and
the
import
Hawk
is
a
dynamic,
it
results
dynamically.
What
that
is,
then
how
how
does
any
ahead
of
time
processing
occurred
or,
for
you
know
determining
what
that
is
and
linking
without
running
any
courage
or
yes,
maybe
I'm
missing
something
yeah.
A
I
follow
you
which,
which
gets
to
the
next
thing
I'm
like
we
asked
for
after
after
this,
which
would
be
a
for
a
compartment
load
method.
So
if
I
were
to
lament
something
like
Sesa
fie,
let's
go
I
mean
browserify
er.
You
know
some
bundler
like
that,
and
let's
call
it
Sesa
fie
for
purposes
of
the
discussion
in
order
to
implement
that
I
would
need
to
either
I
would
need
to
do.
A
One
of
two
things
one
is
I
would
need
to
do
all
of
the
things
that
are
that
the
compartment
does
internally
for
collecting
for
loading
loading
modules
in
the
presence
of
an
import,
hooks,
etc,
etc
or
I
could
try
to
use
the
compartment
the
compartment
API
to
you
to
reuse
that
logic.
If
you
follow
there's
a
compartment,
the
compartment
in
the
compartment
API
necessarily
implements
the
process
of
fetching
a
dependency
analyzing,
its
shallow
dependencies
and
then
obtaining,
and
then
loading
its
transitive
dependencies
before
you
can
execute
any
of
it
right.
A
H
A
A
E
A
Again,
the
way
this,
what
this
would
look
like
is
SS,
apply
implementation.
Where
say
it
reads
your
package
lock
and
then
walks
your
package
lock
and
creates
a
compartment
for
every
package,
JSON
and
you're
in
your
application
right
and
in
order
to
create
those
compartments.
That
needs
to
be
able
to
thread
the
public
modules
from
the
dependency
modules
into
into
the
imported
module
namespaces
of
each
compartment
right,
and
you
can
do
that
entirely
by
analyzing.
The
package.json
snippets
from
in
the
package
lock
right
but
with
the
API,
is
a
dense
today.
E
A
To
do
that
with
the
compartment
API
but
from
outside,
so
the
expectation
is
with
something
like
sexified
we're
not
talking
about
client
code
using
the
compartment
API.
We're
talking
about
using
the
compartment
API
to
assemble
a
statically
known
that
of
compartments
and
the
statically
known
set
of
compartments
is
described
in
something
like
package
locked
out
Jason.
So.
A
A
Essentially,
the
do
that
we,
there
are
two
courses
that
are
that
are
actionable
they're,
both
they're,
both
equally
valid,
one
of
which
is
to
use
the
compartment
API
in
order
to
implement
Sesa
file
or
reproduce
the
behaviors
that
are
in
the
implementation
of
the
compartment
API.
In
order
to
in
order
to
implement
safai.
Does
that
make
sense
so.
H
I,
so
my
question
is
about
the
first
of
those
options:
can
you
implement
a
king,
the
functionality
that
you
have
in
mind
for
bundling
and
unbundling
and
all
the
rest
of
it?
Whatever
that
functionality
is,
can
you
use
the
compartment
given
compartments
without
this
new
API
giving
compartments?
Can
you
implement
that
functionality
straightforwardly
outside
the
outside
of
the
compartments
using
compartment.
E
It
would
help
me
if
we
could
have
if
we
could
draft
up
a
concrete
example
like
a
simple,
a
simple
application,
with
whatever
two
modules
and
two
compartments
or
whatever
and
say:
okay,
this.
This
is
a
scenario
which
we
want
to
bundle,
and
this
is
how
a
bundle
would
would
do
it
using
loaded
and
with
would.