►
From YouTube: SES Meeting: Mass revocation of proxies
Description
Alex presents a draft of mass revocation of proxies and Jack Works proposes a higher fidelity module source virtualization, capable of emulating initialization of hoisted functions.
A
All
right
today
is
august
24th,
and
this
is
a
cess
meeting
today
on
the
agenda.
We
have
a
few
topics
we're
going
to
try
to
get
through
at
least
one
today,
we've
set
aside
for
alex
to
discuss
mass
revocation
of
proxies,
has
he's
volunteered
to
champion
that
proposal
as
an
invited
expert
with
the
support
of
jack
and
mark,
and
hopefully
we
can
get
some
paperwork
through,
so
that
alex
can
present
it
at
a
nearby
plenary.
A
So
after
that,
we
have
a
couple
of
topics.
Jack
has
brought
up
an
issue
with
module
virtualization,
specifically
that
there
is
a
particular
form
that
we
can't
of
javascript,
that
it
is
not
currently
capable
of
virtualizing
and
karate
has
some
some
conversations
and
clarifications
you'd
like
to
make
regarding
the
spectex
for
layer
0
around
the
the
shape
of
the
module
constructor
that
we're
converging
upon.
So
with
that,
please
alex
take
it
away.
B
B
So
when
it
comes
to
membranes
and
apologies,
gentlemen,
this
is
reiterating
some
of
the
things
that
we
have
seen
but
have
not
been
presented
to
tc39
in
probably
quite
some
time.
The
first
model
of
membranes
that
mark
and
dr
tom
van
cutsem
came
up
with
was
of
a
cell
membrane.
Hence
where
the
name
membrane
came
from
you're,
either
inside
the
membrane
or
outside
it.
B
B
Well,
when
I
got
to
thinking
about
this-
and
I
I
was
presenting
actually
in
july
2018
at
the
tc39
plenary
in
redmond
washington-
and
there
was
a
question
that
came
up,
saying:
hey
is
biology
required
to
understand
this
and
on
the
fly
I
responded.
No,
you
really
don't
need
that,
but
we're
going
to
get
to
a
three-dimensional
way,
it's
more
three.
It's
a
three-dimensional
model
that
we're
gonna
get
we're
gonna
get
to
at
the
time.
Even
I
didn't
understand
fully
what
I
was
saying.
B
Two
months
later,
I
came
up
with
a
geometric
model
to
illustrate
this
better,
where,
instead
of
either
inside
a
cell
membrane
or
outside
now,
I'm
using
object
graphs
as
two
dimensions
as
a
as
a
two-dimensional
plane
and
the
the
connection
and
they're
parallel
to
each
other.
The
planes
are
parallel
to
each
other.
B
B
B
When
it
comes
to
shutting
down
one
object
graph,
you
want
to
shut
down
both
the
proxies
in
that
object,
graph
and
proxies
two
objects
in
that
object,
graph
that,
where
the
proxies
live
in
other
object,
graphs
mark
came
up
with
this
idea
of
revoking
having
a
revoked
method
on
a
shadow
realm
which
would
handle
the
first
of
those
revocations
proxies
in
the
same
shadow
realm.
But
it
wouldn't
necessarily
cover
proxies
in
other
shadow,
realms.
B
Which
is
what
this
slide
was
about,
so
the
idea
I
had
was
what,
if
we
had
a
revocation
controller
or
revocation
mechanism
where
we
could
pass
that
in
as
a
third
argument
to
new
proxy
and
to
proxy
that
revocable
and
to
make
sure
that
the
api
was
as
extensible
as
possible,
we
would
pass
it
in
as
a
property
of
an
options.
Dictionary
and
the
options.
Dictionary
would
be
that
third
argument.
B
B
B
You
have
at
most
one
for
each
element
of
the
power
set
of
object,
graphs,
which
means,
if
you
have
three
object,
graphs
you
have
at
most
eight
revoker
functions.
Actually
technically
seven.
If
you
have
four
object
graphs,
you
have
at
most
16
technically
15
revoker
functions
and
in
most
cases,
you'll
have
n
times
n
minus
1
revoker
functions
at
most,
because
those
are
going
to
be
your
I'm
sorry,
n
times,
n
minus
1
divided
by
2
for
the
number
of
object
graphs.
B
So
in
cross-cutting
concerns
there
have
been
questions
raised
about
cancel
about
the
cancellation
proposal,
which
is
currently
stage
one.
I
believe
I
have
no
objection
whatsoever.
I
think
it's
actually
worth
exploring
whether
the
cancellation
api
that's
been
proposed
is
what
the
shape
of
the
revocation
signal
could
be.
I
think
that's
if
we
can
get
that
proposal
to
move
along
and
get
it
in.
I
think
that's
perfectly
fine.
B
I
don't
remember
off
the
top
of
my
head
if
cancellation
is
synchronous
or
asynchronous,
but
I
do
think
that
we
can
work
around
that
in
one
way
or
another
in
the
javascript
code
base,
as
I'm
sorry,
javascript
client
code,
I
should
say
regarding
the
shadowrealm.prototype
the
revoked
idea
that
spawned
all
this.
I
think
that
we
still
want
to
keep
that
around
and
that
the
two
proposals
actually
complement
each
other.
B
C
C
So
the
idea
is
that,
rather
than
having
a
revocation
token,
be
a
thing
with
behavior,
it's
just
an
arbitrary
object
that
you
provide
as
an
additional
optional
argument
and
then
there's
also
a
separate
revoke
api,
where
you
can
revoke
and
provide
the
same
identity
that
you'd
provided
earlier,
and
then
it
revokes
everything
for
which
that
identity
had
been
provided.
As
an
argument,
the
thing
that's
surprising
about
it
is
just
that
you
know
by
reusing
the
same
identity.
C
You
can
revoke
many
things
by
just
revoke
by
just
revoke
and
and
using
that
token,
and
that's
it
that
way.
We
get
that
way.
We
can
avoid
the
entire
issue
about
cancellation
apis
and
the
the
difficulty
of
getting
that
to
move
forward.
Much
as
I'd
like
to
see
it
move
forward,
and
we
are
sitting
on
the
existing
precedent
that
has
succeeded
getting
through
tc39.
B
How
do
I
put
this,
I'm
worried
about
the
lack
of
synchronicity?
It's
okay!
If
you
have
a
synchronous
function
that
causes
the
finalization
and
also
does
marks
a
flag
synchronously
so
that
it
can
be
picked
up
by
a
component
of
the
proxy
handler
to
handle
that
when
someone
else
accesses
that
proxy
handler
through
another
proxy.
C
C
A
D
D
We
don't
we
we
do
have
a
pointer
back
to
back
pointer
back
to
the
actual
function
or
wherever
that
function
live,
but
we
don't
keep
track
of
what
roms
has
that
function
in
the
first
place,
so
how
to
add
more
thanks
to
the
equation
in
order
to
get
any
sort
of
pointer
back
to
a
thing
that
eventually
will
be
revoked.
So
you
can
revoke
this
function
that
you
have
the
term
revoked.
D
D
The
revolt
case
there
is
tricky,
because
not
only
what
I
explained,
but
also
the
function
is
still
useful.
You
can
add
things
to
it.
You
can
do
all
kind
of
things
that
will
not
trigger
any
any
of
the
things
that
you
trigger.
If
it
was
a
proxy
that
was
revolved,
because
the
proxy
revoked
has
a
lot
more
annoyances
around
it
that
when
you
interact
with
that
object
or
function,
you
you
you
do
get
certain
things
that
will
just
fail
in
the
case
of
the
wrath
function,
you
don't
have
those
constraints,
so
it
doesn't
fail.
D
It
only
fails.
You
actually
call
it.
That's
the
kind
of
thing
that
we
might
we
might
we
we
might
have
a
hard
time
figuring
it
out.
So
the
fact
that
the
the
wrap
function
doesn't
know
where
the
target
function
is
coming
from
makes
it
a
little
bit
more
difficult.
So
that's
one
one.
One
note
on
that
on
the
the
callable
boundary
being
able
to
share
the
cancellation
itself
is
also
problematic,
because
I
suspect-
and
you
go
up
maybe
once
like.
B
D
C
Agree
with,
I
agree
with
kurtie's
recommendation.
I
do
think
that
that
there
are
good
engineering
answers
to
the
questions
that
kirk
is
raising,
but
I
think
that
for
what
alex
is
doing,
it's
best
not
to
eat.
You
know
just
to
mention
that
historically
and
not
to
raise
the
idea
that
we
want
to
push
that
actively
alex
in
general.
C
Just
being
being,
you
know
more
minimalist
that
they're
trying
to
to
to
figure
out
what's
sort
of
the
minimal
proposal
that
that
that
satisfies
the
goals
you're
setting
out
to
and
in
particular,
even
if
there
are
good
engineering
solutions
to
the
shadow
realm,
revocation,
which
I
believe
there
are
once
I've
got
good
revocable
membranes.
I
don't
care
because
I'm
never
going
to
use
a
shadow
realm
without
a
membrane
anyway,
and
I
can
just
use
good
membrane,
revocation
to
accomplish
whatever
I
could
have
accomplished
with
shadow
realm.
Revocation.
B
D
So
let
me
see
how
can
I
say
this
so
if
you
share
that
sign
up
with
the
shadow
wrong
across
the
call
of
a
boundary
on
the
other
side,
you
will
not
be
able
to
revoke
that
sign
up.
You
can
only
I
mean
you
would
not
be
able
to
use
that
sign
up
for
things
on
the
other
side,
so
that's
an
important
distinction,
I
believe
so.
Basically,
oh.
B
D
See
what
you're
getting
at
we
created
a
sign
out
here.
That
sign
was
not
useful
beyond
the
current
rom
that
you
are
on
okay,
okay,
so
you
will
not
be
able
to
do
the
second
line:
new
proxy
yada
yada,
with
the
sino
that
you
receive
across
the
membranes
that
that's
just
announces,
but
we
need.
We
need
to
clarify
that
or
at
least
have
it
somewhere.
So
it's
basically
it's
per
wrong,
so
you
can
only
use
it
in
that
realm
itself.
Okay,.
D
The
second
thing
is
that
the
the
sign
on
itself,
which
is
callable
here,
you
will
be
able
to
share
it
with
another
rom
and
call
it
at
the
other
rom
and
it
will
trigger
the
kill
of
the
proxies.
So
that
works
fine.
So
I'm
giving
that
thing
to
you,
you
you
don't
know
what
it
is,
but
if
you
call
it
it
kills.
D
D
You
still
will
be
able
to
maybe
use
like
imagine
that
you
use
like
a
symbol,
because
it
could
be
anything
so
you
could
use
a
symbol
and
then
you
can
share
that
symbol
between
different
realms
and
use
these
things
to
create
to
create
new
proxies
on
the
other
side,
with
the
same
symbol
and
now
suddenly
you
can
revoke
that
symbol
in
one
side
and
what
are
the
implications
of
doing
so?
Is
it
going
to
kill
every
every
proxy
that
was
created
with
that
symbol
across
the
board?
Even
if
it
is
across
the
realms?
D
E
D
B
D
B
Right
regarding
options
being
a
dictionary
object
containing
properties.
I
did
that
deliberately
because
I
was
worried
about.
If
we
made
the
revocation
signal
a
top
level
argument,
then
we
might
risk
getting
the
api
wrong
more
than
anything
and
worried
about
breaking
things
in
forward
compatibility
and
affordable.
D
I
agree:
I
agree
with
that,
a
good
so
the
way
I'm
looking
at
this
is
basically
can
I
have
an
option
that
sign
up
to
the
proxy
that
the
handler
should
be
read
once
during
creation
time
rather
than
keep.
It
then
live
something
like
that,
so
to
make
it
faster
things
like
that,
we
might
be
able
to
add
it
later
on
in
the
option
box.
D
B
A
A
C
A
A
Yeah,
so
there
yeah
there's,
there's
no
reason
to
mention
it
is
in
terms
of
additional
for
additional
feedback
for
bringing
this
to
plenary.
I
think
that
it
with
the
time
you
save
from
omitting
those
slides.
I
think
that
it
would
be
great
to
lead
this
presentation
with
a
recap
of
not
just
what
is
a
membrane
or
why
we
need
a
more
sophisticated
model
for
membranes
or
why
we
need
we
need,
but
it
would
be
good
to
talk
about.
Why
would
you
use
this?
A
B
A
Yeah,
I
guess
to
be
explicit.
I
think
that
the
reason
why
you
need
a
membrane
is
so
that
you
can,
you
is,
is
very
I.
I
agree
that
there's
thing
there
are
things
to
worry
about.
Is
that
it's
part
of
the
object
capability
model
that
that
that
motivates
the
need
for
this.
The
ability
to
revoke
an
authority,
that's
imbued
by
a
capability
and
the
capabilities
transitively
received
from
it,
which
might
not
be
a
popular
stance.
But
it
is
an
honest
one
about
the
motivation.
C
B
C
Oh
absolutely
absolutely
you're
much
better
off
with
the
30
crimes
for
a
30
minute
time
slot
all
together,
including
qa.
I
definitely
think
you
should
go
for
that,
even
though
they
hadn't
seen
your
previous
membrane
talk.
I
think
you
can
assume
that
everybody
on
the
committee
knows
what
a
membrane
is.
So
I
I
I
don't
think
this
talk
is
is
is
miscalibrated
in
terms
of
that,
I
don't
think
a
lot
needs
to
change
because
of
the
the
committee
turnover.
I
just
wanted
you
to
keep
in
mind.
A
B
C
C
I
think
I
mean
at
this
point:
membranes
are
just
one
of
the
programming
patterns,
people
use
in
javascript,
it's
entrenched,
it's
established
and,
and
the
idea
of
it
being
a
boundary
for
imposing
some
kind
of
policy
about
what
crosses
the
boundary.
I
think
is,
I
think,
that's
maybe
I
miss.
Maybe
I'm
overestimating
the
degree
to
which
people
already
understand
that,
except.
B
Yeah,
I
will
probably
add-
I
I
will
probably
add
a
few
slides.
I
hope
to
keep
it
down
to
two
between
slides
two
and
three,
but
that's
a
big
assumption
at
this
point
guys
because
and
the
counterpoint
is,
if
I
have
to
explain
membranes
every
single
time
that
I
present
this
idea.
That's
gonna
be
annoying
to
everybody
in
the
room.
Not
just
me.
D
D
D
D
For
for
those
cases,
we
use
sort
of
an
estate
machinery
there
where
we
say
okay,
this
proxy
is
useful,
is
not
useful
anymore
and
what
we
we
drop
all
together
from
the
weak
map,
and
we
remove
the
thing
from
the
scheduler.
Basically
that
updates
the
ui,
but
nevertheless
this
is
a
case
where
you
have
multiple
proxies
that
has
to
work
in
in
a
in
in
a
coordinated
manner,
and
you
want
to
drop
all
these
proxies
at
once.
D
B
B
E
E
A
So
let's
talk
a
little
bit
about
about
scope
so
with
the
original
compartments
proposal,
when,
when
mark
pitched
virtualizable
modules
to
me,
part
of
the
it
was,
it
was
a
well-known
caveat
and
limitation
that
it
wouldn't
be
suitable
for
emulating,
javascript,
and
that
was
in
a
in
a
prior
form.
That
was
much
much
farther
from
being
able
to
emulate.
Javascript.
C
The
you
know
live
javascript
is
the
only
thing
that
needs
live
bindings.
You
know,
wasm
does
not.
Jason
obviously
does
not,
and
I
think
that
you
know
any
language
that
that
might
seem
to
to
need
live
findings.
You
can
do
the
kind
of
the
wasm
the
tricks
that
wasm
does
to
emulate
them
by
other
means,
so
so
yeah
the
and
the
the
what
it
would
take
to
do.
A
virtual
module
api
that
did
support
live
bindings.
I
just
felt
it.
E
A
E
A
E
I
want
to
share
our
use
case,
so
I
am
working
on
a
plugin
system
that
is
fully
visualized
and
so
and
and
we
cannot
use
a
vowel
in
our
environments,
so
system
cannot
be
used
and
my
answer
to
this
is
I
made
a
compiler
to
compile
all
es
modules
into
the
virtual
module
format.
So
it's
important
to
me
that
this
format
should
be
able
to
emulate
fully
emulate
the
es
module.
E
C
D
E
D
A
A
C
Yes,
let
me
mention
that
the
this
pre
this
early
export
of
function
is
actually
a
a
distinct
complexity,
then
from
the
live
bindings
they're,
both
kind
of
in
the
same
area,
but
but
I
hadn't,
even
you
know
when
I
decided
to
reject
my
bindings
to
avoid
the
complexity.
I
wasn't
even
really
thinking
about
this
early
export
of
function
of
hoisted
functions.
That's
also
just
a
very,
very
odd
and
very
javascript
specific
semantics.
C
E
I'm
not
sure
if
it
is
minimal,
but
the
form
I
suggested
in
the
the
top
top
thread
and
possible
to
support
life
binding
and
functional
hoisting.
It
is.
It
is
also
like
how
system.js
support
for
esm
module
semantics,
but
it
brings
a
lot.
I
believe
it
brings
a
lot
complexity
in
the
individualized
environment
stage,
because.
D
D
Can
we
wait
until
we
get
to
that
api
because
we
haven't
really
see?
I
haven't
seen
that
the
relationship
or
the
intersection
semantic
between
these
and
the
work
that
we're
doing
for
module,
source
and
module
instances
and
reflection
and
data.
It
seems
too
early
for
me
to
comprehend
what
the
problem
is.