►
From YouTube: SES Meeting: compartments and shadow realm errors
Description
Jack Works brings questions about the proposed update for the compartment API and Mathieu brings questions about errors thrown from shadow realms.
A
All
right
welcome
to
the
assess
meeting
today
is
may
25th
of
2022,
and
the
topics
for
today's
meeting
are
updates
for
the
compartment
api.
We
have
jack
works
on
the
call
who
has
questions,
because
their
group
is
implementing
the
compartment
api
as
we
speak
for
their
purposes,
and
we
have
my
changes
to
the
compartment
api,
which
are
an
omnibus
of
all
of
the
things
that
we've
changed
in
the
last
two
years
since
we
updated
it
and
much
of
which
needs
consideration,
and
if
we
can
manage
to
get
karate
and
matthew
here.
A
B
A
A
It
needed
to
also
be
a
number
of
other
things
and,
and
the
question
became,
how
do
we
distinguish
a
module?
Namespace
object
in
a
reliable
way
from
all
of
the
other
things
that
we
needed
to
be
able
to
fit
into
that
position
like
static
module
records
or
static
module
records
with
with
metadata
and
the
metadata
for
a
stat,
so
static
module
records
can't
capture
the
per
compartment
metadata
of
us,
of
the
static
module
or
of
the
module.
The
module
source.
A
A
So
the
idea
is
that
we
solve
so
that
we
can.
We
can
solve
a
whole
bunch
of
problems
by
changing
the
value
type
of
module
map
and
the
return
type
of
magical
module
map
hook
and
the
return
value
type
of
the
load
hook,
which
we
previously
called
the
import
hook.
If
all
of
those
were
module
descriptors,
it
increases
the
uniformity
of
the
of
the
api.
A
So
in
my
proposal,
which
I'm
updating
so
that
xs
and
endo
can
have
a
shared
truth
to
approach
now
that
we're
getting
closer
to
converging
introduces
the
no
introduces,
for
the
first
time,
the
notion
of
of
a
module
descriptor
and
instead
of
looking
at
the
diff.
Let's
look
at
no,
not
the
rich
diff.
That's
not
what
I
want.
I
want
to
look
at
the
file
the
new
file,
so
we're
proposing
the
addition
of
a
module
descriptor,
which
is
this
tagged
union.
B
A
B
A
So
this
is,
this
is
a
a
a
cheap
way
to
say:
hey
this.
The
the
module
loaded
in
my
current
compartment
is
the
static
module
record,
which
is
to
say
the
how
to
instantiate,
not
the
instance
can
pass
from
the
parent
to
the
child,
as
opposed
to
other
cases
where
the
instance
is
passed,
which
is
straw,
man,
I'm
proposing
that
we
say
namespace
and
provide
the
module
exports
namespace,
so
that
this
is
the
distinction
we
for
inheriting
a
namespace
versus
a
record.
A
And
then
the
other,
the
other
case
is
passing
a
descriptor
that
says:
here's
the
static
module
record
or
the
third-party
static
module
record,
in
which
case
you
can
optionally,
say
that,
and
we
might
not
need
this,
so
I
won't
cover
it
right
now.
The
important
thing
is
that
this
would
allow
you
to
carry
properties
to
be
assigned
to
the
import
meta
of
the
instance
before
it
initializes.
A
A
It
is
inevitable
that
the
load
hook
will
be
implemented
in
such
a
way
that
it
discovers
all
of
the
data
necessary
to
populate
import
meta
and
putting
it
in
the
module.
Descriptor
provides
a
clear
way
for
the
load
hook
to
communicate
that
information
back
to
the
compartment
as
opposed
to
putting
it
into
a
side
table
and
then
having
the
import
hook,
share,
share
that
state
and
so
that,
when
it's
called
when
the
import
metahook
gets
called
later,
it
can
provide
the
information
that
was
discovered
during
the
load
hook.
A
The
concrete
implementation
might
not
be
illustrative,
but
the
the
let
me
talk
through
it
first
and
see
if
that's
clear
enough,
a
load
hook
receives
a
full
specifier
and
is
required
to
return
a
module
record
and
then
potentially
additionally,
also
this
metadata.
So
to
make
the
case
for
why
it
needs
to
return
the
metadata.
The
first
thing
that
a
load
hook
needs
to
do
is
take
the
full
specifier
and
then
locate
the
corresponding
request
url.
A
So,
supposing
that
we're
using
urls
in
fetch
right
on
the
web,
you
take,
you
would
first
lift
the
module
specifier
in
its
logical
namespace
into
url
namespace.
Locating
it
right,
and
that
gives
you
a
request,
url
and
then
you
go
off
and
fetch
it
and
fetch
has
the
possibility
with
fetch.
There
is
the
possibility
that
you're,
yes,
you're,
going
to
get
the
source
text
provided
that
it
exists.
A
A
A
B
C
B
But
why
it's
why
the
import
meta
url
as
the
real
real
url
instead
of
the
url-
that's
meaningful
inside
that's
compartment.
For
example,
I
have
a
module
called
called
x
and
I
do
I
go
over
through
the
load
hook.
It's
become
some
http
url,
but
I,
but
it's
important
meta
url,
should
still
be
the
original
specifier
x
instead
of
the
real,
the
real
url.
A
Import
meta,
url
is
being
used
for
retrieving
adjacent
assets
in
the
on
the
web
to
and
they
are
adjacent,
not
in
the
logical
name,
space
of
the
compartment
they're
a
lot
and
they
are
adjacent
in
the
physical
namespace
of
the
web.
So
if
I
were
to
have
like
one
common,
alias
that
happens
in
an
in
an
endo
style
compartment,
that's
emulating
a
node
style
package
is
that
the
name
dot
refers
to
dot,
slash
source,
slash
main.js,
for
example,
right
and
if
I
were
to
use
dot
as
the
import
meta
url.
A
B
B
C
You
don't
have
to
like.
I
think
this
from
what
I
understand
from
chris.
This
api
gives
you
an
opportunity
to
give
at
the
original
url,
but
if
you
want
to
virtualize
it
and
put
whatever
else
you
want
in
there,
that
would
work
with
your
with
that
compartment
compartments
virtualization.
You
still
can
when
the
import
hook
is
called
right.
Yes,.
A
The
the
load
hooker
import
hook
has
the
ability
to
deny
by
default.
The
import
hook
provides
no
meta
there's
by
default
by
default.
The
compartment
api
does
not
provide
any
properties
on
import
meta
then
it
is.
It
is
up
to
the
host
to
provide
or
deny
so
our
position
on
the
compartment
api
is
enabled
to
that.
A
Let
me
let
me
find
where
I
put
my
window
yeah
going
back
to
here:
yeah,
okay,
so
yeah
continuing
from
where
I
left
off
there.
We
add
the
this.
This
revision
of
the
proposal
adds
the
notion
of
a
third
party
static,
module
record
as
well
that
wasn't
there
before
and
third-party
static
module
records,
allow
us
to
link
jason,
wasm,
etc.
A
A
A
A
A
This
is
the
api
that
we
implemented
in
the
shim
and
doesn't
reflect
what
I'm
proposing
for
the
standard,
but
it
should
give
you
the
right
idea.
The
idea
is
that
module
exports
corresponds
loosely
to
a
module
environment
record
and
we
do
some
common
jsc
things
and
create
a
require
call
that
uses
import
now
behind
the
scenes
in
this
case,
in
order
to
return
the
namespaces
of
things
that
are
imported
and
then
we
create
a
functor.
A
This
is
a
common
js
functor
that
just
wraps
the
source
of
the
common
js
module
in
a
fun
function
that
receives,
require
exports,
module
file
named
name,
and
then
we
return
the
old
idea
of
a
static
module
record,
which
was
just
the
declarations
of
imports
exports
in
an
execute.
This
is
changed
into
bindings
and
initialize.
A
The
difference
is
that
the
bindings
array
consists
of
all
of
these
import
star
as
import
export,
star
import
export
as
in
from
and
the
the
effect
is
the
same,
except
that
the
bindings
array
preserves
the
order
in
a
way
that
the
old
form
did
not,
and
the
initialize
no
longer
requires
us
to
pass
a
compartment
in
an
import.
Now
in
because
the
module
environment
record
has
all
of
the
proper
names
already
bound
to
the
module
environment
record.
A
B
A
A
It
it
needs
to
this
regardless,
you
need
to
be
able
to
pass,
require
and
require,
and
exports
and
module
into
the
underlying
source
that
so
the
source
is
just
evaled
and
we're
injecting
those
things
the
require
function
will
need
to
be
more
elaborate.
The
require
function
needs
to
be
able
to
from
the
analysis
phase.
We
will
have
to
keep
track
of
what
the
name
is
for
every
namespace
object
of
something
that
every
namespace
object
that
was
imported
from
another
module
in
the
bindings
array.
A
The
require
function,
that's
passed
into
the
source
is
going
to
close
over
that
module
environment
record
and
have
to
track,
and
we
and
in
the
analysis,
phase
we'll
need
to
produce
a
map
that
says
this
specifier.
This
import,
specifier
from
the
require
call,
corresponds
to
this
property
of
the
environment.
Module
record
does
that
make
sense
not
entirely,
but
it's
basically
for
common
js.
A
C
C
A
C
D
It
feels
to
me
very
similar
to
what
happened
with
the
loader
api,
where
we
spent
years
trying
to
go
for
a
very
compelling
solution
that
can
do
a
lot
of
things
and
then
we
fail
to
deliver
that.
So
we
need
to
be
conscious
about
it
and
hopefully
trying
to
simplify
it
as
much
as
possible,
because
it
seems
like
a
massive
massive
feature
and
we
don't
have
a
very
good
track
record
for
big
big
features.
D
A
D
That's
true,
but
I
I
I
feel
that
when
you
look
at
the
different
use
cases,
some
of
them,
you
might
be
able
to
solve
it
with
solutions
that
you
have
for
other
use
cases.
So
moving
more
things
to
the
user
line
might
be
a
good
strategy
and
it
might
not
give
you
the
full
advantage
that
you
have
with
this
api.
But
it
will
give
us
a
path
forward
with
the
communities
to
try
to
get
something
in
and
then
we
can
move
from
there.
But.
A
A
My
proposal
was
that
all
we
needed
for
a
module,
loader
api,
for
whatever
module
system
we
adopt
into
the
language,
would
be
to
introduce
a
module.
Constructor
function,
that's
analogous
to
a
function
constructor
that
would
be
analogous
to
the
static
module
record,
but
be
directly
executable
by
user
code
without
an
associated
compartment.
A
A
B
D
B
C
Over
to
matthew
all
right,
let
me
share
my
screen
I'll
try
to
do
a
condensed
version
here,
so
the
shadow
realm
api
has
proposed
basically
prevents
anything
thrown
from
one
side
of
the
callable
binary
to
well.
Actually
I
don't
know
what
we
we
talked
about
is
a
couple
months
ago,
and
I
think
what
we
ended
up
at
was.
C
An
object
thrown
including
a
real
error
thrown
across
the
collarbone
boundary
would
just
end
up
as
a
generic
type
error,
because
it
cannot
go
across
the
boundary
there.
Then
questions
came
up
about
well
how
what
is
the
about
the
developer
experience
for
for
those
things?
So
now,
if
you
have
a
generic
type
error,
that's
created
there.
You
lose
the
stack
information
that
you
potentially
had,
or
even
the
error
name
that
you
had
of
the
original
error
and
then
so.
C
It
is
conceivable
that
we
put
the
burden
on
the
user
code
using
the
shadow
realm
api
to
catch
exceptions
before
the
callable
boundary
and
pass
them
over
through
a
membrane
line
system
or
a
reporting
system
to
to
report
exceptions
thrown
during
the
execution
so
use
the
callable
binary.
The
user
code
should
be
aware
of
the
callball
boundary
and
and
in
the
same
way
it
can't
let
object
go
through.
It
would
have
to
catch
exceptions
and
have
a
reporting
system.
For
those.
C
C
So
the
question
is:
if
you
made
a
mistake,
for
example,
in
or
there's
a
problem
with
your
with
your
module
graph
and
now
you're
doing
port
value,
the
hosts
should
be
able
to
provide
information
to
the
developers
that
something
went
haywire
with
variant
ports
and
at
that
point
no
code
user
code
from
inside
the
shadow
valve
would
have
executed.
So
there
is
no
way
for
the
shadow
realm
user
to
actually
do
its
own
reporting
of
that.
C
Errors
and
yeah,
so
it's
tonight
what
my
my
suggestion
was
like:
let's
try
to
find
a
way,
so
that's
host
errors
or
anything
basic,
any
errors
thrown
before
user
code
as
as
started
execution.
So
if
it's
an
evaluation
before
we
actually
evaluate
the
source
code
or
before
we
start
evaluating
the
source
of
of
a
an
imported
module,
any
errors
thrown
before
that
somehow
to
be
able
to
throw
them
with
full
information
in
the
incubator
realm
in
the
incubated
incubator
realm
well,.
D
C
D
So
I
I
think
I
agree
in
principle
that
we
we
could
get
this
done
for
the
purpose
of
reporting
those
errors
from
the
incubator
realm,
on
the
assumption
that
it
is
a
problem
in
the
in
the
operation
that
the
incubator
realm
is
trying
to
carry
on,
which
is
importing
a
value.
But
it's
importing
a
value
that
cannot
be
resolved
by
by
the
the
rom.
So
the
error.
D
C
Yeah,
I
so
I
think,
shu
put
something
on
the
agenda
for
the
next
plenary,
which
is
basically
trying
to
answer
from
some
questions
in
general,
like
whether
in
general,
stacks
they're
not
specs.
Currently,
but
if
it's
something
that
should
be
available
through
the
callable
battery
some
information
that
should
be
available,
whether.
C
Is
information
that
should
be
available
through
the
coldwell
bindery?
I
I
think
in
in
general,
my
opinion
is
still
shadow.
Realm
is
a
low-level
api
and
the
callable
vendor
itself
in,
as
in
the
wrapper,
the
wrap
functions
should
keep
denying
thrown
objects
whatever
they
are,
even
if
they
are
error,
objects
and,
and
so
and
and
that
would
result
in
an
opaque
typer.