►
Description
Michael FIG led a naming discussion for the eventual-send proposal. Alex Vincent proposed that instead of having a separate constructor, we could create a maker static function on the Promise object that returns a Promise. Saleh proposed the maker function might use the root “delegate” to disassociate the term from handled vs unhandled promise rejections. We agreed to avoid the term proxy on the grounds that, while we borrow the handler pattern from the proxy constructor, the handler itself is not sufficiently similar to a proxy handler to suggest they’re related. By the end of the discussion, we had loose consensus that these names were consistent and good:
* Promise.delegate(handler) returns a “delegated promise” and is analogous to Proxy.revocable, Array.from, or Object.fromEntries, in that it is a static method of a constructor that returns an object of the same type as the constructor.
* Promise.get(promise, prop), Promise.apply(promise, …), Promise.applyMethod(promise, prop, …) all could be static methods of the Promise and that we’ll consider alternatives.
* No changes to the names “presence” and “remotable”.
https://github.com/tc39/proposal-eventual-send/issues/11#issuecomment-618711001
We reviewed Caridy’s proposal for Realms to the “incubator” scheduled for the 27th. We attempted to isolate and address the two major concerns brought up in discussion with members of the committee previously, regarding layering the DOM atop realms and “consistency with the principles of the web”.
Kris updated the group with progress on the Compartment shim. We are beginning to add support for Compartment modules. We may eventually need to extend Compartments to support inter-linkage with modules not defined with JavaScript text, like WASM.
A
B
B
B
A
B
A
B
Adding
functionality
to
promises
so
that
they
can
be
used
as
remote
as
and
send
RPC
messages
and
Jack
messages
down
a
promise
before
it
has
resolved
so
that
way
ambassador
on,
but
it's
an
optimization
called
promise
pipelining.
That
Marcus
talked
about
and
great
detail
in
the
past,
where,
basically,
you
don't
have
to
wait
for
the
result
of
a
call
in
order
to
refer
to
it
in
the
future.
E
B
Instead
of
using
the
word
handle
promise,
we
change
B
async
proxy
in
the
same
way
that
every
other
async
instruction
is
the
destruction
that
has
been
specially
tailored
for
promises,
and
it's
analogous
for
proxy
in
this
dim
way
that
an
async
iterator
is
analogous
to
an
iterator.
But
the
interesting
thing
is
that
it
provides
a
lot
of
opportunities
for
optimization
than
regular
proxy
does.
B
A
A
The
idea
that
of
naming
handled
tom
is
something
that
emphasizes
that
there
is
an
elusive
allergy
with
proxy
sounds
good,
but
async
proxy
to
me
suggests
a
much
tighter
analogy.
Then
we
actually
have
the
async
iterator
really
is
taking
the
entirety
of
the
iterator
design
and
modifying
things
to
be
from
X
to
promise
of
X.
A
But
really
you
know
whole-hog
adopting
the
iterator
design.
Likewise,
async
functions
have
you
know,
or
based
on
all
of
functions,
plus
additional
asynchrony
at
the
weight
in
returning
a
promise.
I
think
that
if
we
called
it
async
proxy,
then
people
would
expect
the
entirety
of
the
the
proxy
functionality
with
the
get
own
property
trapped,
and
all
of
that
stuff
is
not
hard.
What
we
want
to
support
in
a
distributed
computing
model,
I
think
people
would
project
that
onto
the
proposal
and
we
would
have
worse
problems.
B
B
B
We
want
to
be
able
to
create,
handle
premises
in
all
sorts
of
different
situations,
not
necessarily
for
marshalling
remotely
and
and
so
the
Marshall
layer
has
one
idea
of
an
object
that
can
be
remoted
to
another
place
and
the
handle
promised
as
the
idea
of
a
presence
or
something
something
that
where,
when
a
handle
promise
resolves,
it
resolves
into
an
object.
That
is
a
stand-in
for
something
else.
B
A
So
one
of
the
key
things
there
that's
important
to
understand
is
the
separation
over
the
two
abstraction
layers
that
Marshall
is
built
on
hand
and
promise
and
uses
it
to
build
a
particular
distributive
object
system,
with
a
distributed
with
a
particular
distributed.
Object,
semantics,
but
handle
promise
doesn't
know
anything
about
Marshall
and
is
much
more
general
than
in
terms.
I
mean
is
much
more
neutral
with
regard
to
what
kind
of
describing
objects
semantics
if
any
is
built
on
top
of
it.
A
So
it
can't
in
case
where
you're
implementing
a
distributed
object
system
with
the
promise
actually
was
fulfilled
to
convince
the.
What
it
now
completely
designates
is
an
object,
that's
elsewhere,
so
because
it's
elsewhere,
it's
not
something
that
you
can
give
to
the
success
handler
to
the
success
callback
over
them,
so
the
the
presence
or
whatever
we
call
it-
has
to
be
the
local
non
Venable,
whose
purpose
is
to
stand
for
the
remote
object
that
the
promise
was
actually
fulfilled
to
so
it's
it
locally
represents
that
fulfillment.
A
A
So
so
the
original
remote
able
would
be
the
object
at
its
actual
location
with
the
actual
methods,
and
then
the
let's
say
remote,
which
is
what
Michael
is
proposing,
would
be
the
thing
that's
created
elsewhere.
Out
of
this
in
Michaels
proposal,
presence
out
of
this
presence
object.
It
would
be
the
marshal
layer
that
hurt
that
that
uses
the
handle
promise
layer
to
turn
a
presence
into
a
remote.
A
A
F
F
But
what
I'm
getting
at
is,
have
you
considered
the
possibility
of
adding
it
as
a
method
under
the
promise
global?
The
reason
being
you've
got
a
promise
that
resolve
promise
not
reject
already
defined
it
might
make
sense
to
put
it
underneath
promise
directly
and
well
then,
whatever
name
you
come
up
with
shouldn't
conflict
with
anything.
E
C
A
B
Think
the
only
thing
that
stopped
us
from
doing
that
was
that
we
wanted
to
have
these
static
methods
as
well
like
apply
function
and
apply
method
and
stuff
like
that,
and
people
would
probably
complain
about
adding
that
to
promise.
But
if
we
nested
in
within
the
only
the
only
a
single
property,
then
we
had
to
promise.
That
would
be
something
useful.
I
think.
A
A
A
F
C
A
A
There
is
a
but
but
didn't
say,
show
about
whether
or
not
it
should
be.
A
constructor
is
interesting
because
the
current
the
current
proposal
has
handled
promise
via
constructor,
but
we
actually
violate
the
constructor
pattern
because
handled
promise,
dot
prototype
is
the
same,
is
purposely
and
necessarily
the
same
object
as
promised
up
prototype.
A
The
the
but
yeah
the
the
having
to
be
a
derived
class
ministers
is
the
way
in
which
the
more
I
talk
about
distal
arm
coming
to
like
the
static
method,
the
people
are,
people
expect
of
the
constructor
or
a
derived
class
is
that
it
has
an
in
prototype
that
we
would
have
a
handled
promise,
dot
prototype
that
inherits
from
promise
not
prototype,
and
that
you
could
distinguish
promises
from
handled
promise
on
at
the
consumer
slide.
We
don't,
for
example,
by
using
instance,
and
we
don't
want
any
of
that.
A
We
want
the.
In
this
sense,
the
the
proxy
analogy
also
continues
to
hold,
which
is
from
the
consumer
side.
It
just
looks
like
a
promise.
There.
Just
is
a
promise,
it's
just
that
the
behavior
provokes
by
doing
things
with
it,
changes
because
the
handler
is
invoked,
but
you
can't
tell
that
from
the
consumption
side.
E
E
B
A
E
A
A
A
E
A
The
reason
why
I've
shied
away
from
that
now
that
I'm
saying
it
out
loud
I
think
it
might
be
a
bad
reason.
The
reason
I
was
shying
away
from
that
is
simply
putting
it
directly
on
promise.
I
suspect
will
create
work
more
committee
resistance,
and
that
is
not
in
it.
That
is
not
an
excuse.
Now
that
I'm
saying
that
it's
not
an
excuse
that
I
respect
for
proposing
something
worse,
I
should
always
start
by
proposing
whatever
I
think
is
best
and
only
back
off.
A
F
E
D
That
we're
kind
of
trapped
by
their
comment
haven't
kind
of
captured
in
the
terminology
which
is
which
we
see
in
terms
like
presence
and
remote
and
or
motivation
for
doing.
This
really
is
is
all
about
setting
up
the
conditions
under
which
we
can
do
distributed
computation
and
remove
messaging,
but
we're
not
proposing
distributed
computation
or
remote
messaging
for
say
we're,
not
language,
so
any
terminology
which
implies
remote
messaging
distributed
programming
kind
of
it
feels
like
that's.
That's.
D
D
Nevertheless,
as
a
piece
of
mechanism
in
the
language,
I
think
it
would
be
better
if
we
could
describe
it
in
terms
of
the
existing
language
and
what
this
would
add
to
it
directly
and
it
can
be
used
for
the
implementation
of
remote
messaging,
but
presumably
it
can
be
used
for
other
things
like
talking
to
workers
or
something
who
knows
what
it
is.
But
there's
you
know
various
other
use
cases
we
might
anticipate
and
terminology
that
sort
of
kind
of
has
baked
into
it
presumptions
about
what
your
use
cases
are
feels
somewhat
bothersome
to
me
almost.
A
D
A
C
Because
the
more
you
know
the
more
listened
about
in
MTC
discussions.
Basically,
you
know
proxy
that
revocable
kind
of
like
has
like
cookie
points
very
like
they.
They
already
kind
of
like
bit,
and
people
are
using
it
or
not.
I,
don't
know
I
never
do
it
might
not
be
an
ideal
thing,
but
it
also
is
ideal
that
most
people
don't
use
proxy
that
revocable
or
bother
to
wonder
why
it's
used
so
so
proxy
dot.
You
know
delegated
or
handled,
or
you.
C
A
No
I
think
I
think
having
it
be,
exactly
promise
dot
delegated
I'm
I.
That
sounds
really
quite
strong
to
me,
I'm,
very
glad
about
the
proxy
dot
and
revocable
analogy,
which
is
it's
a
maker
function
whose
signature
is
the
same
as
the
signature
of
the
constructor.
So
it's
understood
to
use
it
instead
of
the
consumer
or
when
you
want
this
additional
feature
and
proxy
dot
delegated
can
be
explained
exactly
the
same
way
it
has.
It
had
its
if
you
use
it
with
the
same
signature
as
the
constructor.
A
It
actually
means
the
same
thing
to
construct
your
mains,
and
it's
only
by
virtue
of
using
the
additional
optional
arguments
that
you
get
this
additional
functionality
and
the
additional
functionality.
Then
we
can
refer
to
the
promises
that
it
makes
with
the
adjective
delegated
promises
with
app
I
think
solves
all
of
the
terminology
problem
in
terms
of
the
noun
it.
E
A
E
B
F
A
D
D
B
D
A
So
let
me
let
me
just
check
one
particular
so
I
think
I
think
we're
so
I'm
happy
with
where
we
are.
But
let
me
just
check
it
against
a
particular
problem
case
that
Michael
and
I
had
talked
through
and
sanity
checker
against
our
current
terms,
which
is,
if
you
have
two
different
instantiations
of
Oh,.
A
A
A
A
B
D
B
E
D
A
B
A
A
So
that's
a
really
good
question
we
actually
do
provide.
Even
if
we
don't
didn't,
provide
a
predicate,
we
actually
do
provide
a
sneaky
way
to
oh
here's.
The
other
thing
about
collapsing
handle
the
heck
not
having
a
separate
constructor
is
now
the
behavior
that
we're
proposing
for
handled
promise
dot
resolve.
A
We
would
have
to
propose
that
that
behavior
get
folded
into
promise
dot
resolved,
and
we
can
only
do
that
if
it's
compatible
with
the
current
behavior
of
promise
not
resolved,
which
I
think
it
is
yes,
but
that
behavior
does
in
a
sneaky
way.
Ruth
feel
that
something
is
a
presence
because
for
a
normal
object,
if
you
do
promise
dot
resolve
of
normal
object
twice,
you
get
two
different
fulfilled
promises,
so.
B
C
They
had
a
dog
when
define
method
that
you
thought
what
a
dot
when
defined
and
you
would
give
it
the
custom
element
name
and
then
you
would
get
like
they
say
like
a
promise
like
thing,
you
know
that
basically
gets
resolved,
so
it's
kind
of
like
this
transparent
separation
between
the
promised
prototype
and
the
fact
that
you're,
referring
to
the
same
you
know
asynchronous
trigger
without
actually
involving
promises
sort.
So
to
speak.
So
so
there's
no
promise
object,
but
rather
you
pass
a
name
and
then
you
get
a
venable.
C
B
A
E
A
E
A
A
A
B
A
B
G
G
G
G
A
G
A
G
G
To
do
that,
I
haven't
seen
that
in
fact,
last
time
that
we
talked
about
we,
we
did
open
an
issue
three
months
ago,
I
think
to
have
ability
to
suppress
import
in
different
ways,
and
the
answer
was
from
Dominick's
I
know
that
doesn't
really
belong
to
to
the
Dom
API
or
a
link.
We
were
trying
to
see
how
to
suppress
the
CSP
or
by
having
the
ability
to
control
the
input
maps
in
a
generic
way.
So
you
could
say
if
someone
is
trying
to
import
anything
outside
of
these
said
I.
G
G
G
This
is
an
example,
just
very
simple
example:
how
to
evaluate
some
of
you
know
how
to
import
something
and
then
where
we
are
right
now,
which
is
the
end
of
the
presentation,
the,
which
is
what
I
want
to
talk
about,
and
in
this
meeting
now
there
there
are
two
main
other
questions.
One
is
the
mechanical
concerns.
This
is
how
it
works
with
the
DOM,
and
we
been
working
on
these.
G
The
current
position
that
we
have
is
a
we
discussed
here
at
some
point
is
a
the
realm
itself
does
not
have
any
dumb
semantics.
The
realm
is
created
by
a
another
round
that
might
have
done
semantics.
That
means
a
window
or
a
worker
or
some
other
ways
to
access
a
the
new
new
realm
and
from
there
you
can
create
as
many
as
you
want
nested,
but
the
semantics
are
really
the
when
it
comes
to
dance.
The
mountain
is
really
the
semantics
of
the
nearest
for
the
husband
semantics.
A
G
Believe
it's
like
a
completion
in
the
sense
that,
when
they
say
direct
access
to
all
the
Global's
as
a
problem,
what
they
really
are
saying
and
I'm
explaining
this
into
three
concerns.
So
this
concern
for
me,
is
really
three
concerns
and
I
want
to
run
it
by.
You
see
what
you
think.
The
three
concerns
that
I
see
in
number
one
is
a.
G
Access
instead
of
saying,
direct
access
to
other
Global's,
you
see
you're,
really
just
saying
direct
access
to
a
global
that
has
some
done
semantics,
like
the
the
possibility
to
be
detached
or
or
some
other
semantics
that
it
is
very
Dhamma.
Specific
second
problem
is
the
window
proxy
and
and
how
the
window
proxy
semantics
are
problematic
for
many
from
many
different
reasons,
and
the
fact
that
you
can
get
a
a
window,
an
iframe
in
this
case
to
be
refreshed
to
get
different
euro
to
get
a
new
created
document.
G
G
Detach
in
any
significant
way,
I
mean
there's
no
way
to
detach
other
than
detaching
the
nearest
global
with
the
time
semantics.
So
for
me,
those
two
things
are
most
important,
one
to
clarify,
and
then
the
third
one
is
the
garbage
collector,
which
I
believe
is
related
to
the
fact
that
your
detachable,
what.
G
G
G
A
Is
the
the
Global's
of
realms
that
are
created
by
existing
means,
new
iframes
new
workers
and
all
that
those
are
not
sure
about
terminology
for
workers?
Let's
just
talk
about
the
on
the
the
browsing
slide.
Those
Global's
are
Windows.
You
know
the
global
of
an
iframe
is
a
window
when
you
use
the
realm
API
to
create
a
realm.
The
global
of
that
realm
is
not
a
window,
and
this
the
concerning
the
second
bullet
should
be
a
concern
about
direct
access
to
Windows,
something
that's
just
a
global
and
is
not
a
window.
G
It
is
my
it
is
my
perception
of
this
issue
that
they
are
not
only
thinking
about
leads
from
those
terms
and
I
believe
what
you're
saying
it's
correct
like
this
is
just
this
is
just
as
I
said
before.
This
is
just
equivalent
to
a
closure
or
a
private
field,
or
some
other
ways
to
give
you
encapsulation
or
integrity.
Preserving
semantically.
There's
no
different
for
that,
but
I
believe
the
fact
that
there
is
some
association
with
a
window
at
some
point
and
that
window
can
be
detached
have
to
be
some
ways
for
them
to
identify.
A
But
but
that's
I
mean
I
think
you've
already
solved
that
which
is
every
non
window.
Global
is
in
a
sub
tree,
whose
is
a
window
and
everything
that
you're
everything
that
we're
currently
attributing
to
the
nature
of
the
realm
associated
with
a
given
window.
We
would
now
simply
associate
exactly
all
of
those
characteristics
with
the
subtree
of
realms,
the
subtree
of
non
window,
realms
rooted
in
a
given
window.
G
A
G
This
is
the
node
from
Daniel
that
explicitly
said
what
we're
saying.
So
we
were
saying
we
defer
to
the
pot
and
window
worker
for
all
kind
of
behavior.
We
don't
care
about
what
what
the
realm
is
doing
is
delegate
it,
but
still
we're
getting
some
pushback.
But
there's
no
much
detail
here
about
what
the
problem
is.
G
C
E
Look
good
for
my
own
understanding
of
the
realms
proposal.
Can
I
ask
some
clarifying
questions.
Yes,
is
it?
Is
it
our
intention
that
the
realm
API
be
usable
in
order
to
provide
a
rational
implementation
of
all
the
way
that
existing
api's
create
bags
of
intrinsics
today
already
do
like
iframes
like
nodes
virtual
environment?
Is
the
intention
to
lift
this
into
the
language
so
that
there's
a
common
bedrock
for
all
of
these
environments,
or
is
that
so
that
is
that
is
intended?
G
A
E
G
E
G
E
Well,
I
I
would
want
to
put
scare
quotes
around
this
or
frame
it,
as
is
some
worry
that
this
not
that
it
is
not
not
that
it
is
a
fact,
because
I
think
that
the
counter-argument
is
the
counter-argument
is
specifically
that
you're
trying
to
create
not
you're
not
trying
to
create
an
API.
That's
in
conflict
with
the
web
platform
you're
trying
to
create
an
API
that
explains
the
web
platform
as
it
exists
today
at
the
language
level,
so
that
that
explanation
can
be
shared
between
non
non
web
environments
and
the
web.
Is
that
about
right?
E
D
It
seems
to
be
because
it
sort
of
recurring
flavor
of
pushback.
That
is
a
way
of
saying.
I
have
big
unarticulated
objections
to
this.
That
I
can't
actually
explain
and
so
I'm
going
to
say
that
it's
counter
to
the
design
principles
of
the
web,
and
so
it's
it's
a
difficult
objection
to
push
back
against,
because
well.
First
of
all,
different
people
mean
different
things.
D
Concept
that
they
think
it's
in
conflict
with,
and
sometimes
it's
just
a
general
purpose
phrase
that
is
like
well
this
this
you
know
this
isn't.
This
is
outside
my
comfort
zone.
Therefore
I
don't
like
it
and
and
the
trick
there
is
how
to
how
to
get
somebody
to
converge
on
a
a
concrete
objection
that
you
can
make
a
counter-argument
to
or
possibly
that's
a
real
problem,
and
then
you
need
to
solve
the
problem
without
without
provoking
an
immune
reaction
or
provoking
a
fight.
D
G
D
I
I
often
thought
realms
in
terms
of
it's
like
taking
the
kind
of
core
idea:
that's
behind
iframes
and
and
and
separating
the
the
HTML
piece
of
it
from
the
other
stuff
that
it
does
and
it's
basically
it's
not
contrary
to
the
web.
It's
taking
an
idea
that
the
web
gave
us
and
allowing
us
to
abstract
it
out,
so
we
can
apply
it
in
other
domains.
Oh
and.
E
G
Coming
sorry
to
people
on
the
they're
coming
from
a
inaudible
around
on
the
down
side
of
things,
which
is
the
iframe
without
a
dome
which
they
want
to
implement.
This
is
an
iframe
that
has
only
the
some
some
capabilities,
but
now
that
not
a
Dom
doesn't
have
a
window.
A
document
I
haven't
spent
too
much
time
on
that
proposal,
but
that
one
will
have
is
asynchronous.
Communication
with
the
host
seems
I,
don't
think
it
will
be
synchronized,
but
there's
an
idea
that
they
have
yeah.
D
D
E
The
shadow
the
shadow
behind
this
is
that
there
is
certainly
a
with
people.
It
certainly
am
implied
to
buy
shoes.
Last
message
is
that
there
is
a
group
of
people
who
who
believe
ardently
that
that
the
creation
of
bags
of
intrinsics
like
iframes,
we're
a
mistake.
We
should
attempt
to
get
to
a
place
where
such
things
are
no
longer
needed,
that
it
will
gradually
find
a
way
to
wing
the
web
of
using
this
and
then
maybe
someday.
E
Maybe
someday,
have
have
a
foot
a
leg
to
stand
on,
to
get
rid
of
it
and
I
think
that
if
you
call
them
out
for
having
that
agenda,
it
starts
to.
It
starts
to
show
the
picture
that
that
isn't
a
realistic
end
that,
in
the
interim
at
least
until
we
can
have
until
they
can
realize
that
agenda
of
eliminating
the
notion
of
having
multiple
realms
entirely,
it
makes
sense
to
consolidate
what
already
exists
today
at
the
language
layer,
so
that
there's
some
shared
sense
between
browsers
and
non
browser
environments.
Yes,.
A
Actually,
I
disagree
completely
with
that,
which
is
that
there
is
a
proposal
that
enables
there's
pair
of
proposals,
analysis
we
split
it
that
enables
one
to
do
all
sorts
of
things
without
ever
creating
a
new
realm
and
that's
what
we're
in
fact
planning
to
doing
with
excess,
which
is,
if
you
freeze
all
the
primordial
x'
and
you've
got
compartments.
So
you
can
create
new
global
scopes.
Then,
in
fact
there
are
tremendous
numbers
of
things
you
can
do
without
ever
creating
a
new
realm.
A
E
E
We
have
this
realm
and
we
can't
futz
with
it,
because
there's
there's
there's
user
code
that
we
need
to
continue
being
able
to
run
in
hit.
We
also
want
to
run
things
inside
of
compartments
in
it
in
a
frozen
realm.
So
we
do
need
a
second
realm.
We
might
not
need
a
lot
of
realms,
but
we
do
at
least
one
and
have
one
round
so
that
we
do
need
one
more
realm,
so
that
we
can
freeze
that
one
and
yeah
yeah.
A
It
depends
on
what
you're
trying
to
do
for
the
browser.
Obviously
we
you
can't
break
the
tremendous
amount
of
old
code
that
relies
on
unmodified
yeah,
one
on
fully
mutable
traditional
realms
sets
of
intrinsics,
but
for
new
code,
like
you
know,
planning
can
do
on
excess
excess,
never
plans
to
support
multiple
realms
because
it
there's
no
reason
to
and
multiple
compartments
with
one
frozen,
ROM
satisfies
all
of
their
use.
Cases.
G
And
finish
they
explained
in
which
they
asked
for
so
far.
I
have
some
some
I
think
some
information
here,
I
will
continue.
Working
on
I
will
send
a
pull
request,
form
it's
more
complete,
so
they
were
asking
for
a
explain.
A
type
of
document
similar
to
what
they
do
put
Dom
API
is
don't
propose.
Also
we'll
see
how
that
goes
on
touching
on
modules.
G
G
How
these
relates
to
the
college
order
similar
proposals
like
the
compartment
API
and
explained
some
of
the
future
or
for
forward-looking
a
statement
around
these
are
no
yeah,
so
I
don't
know
if
I
will
get
the
chance
to
finish
these
I
don't
have
too
much
time
for
now
until
that
meeting,
but
we'll
see
how
that
goes.
If
some
of
you
can
participate,
please
do.
A
E
The
an
update
on
the
status
of
the
compartment
import
support
I
have
a
stack
of
changes
that
bring
it
in
into
the
shim
the
there.
There
are
some
lingering
issues.
I
need
to
work
out
because
it
entrained
Babel
is
a
Babel
as
a
dependency
and
there's
some
trouble
getting
that
to
work
in
all
three
of
the
module
systems
that
we
support.
But
it's
it's
coming
along
the
this
is
what
will
happen
is
over
one
of
a
matter
of
from
just
logistics.
E
I
intend
at
some
point
to
split
the
compartment
shim
from
the
lockdown
shim
and
create
a
new
added
goreck
/
compartment
package.
That
would
be
where
the
where
the
compartment
shim
would
live
and
it
will
be
fully
decoupled
from
lockdown
and
then
the
next
step
after
that
is
yeah,
import
will
be
coming
and
the
compartment
shim
will
export
both
compartment
and
a
module
static
record
constructor.
E
We
had
a
conversation
yesterday
about
how
deeply
how
deeply
we
need
to
how
much
of
the
API
we
need
to
expose
to
the
outside
world.
I
think
that
there
remain
some
open
questions
about
how
we
make
other
languages
than
JavaScript
mutually
linkable
in
a
compartment
like
wasm,
and
this
might
also
feed
in
to
the
conversation
about
how
the
module
attributes
proposal
goes.
A
So
the
the
attributes
proposal,
the
the
more
don't
we
talk
about
it,
the
more
it
seems
like
having
the
attributes
come
from.
The
importer
is
just
tremendously
inappropriate
and
I
tried
to
I'm
having
a
hard
time
imagining
what
the
security
problem
was
in
having
the
attributes
come
from
the
provider
of
the
module.
E
The
comment
of
Brian
Warner
yesterday
suggested
that
some
compartments
might
actually
use
web-based
rules
and
realize
the
compartment
realize
the
module
type
based
off
of
the
mime
type.
That's
obtained
from
the
server,
whereas
compartments
that
are
realized
from
node
style
packages,
would
ideally
all
in
infer
how
to
rely
as
the
module
based
off
of
the
module,
specifier
and
metadata
to
the
compartment.
Since
that's
the
norm
for
that
style
of
packaging
yeah.
E
The
the
big
open
question
that
that
I'm
beginning
to
think
about
now
and
invite
you
all
to
begin
thinking
about
now
is
what
kind
of
API
we
need
to
add
on
to
the
compartment
proposal.
In
order
to
facilitate
linkage
between
non
JavaScript
module
types
and
I.
Think
that
this
might
take
the
shape
of
having
a
module
static,
record
interface.
E
There
could
be
implemented
in
different
ways
depending
on
the
language
or
the
source
of
the
binding,
which
would
which
would
realize
that
which
would
carry,
which
would
mean
that
the
import
hook
would
provide
a
something
that
implements
the
modules
static
record
interface
in
such
a
way
that
it
can
orchestrate
any
an
underlying
implementation
from
any
language
that
may
become
I'm,
not
sure
how
much
gross
nests
of
the
internals
will
have
to
be
realized
in
the
public
API.
In
order
to
facilitate
that
it
might
be.