►
Description
A
Know:
okay,
if
there's
no
announcements,
let's
move
on
to
the
agenda
items.
The
first
one
is
tagged.
It's
24,
347
make
compat
finished,
match
easy
to
be
won.
Let
me
just
take
a
quick
look
that
one
I
think
this
is
still
waiting
on
Anatoly.
He
he
had
some
concerns
over
the
PRA
had
stalled,
which
is
why
it
was
tagged
for
the
agenda,
but
he
is
working
on
it.
It
sounds
like,
and
you
know
he
commented
as
recently
as
yesterday,
that
he'll
have
some
more
information
in
terms
of
tests
and
so
forth.
So.
A
So
now
trot
needs
to
be
loaded,
yeah
I'm,
just
there
we
go
come
on:
okay,
okay,
so
moving
on
to
the
next
one,
which
is
new
new
core
modules,
go
underneath
state
namespace,
which
is
20155
one
I'm
gonna,
take
a
quick
look
to
see
who
tagged
that
for
the
agenda.
I
know
this
is
a
fairly
long
standing
issue,
but.
A
B
His
mic
is
not
working
so,
and
he
says
in
the
chat
for
me
to
just
take
it
away.
There
you
go
so
namespaces
are
something
that's
coming
up
a
couple
times.
I
know
that
we
didn't
discuss
it
that
much
this
year
at
the
collaborator
Senate
that
last
year
in
Berlin,
was
where
we
had
actually
had
like
a
longer
conversation
about
it
in
2018.
B
This
came
up
initially
like
this
issue
around
the
time
of
HTTP
2
and
specifically
with
the
fact
that
us
introducing
new
modules,
potentially
shadowed
ecosystem
modules-
and
you
know
we
kind
of
got
off
easy
with
HTTP
2,
where
no
date
actually
broke,
that
module
and
the
module
author
decided
well.
If
you're
gonna
do
a
t2
that
I'm
just
not
going
to
bother
fixing
it,
so
we
kind
of
got
a
bit
of
a
mulligan
there.
B
B
So
the
discussion
started
in
there
around
like.
Could
we
create
a
node.js
namespace
somewhere,
where
we
could
put
a
reference
to
likely,
like
all
existing
modules
would
be
put
in
there
aliased,
but
also
like
that
new
modules
would
go
only
in
the
namespace
and
not
in
a
flat
namespace
like
what
we
do
today.
B
There
was
debate
at
the
time
there
was
kind
of
like
two
major
facets
of
debate.
One
of
them
was
what
was
the
mechanism
we
were
going
to
use
so,
like
did
we'd
want
to
do
at
no
J
a
slash
or
no
js'
colon
or
no
J's,
colon,
colon
or
hash
tag,
nut
juice,
hash,
hash,
bang,
bang,
bang
I,
don't
know
like
we
that's
an
obvious
place
to
start
bike.
B
Shedding
is
the
mechanism
itself
and
then
the
other
one
was
if
I
recall
at
the
time
some
individuals
from
the
technical
steering
committee
we're
not
convinced
that
we
necessarily
needed
namespaces
and
that
it
might
over
complicate
things.
So
since
then,
a
couple
other
things
have
have
come
up
which
have
shown
at
least
to
me
that
I
have
a
bias.
I've
always
wanted
them
that
namespaces
might
be
necessary.
B
One
of
them
is
the
PR
that
prompted
this
conversation,
the
PR
from
Gus.
That
would
allow
us
to
have
like
because
right
now,
NES
modules
because
of
the
way
in
which
we've
done
things
with
FS
promises.
You
need
to
import
promises
from
FS
and
then
D
structure.
The
promises
object
because
we
did
not
do
FS
/
promises.
B
Web
assembly
system
interface
is
being
set
up
to
be
in
a
namespace
called
Wahby
huazi
underscore
unstable
for
now,
but
will
eventually
be
Y
Z.
But
that's
using
the
mechanism
of
a
URI
type
scheme,
so
Y
Z
underscore
and
stable
:
there's
been
some
layered
api's.
That
then,
introduced
by
the
browsers
that
are
using
the
STD,
:
namespace
and
there's
also
stuff
going
on
right
now
within
tc39,
looking
at
standardizing
built-in
modules.
B
So
not
note,
and
the
namespace
mechanism
that
that
proposal
is
looking
at
is
also
the
URI
scheme
of
je
s,
:
the
idea
being
that
these
URI
schemes
can
be
taken
over
ty,
Ana
and
actually
standardized.
So
you
know,
if
there's
n
number
of
schemes,
those
schemes
can,
you
know
all
be
specified,
not
be
kind
of
random,
and
you
know
there
can
be
some
sort
of
schema
overall
I
I
still
very
bullish
that
this
is
a
thing
that
we
should
do
I'm,
also
very
bullish
that
we
should
follow
suit
with
no
J's
:.
B
Well,
none
of
the
other
things
in
the
ecosystem.
Have
you
know
like
officially
landed
with
that.
I
am
not
hearing
a
lot
of
pushback
elsewhere
in
the
ecosystem
around
this,
and
we
could
kind
of
take
lead
in
showing
hey
we're
going
to
use
this
mechanism
and
I
personally
be
happy
to
head
over
to
Ayanna
and
try
to
get
the
namespace
mechanism
standardized.
B
C
C
Yeah
I
mean
I
I,
don't
see
why
we
wouldn't
be
able
to.
The
question
is
just
what
do
you
put
behind
there
so
saying
this
was
required
for
I?
Think
the
PR
still
hoping
to
add
a
mine
types
module
to
node,
in
which
case
is
that
entire
module
done
experimental
or
not
I
think
that's.
The
thing
that
we
would
be
needing
to
be
decided
upon
is
like
what
we
would
actually
put
there
behind
it.
B
So
we
could
potentially
reach
out
to
those
folks
and
see
like
how
much
was
expected
to
be
written
by
the
host
and
and
how
much
would
be
by
the
VM
to
ensure
that
we're
not
doing
too
much
but
either
way.
I'd.
Imagine
it'd
be
like
a
refactor
and
performance
boost
in
the
future.
If
this
ends
up,
you
know
like
in
v8
itself,
I
think
we
could
put
it
behind
a
flag
rich
if
we
wanted
to,
but
the
second
that
we
start
landing.
A
B
Some
of
the
loudest
folks
were
not
even
collaborators.
Okay,
the
loudest
objections,
I
believe,
like
Jordan
hardened,
had
concerns
about
namespaces
it's
his
PR,
but
I
was
one
who
kind
of
was
working
on
it
because
it
needed
some
refactoring
from
the
initial
implementation,
which
was
based
on
the
file
system.
I
can
talk
to
Jordan
and
see
where
he's
at
I
know
that
folks
from
NPM
came
in
with
you
know,
pretty
strong
opinions
that
we
should
be
following
suit
to
how
NPM
has
done
namespaces
with
at
nodejs
slash.
B
B
Rest
of
the
platform's
going
seems
to
be
airing
a
direction.
You
know
that
I'm
pitching
on
this
PR
and
I
really
don't
think
that
using
the
NPM
namespace
is
a
good
idea,
especially
since
we
have
other
people
in
the
project
talking
about
wanting
to
publish
modules
in
the
ecosystem
to
that
namespace
as
well.
But
I
really
don't
think
that
we
should
be
doing
you
know
publishing
things
to
at
nodejs
slash
on
npm,
if
that's
the
namespace
we're
going
to
be
having
built-ins
under.
E
Can
ask
you
about
that?
I
mean
I,
I
kind
of
like
the
node.js
code
and
I.
Don't
have
any
problems
with
it,
but
to
me
using
at
nodejs.
You
said
that
we
don't
we
shouldn't
be
doing
that,
but
it
isn't
it
kind
of
nice
if
all
of
our
modules
are
in
the
same
namespace,
whether
we
compile
them
into
node.js
or
whether
you
install
them
from
NPM
jsg.
It
would
even
allow
us
to
do
both
like
for
backwards
compatibility
like
for
old
LTS
releases.
B
I
mean
personally
I
think
that
it's
really
important
to
have
a
distinguishing
thing
between
things
that
are
taking
from
the
registry
and
installed
via
NPM
versus
things
that
are
built
into
our
platform.
I
mean
there's
no
reason,
for
example,
that
if
we
start
breaking
things
out
and
then
during
them
in
that
we
couldn't
have
a
combination
of
both.
So
if
we
take
a,
we
think
about
something
like
fetch
which
hasn't
landed
yet,
but
I'll
use
that
as
an
example
since
we're
looking
at
ven
during
it.
B
It
feels
really
odd
to
me
that
the
same
specifier
could
be
a
built
in
or
not
a
built
in,
depending
on
the
version
that
you're
running
on
it
also
seems.
It
would
seem
odd
to
me
that
the
same
mechanism
for
reaching
built-ins
could
mean
something
difference
between
things
that
are
built
in
versus
things
that
are
published.
B
The
modules
that
we
have
that
are
built
in
are
maintained
by
us,
and
you
know
like
have
a
certain
level
of
maintenance
expectation
that
I
don't
know
if
the
ecosystem
modules
that
we're
talking
about
publishing
will
have
the
same
degree
of
care.
I
think
there's
also
a
question
regarding
bugs
and
vulnerabilities
like
will,
if
we
start
publishing
ecosystem
modules.
Well,
there's
ecosystem
modules
falling
like
nodejs
cores
vulnerability,
or
will
it
be
an
ecosystem
vulnerability
who
will
be
managing
those
like
the
second
that
we
start
conflating
those
things
it
just
seems
odd
to
me.
B
E
F
So
I
have
a
question:
that's
I,
guess
more
on
implementation.
Detail
are
we
so
we
have
right
now,
a
bunch
of
like
module
names
that
start
with
underscores
and
we're
kind
of
exporting
callback
based,
api's
and
then
now
adding
promises.
Could
we
use
this
as
an
opportunity
to
only
export,
like
es6
modules,
using
promises
api's
to
kind
of
clean
things
up
a
bit?
I.
B
Think
yeah,
that's
a
yes
and
a
no!
I
think
that
we
definitely
should
clean
up
in
the
sense
of
like
we
could
limit
the
modules
that
we
export
on
that
namespace.
But
then
I
don't
think
that
we
should
take
it
as
an
opportunity
to
like
replace
all
the
api's,
especially
if
we
want
people
to
upgrade
to
use
the
namespace.
It
would
be.
B
Mele
would
not
I
do
not
think
it
would
be
a
good
idea
to
make
like
node.js
:
FS
by
default,
the
promises
export
we
could
do
like
node.js
:
promises,
slash
FS,
which
was
something
that
I
was
thinking
of
doing
and
we
could
eventually
I
guess,
switch
that
we
could
have
promises
and
callbacks
or
something
we
could
think
of.
Like
nice
scheme
there,
but
I
am
I
I.
B
C
B
Yeah
and
I
guess
something
that
we
could
do
if,
like
to
what
rich
said,
if
we
put
if
we
start
with
namespace,
and
we
do
it
as
an
experimental
API,
so
we
at
least
like
work
out
the
mechanism
of
the
namespace
itself
and
how
we
handle
the
namespace.
If
we
put
that
behind
a
flag,
we
always
could
revisit
like
what's
being
exported
in
that
namespace
at
a
later
time,
as
its
own
discussion.
D
B
A
D
B
A
semi
I
mean
like
the
switching
from
at
no
geo
/,
no
J's,
:
you'd
like
a
set
expression.
It's
not
actually
a
huge
deal.
I,
don't
know
that
the
way
in
which
we're
doing
it
in
that
PR
is
the
most
efficient
way
to
do
it.
There
is
a
lot
of
noise
in
that
PR,
so
it
may
make
sense
to
close
that
PR
and
open
a
new
one
just
to
kind
of.
Like
start
the
conversation
fresh.
That's.
A
B
So
let
me
I
can
follow
up
with
Jordan
one
that
I'm
heading
out
on
vacation
soon
so
I'm
in
the
next
like
two
weeks
and
then
I'm
gone
for
like
a
month,
and
so,
if
someone
else
wanted
to
pick
this
up,
you
know
they're
they're,
welcome
to
I,
don't
know
if
this
is
extremely
time-sensitive.
I
feel
like
it
can
maybe
wait
until
August,
but
if
I
can
find
time
between
now
and
when
I
leave
to
kind
of
get
the
ball
rolling
on
it,
at
least
so
we're
unblocked
on
what
to
do
next.
A
A
The
next
one
698
doc
update
the
TSA
charter
that
one
I
believe
in
the
last
well
in
the
last
CPC
meeting
we
did
discuss
and
it
sounds
like
it's
ready
to
land.
There
is
a
PR
going
through
to
just
clarify
charter
changes,
so
I
think
it
may
be
worth
just
waiting
for
that.
So
that's
in
progress
and
then,
finally,
we
have
our
strategic
missions,
reviews.
A
B
Pr
for
the
exports
proposal,
the
experts
proposal
would
allow
us
to
have
an
experts
field
in
the
package.json
and
that
would
allow
you
to
specify
all
of
the
deep
exports
of
the
module.
So
when
you
do
like
import
lo
slash
slash
for
each
so
it's
a
mechanism
to
allow
you
to
specify
all
of
that,
because
we've
removed
file
extension
resolution
by
default
and
because
you
know,
when
you're
deeply
searching
from
the
module
that
always
has
to
come
from
the
root.
B
This
would
allow
you
to
specify
you
know
like
any
file
within
the
module
to
be
a
specific
export.
This
also
pairs
very
nicely
with
import
Maps.
So
this
this
information
would
be
able
to
be
used
by
both
node
and
the
browser.
The
other
thing
that's
really
nice
about
it
is
by
default.
It
will
make
it
so
that
only
the
paths
that
are
exported
are
the
ones
that
can
be
reached
now.
This
is
not
foolproof.
You
know
you
could
always
reach.
B
Do
a
deep
reach
directly
into
the
node
modules
folder
to
get
whatever
you
want,
but
this
would
create.
This
does
create
a
little
bit
more
of
an
explicit
contract
of
a
public
versus
private
API
surface,
which
is
not
something
that
currently
exists,
so
that
landing
is
the
last
of
two
bits
that
and
some
work
that
we're
doing
right
now
on
custom.
Loaders
are
the
last
two
bits
that
I
think
we
really
need
to
do
before
unflagging
modules.
A
B
Probably
could
drop
it
at
this
point.
I
think
the
last
thing
that
we
were
leaving
it
on
there
for
now
about
was
making
sure
that
we
had
the
charter
changes
in
place,
but
I
think
that
we've
done
that
and
I
think
that,
like
devoting
for,
like
we've,
mostly
covered
all
that
stuff,
so
I
think
we
probably
could
remove
it
at
this
point.
A
C
So
there's
kind
of
like
a
couple
things
going
on
at
the
same
time,
not
necessarily
related
to
the
new
streams
initiative,
but
kind
of
relate
to
streams
initiatives
in
general.
So
there's
a
continued
thing
with
there's
now
a
PR
open
for
stream
transform
dot
by
to
allow
you
to
better
use
existing
streams
with
async
function,
generators
which
is
pretty
neat,
also
kind
of
parallels
of
things.
C
Also,
I
work
on
my
sort
of
take
on
streams
things
the
Bob
streams.
So
in
the
time
since
Jay
has
come
for
you
there's
now
a
streams,
three
adapter,
so
you
can
pipe
streams.
Three
streams
to
this
new
streams
thing
and
back
again,
as
you
wish,
and
also
I,
am
presently
working
on
getting
full
automated
tests
up
for
the
sort
of
spec
repo,
which
is
I,
think
that's
what
fish
market
one.
B
A
B
B
P.M.
UTC
so
2:00
p.m.
Eastern
Time,
11:00,
Pacific,
8:00
p.m.
central
Eastern,
a
Central
European,
so
we're
doing
bi-weekly
meetings.
The
first
one
was
yesterday.
We
didn't
really
go
through
too
much.
It
was
like
a
really
high-level
discussion
about
like
what
would
we
like
to
do
what
our
programs
we
could
run.
The
open
J's
Foundation
has
a
partnership
with
both
Aetna
as
well
as
w3c,
but
we
can't
just
make
that
like
an
open
thing
that
anyone
can
go
and
do
so,
it's
like
how
do
we
decide
who
would
be
representatives?
B
How
do
we
make
sure
that
all
of
the
projects
that
want
to
participate
or
want
representation
are
accurately
in
being
representative?
How
do
we
make
sure
that
people
who
are
doing
work
are
able
to
attend
the
results?
A
discussion
about
some
of
the
work?
That's
being
done
right
now
around
like
outreach.
So
how
do
we
make
that?
B
What
was
I
gonna
say
this
is
actually
related
to
namespaces,
but
if
we
end
up
having
a
built-in
namespace
for
the
Java
platform,
there's
discussion
about
like
domains
and
like
who
should
be
able
to
publish
to
namespaces
and
there
might
be
a
need-
and
all
of
that
for
a
neutral
party
that
isn't
one
of
the
standards
works
to
be
a
place
that
that
kind
of
maintains
a
registry
of
what's
aloud
or
what's
registered
in
built-ins
and
I.
Think
that
there's
room
potentially
for
the
open,
J's
foundation
to
be
that
third-party.
B
So
you
know
these
are
the
kind
of
problems
that
we're
looking
at
engaging
in
in
general.
If
nodejs
has
needs
to
either
attend
standards
meetings
or
to
you
know
have
things
handled.
This
would
be
a
great
place
to
open
them,
but
you
know
like,
as
always,
we
do
have
a
lot
of
people
on
the
committee
now
and
in
the
project
as
a
whole
who
participate
in
these.
B
So
you
know
you
should
still
always
feel
comfortable
to
come
to
myself
or
James
or
other
folks
who
have
participated
in
the
standards
orgs
to
help
make
sure
that
you
know
the
things
you
care
about
are
said,
but
also,
if
you're
interested
in
coming
and
participating.
You
know
I'm
happy
to
sit
down
and
kind
of
go
through.
What's
the
process
getting
involved
and
help
try
to
like
coach
you
or
come
up
with
a
plan
for
your
organization.
If
you
want
to
approach
it
from
that
that
angle,
rather
than
from
the
Foundation's
angle,.