►
From YouTube: SES-mtg: Endo design
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
C
It
is
indeed
alright
welcome
to
weekly
cess
meeting
okay.
So
in
previous
week,
I've
discussed
proposing
adding
a
a
load
method
to
the
compartment
API,
and
the
purpose
of
the
load
method
would
be
to
induce
the
loading
of
all
of
the
modules
needed
to
execute
a
particular
entry
point
such
that
after
the
promise
returned
by
load.
You
could
immediately
call
import
now
and
be
guaranteed
that
the
working
set
was
already
there.
C
We
would
like
to
be
able
to
construct
an
archive
of
an
of
an
entire
application
that
can
be
executed
on
a
chain
or
and
I,
and
there
are
obvious
applications
of
the
same
idea
for
just
a
straightforward,
constructing
bundles
for
production
of
a
particular
web
application.
So,
basically
providing
the
mechanism
that
it
would
allow
you
to
use
the
compartment
API
in
order
to
implement
something
like
browserify
or
or
web
pack
or
or
roll-up
or
whatever
or
what-have-you,
with
the
intention
of
surfacing
individual
modules.
C
C
Okay,
all
right,
so
this
is
a
straw.
Man,
I'm
calling
endo
as
endo
is
means
within
right
and
it's
an
anagram
of
node
or
Dino,
and
you
know
it
implies
much
more
than
it
is,
but
so
I've
posted
a
stack
of
changes
that
would
allow
us
to
execute
node
style
applications
in
with
one
compartment
for
package
and
a
similar
similar
to
the
way
that
you
can
do
lava
mo,
except
this
would
basically
be
a
reimplementation
of
the
core
of
laga
mo
in
terms
of
the
compartment
api,
and
so
it
would
provide.
C
Let
me
show
you
probably
best
place
to
start
is
the
design
this
this
depict?
The
each
of
these
is
one
of
the
functions
that
is
part
of
the
public
api
of
the
endo
package,
so
import
from
path,
load
from
path,
write,
an
archive,
make
an
archive
and
get
the
bytes
or
parse
an
archive
from
bytes
load,
an
archive
from
the
file
system
or
execute
an
archive
and
end
the
sort
of
the.
There
are
three
major
use
cases.
C
One
is
I
want
to
execute
an
application
off
of
the
file
system
as
if
it
were
node
calling
it
as
if
you
were
saying
node
in
the
name
of
a
file.
That's
the
entry
point
module
and
then
right
archive,
which
would
be
the
same
thing
except
instead
of
executing.
It
creates
a
zip
file
and
then
import
from
archive
which
takes
that
zip
file
and
accepts
whatever
endowments.
C
You
want
and
built-in
modules
to
thread
into
that
and
then
resume
as
if
it
had
been
loaded
from
the
file
system
up
front
and
in
order
to
make
this
work.
There
are
a
couple.
There
are
a
small
number
of
common
common
facilities
that
make
all
of
this
possible,
though,
that
the
asterisks
is
denote,
components
that
are
used
in
the
workflow
for
each
of
these
functions.
C
So
first
up
is
finding
the
package.json
that
is
in
the
containing
directory
for
the
module
that
you
wish
to
execute
as
your
entry
point
and
then
constructing
a
compartment
graph
and
the
way
this
works
is.
It
goes
to
the
package.json
and
looks
at
its
dependencies
of
array
or
dependencies
object
as
it
were,
and
then
does
as
node
would
search
up
the
up
the
parent
and
ancestor
directories
until
it
finds
a
an
existing
package.
Jason
under
node
modules,
package,
name,
package,
jason
and
then
builds
that
out
transitively
until
it
has
all
of
the
package
Jason's.
C
C
So
there's
a
section
in
the
compartment
map
for
every
compartment
that
needs
to
be
created
and
all
and-
and
it
contains
an
array
of
all
of
the
modules
that
need
to
be
or
permanent
object
that
describes
how
to
construct
the
module
map
for
that
compartment
by
linking
it
to
the
exports
of
other
compartments
and
then
assembling.
The
compartments
is
just
a
matter
of
doing
a
traversal
over
the
graph,
constructing
all
of
the
compartment
objects,
and
then
you
call
load.
C
That
compartment
isn't
to
be
in
that
realm,
which
would
allow
you
to
have
some
of
the
flexibility
to
run
things
that
that
aren't
able
to
share
a
single
frozen
realm
and
then
tags
are
basically
does
this
design
is.
Is
this?
Is
this
an
is
this
a
compartment
map
that
was
built
for
browser
or
front-end?
Or
what
have
you
so?
C
In
order
to
to
do
parse
and
provide
the
static
module
record
and
then
the
modules
map
is
very
similar
in
it's
very
similar
to
the
module
map
that
gets
passed
in
through
the
compartment
constructor,
except
that
it
describes
the
compartment
name
of
the
compartment
that
provides
the
module
and
then
the
module
specifier
from
within
that
compartment.
And
then
there's.
There
are
clear
ways
that
you
could
extend
this
in
order
to
thread
built-in
modules
or
whatever
or
or
shim
modules.
C
C
We
might
be
able
to
use
this
as
a
foundation
for
lava,
moat
or
or
share
a
whole
bunch
with
lava
moat
for
the
static
analysis
of
all
of
your
packages
in
order
to
create
a
set
of
Mynt,
the
minimum
necessary
policy
in
order
to
thread
the
Empowered
built
in
modules
and
any
other
powerful
objects
in
and
even
whether
to
use
realms
or
compartment
or
the
frozen.
A
shared
frozen
realm
could
be
inferred
by
static
analysis
of
a
package
at
a
particular
version
and
constructive
policy
and
then
weave
that
policy
into
the
resulting
compartment
map.
C
C
You
wish
to
write
and
the
entry
point,
and
it
goes
through
the
process
of
collecting
everything
and
putting
it
in
a
zip
file
and
then
import
archive
give
a
you,
give
ability
to
read
you
give
the
path
of
the
archive
and
then
pass
endowments
and
modules.
So
those
are
the
those
are
the
three
major
use
cases
for
this
there's.
There
are
possible
ways
that
you
could
use
a
lot
of
the
same
internal
mechanism
to
then
also
implement
something
like
browserify
or
possibly,
some
other
more
interesting
things.
C
So
this
motivates
the
then
so
that
whether
the
core
of
this,
that
motivates
the
need
to
add
a
load
method
and
the
module
method
to
the
compartment
to
the
compartment
specification,
is
this
assemble
method
which
takes
the
compartment
map
and
and
and
a
function
for
making
an
import
look
for
a
particular
compartment
based
off
of
the
path
of
its
route,
module
that
goes
in
transitively
visits.
The
compartment
map
constructing
compartments
right
down
here
and.
C
Though
so
this
this
requires
the
use
of
the
module
function
in
order
to
thread
the
package
apartment
module
from
a
dependency
package
into
the
module
map
of
of
the
dependi
compartment,
and
so
this
this
function
in
here
is
going
through
all
of
the
modules
that
this
thing
depends
upon
and
injects
and
injects
the
module
namespace
object
into
its
module
map
and
then
then
constructs
it.
And
then
then
you
can.
Then
you
can
execute
the
compartment
at
the
you
can
execute
the
module
at
the
root
compartment.
C
C
C
And
the
implementation
of
this
change
is
just
this.
So,
as
you
can
see,
the
async
import
method
is
implemented
in
terms
of
an
internal
load
method
and
once
your
trend
and
once
your
working
set,
has
fully
loaded,
it
then
uses
import
now
to
execute
that
module
and
any
of
and
all
of
them
all
of
the
modules
it
depends
upon
that
have
not
yet
already
executed
and
then
returns.
The
module
namespace
load
is
just
the
front
end
of
that.
Without
the
back
end
exposed
they
are
without
the
execution
at
the
end
and
yeah.
B
Archive
or
import
the
thing
that
imports
the
from
the
zipa
mm-hmm
and
the
thing
that
generates
with
zip
file
and
in
general,
anything
that
does
file
I/o
in
your
API.
You
have
it
being
passed
a
file
system,
you
know
an
FS
method
of
some
kind,
FS
object
of
some
kind
and
a
path
name
in
a
Mauro,
Cappy
style,
and
then
this
may
not
get
along
with
the
zip
library
that
you're
using.
C
C
Trick
in
this
particular
case
is
that
the
user,
who
calls
node
in
a
file
name,
does
not
actually
know
where
all
of
the
transitive
dependencies
are
and
is
not
in
a
position
to
specific
authority
to
specific
individual
files.
The
the
right
archive
method
in
the
import
path
method
both
require
the
ability
to
explore
the
file
system
to
find
where
all
of
those
packages
are
in
order
to
build
out
the
in
order
to
build
out
the
package
graph.
C
It
only
needs
the
ability
to
read
within
the
scope
of
that
archive
which,
which
greatly
attenuates
the
authority
of
the
of
the
mechanism
yeah
you
just
so.
For
that
case,
you
can
actually
use
parse
archive
yeah.
If
you
use
our
site
archive
directly,
you
just
give
it
a
bag
of
bytes
from
the
zip
file,
and
it
requires
no
further
authority
in
order
to
construct
the
compartment
graph
and
execute
it.
C
C
I'm,
assuming
at
the
moment
that
we
do
not
need
to
do
that,
the
my
presumption
is
that
the
entire
archive
can
fit
in
memory
which
seems
like,
which
is
a
reasonable
assumption.
Until
there
are
significant
assets
embedded
in
the
application.
It's
a
given
significant
non
code
access
embedded
in
the
application.
C
The
the
code
is
going,
something
that
the
the
application
will
require.
The
entire
working
sets
source
text
to
a
be
in
memory
at
some
point
may
be
immediately
discarded,
but
at
some
point
it
needs
to
all
be
in
memory
and
or
at
least
the
something
some
amount
of
memory
will
be
need
to
need
to
be
consumed.
That
is
proportionate
to
the
amount
of
source
code
in
the
archive.
C
So
I'm
not
worried
about
that
case.
I
would
be,
I
am
worried
about,
say
if
you
take
a
dependency
on
I,
don't
know
an
emoji
font
and
your
code
means
access
to
all
of
those
resources
at
at
that
point,
we'll
probably
need
to
come
up
with
something
more
clever
where
you
know
the
zip
file
gets
mapped
or
something.
C
A
C
Okay,
so
McGirt
has
not
mentioned
a
requirement
for
this.
Yet
why
I
imagine
that
there
I
imagine
that
we
will
eventually
need
to
be
able
to
embed
assets
and
archives
and
also
provides
some
and
and
and
that
this
system
would
need
to
provide
some
sort
of
API.
That
would
work
exactly
the
same
way
if
you
were
executing
it
and
development
locally
or
in
a
web
page
or
on
blockchain
and
I
I.
C
C
In
order
to
find
in
order
to
find
assets
in
the
same
package,
I
find
that
deeply
dissatisfying
I
know
that
shame
Dan
didn't
hang
around
because
he's
proposing
the
the
module
attributes
proposal
that
would
give
some
language
foundation
for
being
able
to
import
assets
into
modules
in
some
way
or
another.
A
previous
project
I
did
for
Motorola
and
montage
was,
did
it
have
an
ability
to
tune.
C
A
Think
wid
pack,
it
might
be
similar
to
what
you're
saying
about
browserify
in
that
year.
You
would
have
a
plugin
that
that's
external
to
your
application.
That
runs
as
part
of
the
web
pack
process,
which
understands
based
on
the
file
extension
how
to
acquire
that
file
and
incorporate
it
into
the
yeah.
C
C
The
montage
had
HTML
modules
that
were
and
that
the
concept
could
have
been
extended
to
CSS,
even
just
in
incorporating
CSS
and
HTML
into
the
module
system
in
order
to
build
whole
applications
with
these
multi-language
assets
is
very
powerful,
because
a
lot
of
these,
like
CSS,
doesn't
have
the
notion
of
a
linker
and
it
doesn't
have
a
notice
notion
of
a
package
manager.
So
a
reference
in
in
a
a
URL
embed
in
a
CSS
file
isn't
something
that's
portable
through
through
the
module
system.
A
What
can
I
ask
so
the
it
sounds
like
the
bonding
process
of
end
or
I.
Don't
know
if
it's
the
assemble
of
the
archive
side
of
things,
but
it's
requiring
that
the
application
code
is
running
if
I
understand
correctly
and
because
in
the
application
cards
inside
the
compartment
needs
to
call
the
import
hook
in
order
to
know
what
asset
gets
included.
Am
I
understanding
that
correctly?
A
C
C
It's
able
to
extract
the
shallow
of
dependency
references
from
the
source
text
and
then
present
that
to
the
compartment
API,
and
then
the
compartment
API
goes
and
visits.
Those
shallow
visit
visits
the
shallow
dependency
graph
to
create
the
whole
transitive
dependency
graph
without
executing
anything.
The.
A
C
C
Let's
just
say
that,
because
the
entry
points
are
not
discoverable,
there
is
not
much
meaningful
work.
You
can
do
with
dynamic
import
in
the
context
of
an
archived
application,
and,
but
you
could,
in
your
package,
Jason
described
all
of
the
valid
dynamic
entry
points
you
wish,
if
you're,
using
dynamic
import
for
lazy
execution,
lazy
loading,
which
is
a
which
is
a
common
use
for
dynamic
import,
is
added
to
like
what
is
it
called
nowadays,
oh
man,
splitting
what
web
pack
you
had.
This
has
this
feature
a
code.
C
Splitting
I
think
is
what
they're
calling
it
in
any
case
where
you,
where
you
can
have
explicit
explicit
check
points
where
you
provide
progressively
enhanced
behavior
while,
while
gradually
loading
in
the
behavior
of
the
application-
and
you
could
use
dynamic
import
for
that,
and
you
could
use
dynamic
and
port
front
that
inside
of
an
hour
application
you
just
need
to
give.
You
would
need
to
give
a
tool
like
the
endo
archiver,
a
hint
about
what
all
of
the
entry
points
are
going
to
be.
C
Those
are
the
trouble
with
workers
with
archiving
and
bundling
is
the
same
as
dynamic
import
right
where
your
entry
points
are
dynamic
and
they
might
even
be
on
the
web.
They
might
not
even
be
part
of
your
archive,
but
they
probably
ought
to
be,
and
if
that's
the
case,
what
but
yeah
and
then
and
then
there's
the
issues
that
that
when
you
do
a
dynamic
import,
what
knows
you
mean
you're
refer
as
your
module
refer,
but
with
a
worker
constructor,
you
passed
a
URL
and
what
is
the
worker?
C
There
there
are
more
interesting
complications
with
that,
because
there
are
three
I
think
sensible
worker
calling
conventions
to
which
I
say.
Let's
just
anticipate
that
there's
going
to
be
more
than
one
one
type
of
worker
API
exposed
in
package
Jason,
one
for
workers
that
communicate
with
an
I/o
stream
of
with
binary
data,
another
another
worker
API
that
communicates
with
an
object
stream
using
async,
iterators
and
another
one.
That
would
use
something
that
would
be
built
on
top
of
cap
TP.
C
Where
you
get
when
you,
when
you
instantiate
the
worker,
you
would
get
a
promise
for
the
module,
a
promise
for
the
exported
module,
export,
a
namespace
of
the
entry
module
of
the
worker
and
be
able
to
use
eventual
these
eventual
send
to
communicate
with
the
worker
and
possibly
possibly,
making
swings
out
of
work
swing.
Set.
Part
of
the
foundational.
A
Perhaps
workers
sort
of
fall
into
the
same
category
as
other
types
of
non
JavaScript
resources
and
at
the
way
that
they
loitered
at
run
time
is
different
from
it's
a
pickle
module,
as
you
say,
you
might
have
an
async
iterator
that
accesses
it
or
something
mm-hm,
maybe
CSS
and
HTML
imports
would
would
be
similar
and
that
you,
you
don't
have
a
JavaScript
API.
It
doesn't
export
into
a
JavaScript
API,
that's
directly
accessible
by
the
importer.
C
A
B
This
has
always
been
a
bit
of
a
hand
waving
and
then
a
miracle
happens
aspect
to
the
question
of:
where
does
the
code
actually
come
from
and
part
of
that
was
wanting
to
defer
to
not
to
not
commit
in
the
in
the
spec
to
any
particular
mapping
of
names
to
files
or
URLs
or
any
of
that
kind
of
thing
which
I
which
I
agree
with.
But
the
notion
still
remains
that
there's
going
to
be
some
kind
of
I/o
operation
to
get
bits
from
somewhere
and
that
was
always
kind
of
waved
off
as
oh.
C
Feel
like
I
feel
like
there
has
to
be
some
other
topics.
It
were
that
we're
forgetting
to
address
here,
oh
yeah,
if
it
sounds
like
there's
not
much
more
to
be
said
about
this
I'll
just
I'll
make
the
proposal
for
the
specification
and
refer
to
this
recording
for
the
explanation
of
the
design
and
also
to
the
the
design,
rationale,
documentation
and
yeah,
and
the
floor
is
open
for
topics
I
haven't
prepared
for.
C
From
in
preparation
for
tc39,
which
was
enormously
helpful
thanks
to
Alex
for
recommending
that
we
go
over,
that
I
know
the
the
focusing
specifically
on
the
the
q4
tc39
wasn't
the
original
intent,
but
it
was
certainly
a
useful
effect,
and
perhaps
we
should
actually
should
resume
in
that.
In
that
vein,
and
looking
at
some
of
some
of
the
other
proposals,
I,
unfortunately,
don't
have
enough
I,
don't
have
any
context
on
any
proposals
that
I
that
has
happened
in
the
last
five
years.