►
From YouTube: 2022-01-27-Next 10 years of Node.js - Mini Summit
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
So
welcome
to
the
node.js
next
10
mini
summit.
The
topics
are
modern,
http
and
documentation.
A
We
have
a
good
group
of
attendees
here,
so
I'm
thinking
that
it
would
make
sense
before
we
kick
this
off,
that
we
just
do
a
quick
round
table
to
introduce
everybody
so
that
you
know
those
those
of
us.
We
don't
who
don't
don't
each
other.
We
have
a
little
bit
of
an
idea
of
the
interest
and
you
know
where
you're
from
if
I
will
go
through
the
list
based
on
how
I
see
people
showing
up
in
the
participant
list
and
maybe
go
from
there
or
yeah.
A
B
B
What's
your
interest,
like
you
know,
oh
for
sure,
yeah
I
mean
I'm
interested
in
both
topics
today
and
and
particularly
the
documentation
stuff
is
it
you
know,
I
don't
know
what
we'll
actually
get
into
today,
but
particularly
as
it
relates
to
the
website
redesign
work,
because
that's
one
of
the
last
major
hurdles
on
that
effort.
A
Sounds
good
okay!
Next
up
chris.
C
Okay,
I'm
chris,
I
am
a
technical
consultant,
I'm
a
freelance
technical
consultant
based
in
lebanon.
My
main
field
of
expertise
is
nodejs,
I'm
currently
teaching
at
the
lebanese
american
university
as
well.
A
computer
programming
course
the
laboratory
and
just
as
joe,
to
be
honest,
I'm
quite
interested
in
both
topics,
but
specifically
the
logging
aspect.
D
I
maintained
the
thing
co-maintained
the
thing
with
ronak
at
this
point
the
http
stack
and
it's
as
bad
as
it
sounds,
so
we
are
probably
carrying
a
lot
of
the
dead
weight
between
the
two
of
us
of
keeping
that
thing
around
at
some
point
a
few
years
back
at
this
point,
I
thought
well
can
something
better
be
even
possible
and
that
proof
of
concept
as
becoming
a
real-world
project
that
is
being
downloaded.
D
I
think
750
000
times
per
month
at
the
latest
start,
which
is
so
it's
sorry
per
week,
so
750k
per
week
of
downloads,
so
yeah,
the
weekly
download
is
seven
five
five
thousand
per
per
week.
So
it's
a
pretty
good
and
steep
growth.
So
I'm
pretty
happy
about
the
trust
that
people
gave
on
this
on
the
project,
but
you.
E
D
Also,
it's
it's
doing
as
good
job
as
taking
over
from
from
the
core,
so
I'm
very
that
has
been
a
good
journey,
so
I'm
mainly
I'm
also
I'm
also
there
here
to
talk
about
fastify,
maybe
for
the
server
side,
I'm
the
lead
maintainer
of
fastify
created
that
thing
as
well,
plus
some
a
lot
of
work
in
the
diagnostic
space
back
in
the
days.
So
I
don't
know
spoke
too
much.
A
Sounds
good
thanks,
michael's.
F
A
Great
thanks,
beth.
A
H
Okay,
maybe
we'll
come
back:
manish,
hey
everyone,
I'm
a
final
year
student
here
at
india
and
I'm
a
part
of
the
website
free
design
team,
I'm
primarily
interested
in
docs
section.
I
Hello,
I'm
richard.
I
work
at
red
hat,
I'm
on
the
no
tsc
build
and
release
working
groups
and
yeah
I'm
following
following
along
just
to
understand.
If
anything,
sort
of
from
from
the
build
site
needs
to
keep
up
with,
say
the
documentation,
changes
or
anything
like
that.
A
Great
robert.
J
A
Great
thanks,
wes.
K
Hey
everybody,
I'm
wes,
keeping
that
camera
off
most
of
the
time,
because
I'm
on
some
slow
internet
here,
but
I
am
I
work
at
netflix
on
the
node.js
platform
team.
I
have
participated
for
quite
a
long
time
in
the
express
ecosystem
on
the
technical
committee
for
that,
although
I've
haven't
been
participating
very
much
for
the
past,
maybe
six
months,
but
I'm
excited
to
see
that
this
topic
is
continuing
for
a
little
bit.
K
I
think
maybe
robert-
and
I
mainly
jean,
was
also
on
there
quite
a
bit,
but
we
were
doing
the
http
server
frameworks
working
group
just
to
kind
of
explore.
I
think
this
same
idea.
That
was
maybe
a
year
ago.
Sorry
I
you
know,
had
to
step
back
for
a
bit,
but
I'm
really
excited
to
to
see
this.
You
know
continue
and
also
I
you
know.
Obviously
at
netflix
we
still
use
rustify
and
you
know
I'm
I'm
interested
to
see.
K
You
know
a
future
where
maybe
we
don't
you
know,
but
maybe
that
could
be
on
top
of
some
some
improvements
to
the
decor
or
maybe
that's
you
know,
on
top
of
fastify
or
some,
you
know
future
layer
where
we,
you
know,
have
a
little
bit
less
code
in
the
frameworks
and
a
little
bit
more
in
the
in
core.
You
know
so
that's
that's
sort
of
where
I'm
interested
in.
A
Okay,
thanks
roy.
L
L
Thanks
tierney.
M
Hey
everyone
tierney
siren
we're
get
microsoft
as
a
senior
co-developer
advocate,
focusing
on
javascript
and
node.
Do
node
tc39
electron,
openjs
foundation,
help
out
with
a
bunch
of
things
and
primarily
interested
in
docs,
but
also
very
interested
in
in
the
hdb
stuff.
So.
A
Thanks
jean.
A
I
guess
maybe
jean
is
having
trouble
with
his
microphone
I'll
go
last,
I'm
michael
dawson,
a
member
of
the
technical
steering
committee,
so
interested
as
a
maintainer.
I'm
also
the
the
lead
for
the
node.js
red
hat,
node.js
team
and
interested
in
in
both
of
these
topics.
In
terms
of
them
being
you
know
the
some
one
of
the
top
items
we've
identified
as
being
important
to
the
future
success
of
node.js
and
wanting
to
make
sure
that
we
have.
A
You
know
at
very
least
what
we
think
we
need
to
do
documented
on
those
critical
things
so
that
we
can
then
use
that
as
the
framework
to
figure
out.
What
can
we
do
and
how
do
we
progress
on
them?
A
So
I
think
that's
everybody
who's
on
the
the
call.
So,
let's
launch
into
the
agenda
itself,
so
the
first
topic
was
modern
http
and,
from
my
perspective,
the
starting
first
questions
are,
like
you
know,
is
the
state
of
our
http
implementations
good
enough
to
ensure
future
success,
or
are
there
things
that
the
project
should
be
doing
to
improve
them?
And
then,
if
the
answer
to
that
is
like,
we
need
to
give
significant
improvements.
Can
we
document
those
specific
things
that
we
should
you
know
that
would
improve
this?
The
current
state?
A
The
answer
could
be
that,
like
you
know,
I
know
there
was
a
working
group
looking
at
indicia.
Maybe
that's
already
all
sorted
out,
but
you
know
the
so
we
can
start
with
a
discussion
like
you
know.
Where
are
we
and
you
know-
maybe
it's
good
enough
or
maybe
we
know
of
some
things
we
need
to
do
so.
I
don't
know
who
want
to
sort
of
kick
off
with
their
opinion
of,
like
you
know,
the
current
state,
in
terms
of
you
know
where
we
stand
in
in
terms
of
what's
important
for
the
future.
D
Let
me
let
me
take,
let
me
take
it
okay,
I
so
I
just
want
to
talk
a
little
bit
about
http,
1.1
and
http
2..
This
they
have
two.
There
are
two
different
type
of
those
code.
Ways
are
slightly
different
that
different
problems:
okay,
so
http
one,
the.
D
Http1,
it's
it
has
a
new
http
parser.
So
it's
great
it's
way
better,
it's
more
robust,
okay.
So
this
is
a
good
improvement
compared
to
the
past
the
part
of
the
challenges,
so
it
but
http
one
is
plugged
by
design
decisions
that
have
that
are
a
decade
old.
D
So
it's
specifically
having
the
response
message
not
to
be
a
complete
writable
stream
and
the
while
the
request
is
readable.
So
those
are
the
fundamental
problem,
app
problem,
design
decision
problems
of
that
is
that
of
the
gp1
http
2,
it's
a
little
bit
more
modern.
However,
we
don't
have
much
people
maintaining
it.
D
D
To
fix
certain
bugs
and
improve
things,
okay,
so,
but
it's
there's
a
huge
pile
of
issues
in
the
tracker
about
it:
okay,
so
it's
even
some
fundamental
stuff
that
intersect
with
diagnostics
and
on
both
hp1
and
cp2.
So
it's
it's.
H
D
It
it's
an
interesting
topic
on
the
client
side,
the
main
one
of
the
major
problems
is
perform,
the
performance
of
the
http
client
and
it's
one
of
the
major
bottleneck
for
most
enterprise
applications
like
I
was
chatting
with
one
of
our
clients
yesterday
afternoon,
and
they
were
telling
that
the
proof
of
concept
that
they
did
migrating
to
wundi
from
http
from
the
old
request
model
module
to
mundici
was
a
reduction
of
reduction
of
latency
of
50
like
50
percent.
D
Those
are
significant
numbers
for
most
businesses,
so
I
then
I
will.
I
will
leave
ronic
to
talk
about
the
state
of
foundation
fetch
because
it's
probably.
D
More
of
his
baby
at
this
point,
but
I
activities
are
being
done
on
that
front
too.
So
it's
it's
good
to
see.
That's
all.
J
J
I
don't
know
if
it
would
be
a
good
idea
to
split
this
up
into
sections,
because
I'm
a
little
worried
that
the
scope
here
is
so
wide
that
if
we
try
to
talk
about
all
of
these
things,
at
the
same
time,
we'll
just
end
up
with
discussions
without
actually
reaching
anything.
A
I
I
think
your
suggestion
of
like
breaking
it
up
makes
a
lot
of
sense
to
me,
like
I
don't
know,
if,
like
does
you
mentioned
client
and
server
side,
does
it
make
sense
to
break
it
up
that
way
to
start
or
is
it
make
sense
to
break
it
up?
A
C
I
think
it's
going
to
depend
on
the
audience.
To
be
honest,
I
mean
for
me
it
does
matter
to
discuss
this
from
the
client
and
and
the
server
side,
but
it's
also
equally
important
to
discuss
the
differences
between
http,
2
and
http
3
and
when
that
move
would
be
made
and
why
it's
not
being
made
you
know.
So
that's
my
humble
opinion.
K
Yeah,
I
think
that
I
think
it
makes
sense
to
do
client
and
server
as
sort
of
a
major
breakdown,
but
maybe
we
could
just
quickly
tackle
the
the
http
one
three
part,
because
I
feel
like
that
spans
just
a
little
bit
of
both
and
might
be
like
a
good
foundation
for
the
other
two
conversations.
B
I
was
going
to
say
real
quickly.
You
know
just
keeping
the
context
in
mind
that
this
is
the
the
next
10
mini
summit.
So
definitely
thinking
about
what
what
what
we
want
to
be
achieving
in
the
in
the
future.
A
Yeah,
so
maybe
sorry
go
ahead
and
go
go
ahead.
Jim
michael,
I
was
just
gonna
say:
maybe
we
time
box
a
discussion
on
like
the
http
one,
two
and
three
then
go
to
the
client
and
server
and
then,
if
we
have
more
time,
come
back
to
the
http
123.
Does
that
sound
reasonable
to
people
yep
yep?
A
So
I
don't
know
like.
Maybe
we
choose
10
minutes
to
talk
about
those
and
the
challenges
and
see
where
we're
at
does
that
make
sense.
A
J
Yeah,
so
I
think
in
this
case
I
mean
http1.
We
have
to
do
one
way
or
another,
and
I
think
that's
here
to
stay
for
quite
a
while,
and
the
the
first
thing
I
would
like
to
bring
up
here
in
the
on
topic
is:
is
http
2
even
relevant
right
now?
Should
we
putting
our
focus
on
http
3
do
do
we
need
http
2?
Is
that
something
we
need
to
maintain.
K
So
I
raised
my
hand
to
say
this
has
been
just
a
we
I
feel
like
this
conversation
has
been
since
http
2
landed
in
in
node.
Like
look,
you
know
express
still,
doesn't
support
it.
I
don't
think
anybody
was
working
on
it.
Last
time
I
checked
in
on
on
the
project,
which
has
frankly
been
a
little
bit
but
like
there
was
just
not
enough
interest
from
users.
There
was
not
enough
interest
from
maintainers
and
then
speaking
from
my
user
perspective,
so,
like
you
know
at
netflix,
we
don't
really
use
it
like.
K
I
think
it.
You
know
it's
used,
I
think
under
the
hood,
maybe
for
the
grpc
stack
and
that's
like
the
main.
That's
like
the
only
thing
that
it's
used
for,
but
it's
like
so
abstracted
away
from
any
end
user
concerns.
It
could
be
a
third-party
module
for
all.
Again,
I'm
not
saying
that's
the
way
to
go,
I'm
just
saying
from
a
as
a
user
like.
K
If
I'm
removing
myself
from
the
maintainer
side,
I
don't
care
as
a
user,
because
I'm
not
going
to
be
going
in
and
making
a
new
http
2
server
with
just
node
core.
Like
I
just
am
saying,
I
don't
think
anybody
does
that.
I
have
not
seen
a
single
person
come
into
the
express
repo
in
years
and
say
they're
going
to
do
it
for
anything
other
than
a
toy
project.
So
my
take
on
that
is.
If
we
want
to
invest
in
it,
then
we
should
find
a
clear
use
case.
K
That's
going
to
have
real
world
applicability
before
making
that
that
investment,
and
I
say
I
say
that
saying
specifically,
I
think
the
grpc
use
case
is
great
but,
like
I
don't
think,
that's
enough
to
drive
investment
from
node
core
unless
we
can
get
the
grpc
folks
in
the
room,
saying
hey
here's
what
we
would
like
to
see
out
of
the
http
2
platform-
and
I
don't
know
if
anybody
else
on
this
call
is,
but
I'm
not
aware
of
anybody
who's
doing
like
heavy
work
in
the
grpc
space
right
now.
K
D
Yeah,
the
the
amount
of
companies
using
grpc
and
using
the
our
hdp2
driver
for
for
it
to
support
it.
It's
it's
massive,
so
it's
we
are
doing
a
good
service
to
have
this
in
the
in
the
runtime.
It's
a
good
place
where
that
that,
for
long
reason,
literally
every
cloud
that
says
tierney,
so
it's
it's
fundamental
that
we
keep
the
he
that
we
keep
some
http
2
capability
in
it.
Now
we
have
this
now,
the
code
base
can
be
improved
and
simplified.
D
But
from
my
point
of
view,
it's
at
this
point:
it's
not
it's
abstracted
from
it's
very
abstracted
from
the
end
user.
Okay,
that's
your
voice
is
totally
right,
but
nevertheless
it's
it's
a
good
thing
that
it
supports
a
lot
of
use
cases
so.
A
I
I
guess
the
question
from
what
west
had
said
would
be
like.
Is
there
things
like?
Are
there
shortcomings
that
affect
say
grpc
specifically,
and
if
not
you
know,
maybe
I
don't
think
it's
like
we're
saying
we're
going
to
rip
out
the
api,
but
maybe
as
a
project
we
say
you
know
it's
there's
not
necessarily
any
major
priority
to
change
it.
If
it's
got
doing
everything
mostly.
D
K
D
K
Yeah
yeah,
I
don't
mean
to
to
get
into
that.
I
I'm
you
know.
My
point
definitely
also
was
not
to
say
like
advocate
for
removal.
I
I
just
wanted
to
you
know,
give
the
perspective
that,
like,
as
far
as
I
can
tell,
no
one
is
directly
using
it
other
than
the
maintainers
of
the
grpc
library
and
people
using
it
for
toy
projects.
B
And
robert
had.
B
D
H
J
K
So
so
http
one
is
sort
of
the
foundation
of
all
of
the
like
pretty
much
future
application
development
still
right,
like
we're
talking
graphql
here
right
graphql
is
the
found.
Http1
is
the
foundation
of
that.
I
don't
see
that
changing
anytime
soon
in
the
popular
clients.
Mateo,
who
maintains
one,
maybe
has
a
different
opinion.
I
would
love
to
hear
that,
but
to
me
if
we
can
improve
http
1
in
support
of
the
graphql
style
use
cases,
I
think
that
would
be
still
pretty
beneficial
in
the
long
run.
K
K
J
N
I
mean
if
they
do
eventually,
but
we
can't
determine
when
they're
going
to
do
that.
You
know
and
just
because
we
say:
okay
go
to
hp3.
That
doesn't
mean
they're
going
to
so
you
know
we
have
no
control
over
that
particular
aspect
of
it.
K
Hp
also,
that's
a
pretty,
I
was
just
gonna
say:
that's
pretty
heavily
reliant
on
all
the
other
platforms.
Grpc
supports
also
having
a
path
forward
for
for
hdp
three
right,
and
I
I
don't
know
that
that's
true
today,
and
even
if
it
is,
I
feel,
like
that's
a
really
heavy
lift
for
us
to
make
our
decisions
based
off
of
okay,
fine.
N
In
terms
of
ecosystem
usage,
there
might
be
folks
using
hp2,
but
no
one
expects
that
to
grow.
No
one
expects
that
to
really
continue
the
the
the
momentum
is
definitely
moving
towards
http
3.
that
that's
a
reality.
N
So
everything
that
we've
said
so
far
about
hp2,
just
being
kind
of
steady
state
maintained
bug
fix,
is
only
I
think,
that's
absolutely
spot
on
with
hp
one.
Nobody
anticipates
there
ever
needing
to
be
a
like.
You
know
a
really
significant
new
hp1
feature
added
like
there
may
be
extensions
and
new
headers,
and
in
that
kind
of
thing,
but
hp1
is
hp1.
It's
not
going
to
change
where
we
do.
N
Focus
would
be
on
like
the
improvements
to
the
stream
support
like
if
there's
new
features
and
streams
and
stuff
that
need
to
be
supported
in
hp1,
then
then,
then,
yes,
those
things
make
their
way
over,
but
hp1
is
what
it
is
right.
It's
not
going
to
change.
A
The
other
question
I
I
have
to
is
just
like
when
we
talk
about
http
one
two
and
three
there's
sort
of
the
protocol
aspect
and
then
there's
the
api
aspect,
like
ideally
as
a
consumer
to
me,
I'd
like
to
not
really
have
to
use
a
different
api
for
each
of
those
three.
If
that
was
possible,
that'd
be
ideal.
A
So
I
I
wonder
about
people's
thoughts
on
that
perspective.
Is
it
that,
like
you
know,
in
terms
of
protocol
implementation,
it's
kind
of
like
yeah,
http,
1
and
hp3
are
the
important
ones.
Http
1
is
probably
done.
Http
2,
we're
saying
like
is
find
to
trade
is
done,
and
so
http
3
is
where
you
put
the
effort,
but
that
doesn't
mean
that
we
wouldn't
provide
we,
wouldn't
it
wouldn't
be
important
for
future
success
for
our
apis
to
evolve,
that
let
you
access
any
one
of
those.
N
The
challenge
there
with
hp1
the
key
challenge
I
mean
so
this
is
you,
know,
backing
it
up.
The
reason
in
hp2
is
implemented.
The
way
that
it
was
as
a
separate
api
from
hp1
is
that
in
node,
the
hp1
api
and
protocol
implementation
are
so
intertwined
that
you
cannot
separate
them
without
breaking
changes.
Significant
breaking
changes,
all
right,
you
know
it.
You
have
protocol
details,
bubbling
all
the
way
up
to
the
api
layer
and
and
leaking
out
to
to
to
users.
N
So
it
we
had
to
do
a
separate
api
in
order
to
introduce
hp2.
In
fact,
that
was
part
of
the
agreement
for
adding
http
2
is
that
we
would
not
touch
the
hp
one
api
that
was
there
and
then
hp3
comes
along
and
completely
changes
the
protocol,
and
you
know
many
aspects
of
it
at
every
level,
meaning
that
we
couldn't
even
reuse
the
hp2
stuff
for
hp3.
N
So
you
know
we're
kind
of
in
a
bind
at
this
point.
If
we
add
hp3
on
its
own,
it
has
to
be
a
separate
api.
N
N
It
would
be
yet
another
api,
but
would
allow
us
to
eventually
deprecate
the
hp1
and
hp2
apis,
not
necessarily
deprecate
but
say
those
are
what
they
are,
we're,
leaving
them
alone,
we're
not
extending
them,
we're
not
going
to
focus
on
them,
we'll
fix
bugs,
but
we
won't
evolve
them.
Here's
the
new
sack.
N
D
I
think
like
we
need
to
before
looking
at
it.
We
need
to
look
at
who
are
our
users
and
of
the
unified
apis.
Okay,
and
what
are
our
users?
Our
users
needs
with
our
users.
You
you
have,
that
is
the
client
of
the
server
okay.
So,
on
the
client
we
have.
Typically,
our
users
are
module
authors
that
develops
modules
on
top
of
our
low-level
apis,
to
make
it
more
user-friendly
and
implement
more
features
on
top
on
the
server
side.
Pretty
much
the
same,
so
our
target
users
are
in
fact
module.
D
Authors
not
like
final
end
users
on
the
client,
most
people
whatever
they
all.
There
is
only
one
request
that
is
coming
banging
on
our
door
every
single
day
that
pass
through,
which
is
a
put
fetching
core.
So
that
is
the
elephant
in
the
room
that
needs
to
be
completely
agnostic
of
the
protocol.
So
ideally,
it
should
be
able
to
support
http,
so
even
http
1,
the
gpu
http
3,
it's
so
high
level
that
is
designed
by
for
for
browser
consumption,
and
things
like
that.
D
Yeah,
no
I'm
I
just
wanted
to
mention
it
so
fetch
is
already
designed
for
with
that
in
mind.
Okay
for
the
client-
and
I
don't
think
we
need
like
the
low
level
apis-
are
needed.
100,
okay,
but
it's
mostly
something
where
we
have
a
lot
of
free
reign
on
in
how
we
want
to
design
them
and
work
with
them
and
so
on,
because
in
reality,
what
our
users
would
use
is
some
fetch
that
some
level
of
fetch
that
we
have
to
add
in
core.
So.
K
In
case
we
don't
get
back
to
it,
do
we
want
to
put
it
down
some
key
takeaway
here,
like
I
feel
like
the
takeaway
is
http.
2
is
in
for
lack
of
better
words,
maintenance
mode,
http
1
is
in
like
stable
protocol,
but
innovation
still
in
the
user
land.
You
know
the
the
high
level
api
and
then
http
3,
I
mean
right.
Am
I
doing
good
synopsis
of
what
our
takeaways
from
this
yeah.
K
A
A
Okay,
so
I've
got
that
and
I
think
we
will
have
some
more
time
to
sort
of
come
back
to
that,
but
I
think
we're
okay.
We
can
move
on
to
sort
of
a
discussion
on
the
client
side,
see
that
see
that
where
that
takes
us
and
then
sort
of
circle
back,
so
I
think
mateo
may
be
kicking
off
with
a
discussion
around
what
you'd
said
there.
N
It's
just
you
know,
I
have
to
say
you
know
not
just
with
node.
I
mean
we're
seeing
that
across
multiple
multiple
environments,
people
just
need
fetch
and
they
and
they
they
don't
want
to
think
about
exactly
which
version
of
the
protocol
isn't
underlying
it.
They
don't
care,
they
want
they.
They
want
that
to
be
discovered
automatically
by
the
implementation
right.
They
don't
want
to
have
to
set
it.
So
fetch
is
definitely
the
api
direction.
We
want
to
go
to.
D
Yes,
also,
there
are
a
few
notes
there.
They
want
a
good
detail
on
a
good
detail
of
information.
Sorry
they
don't
want
to
deal
with.
I
don't
know
maximum
number
of
connections
pools
and
all
those
things
okay,
like
most
of
the
a
lot
of
the
users
for
those
apis,
are
very
basic
and
we
need
to
ship
good
defaults
for
them.
That
would
perform
well,
essentially.
N
Yeah,
my
oh
overall,
what
I'm
saying
is
that
people
either
want
that
high.
You
know
that
that
high
level
most
things
are
done
for
them
fetch
api
or
they
want
a
really
low
level,
socket
thing
that
they
can
build
on
top
of.
So
they
can
just
make
all
those
decisions
themselves,
and
you
know
there's
very
little
in
the
in
very
little
in
the
middle
in
the
middle
ground
there.
So
we
give
them
a
socket
api
in
fetch
and
folks
are
good.
K
Yeah,
I
put
my
hand
up
sort
of
to
say:
hey:
we
we
don't
want
just
fetch,
but
I
also,
I
think,
I'm
maybe
to
james's
comment.
I'm
not
entirely
sure,
there's
not
a
middle
there.
So
so,
for
example,
you
know
we
we've
looked
at
moving
our
clients
on
to
got.
It
was
impossible
because
of
performance
reasons.
There
was
some
you
know.
Maybe
there
was
some
speculation
that
if
it
got
moved
on
to
indici,
that
would
help
solve
it,
but
that's
not
moving
on
to
fetch
right.
K
So
if
we
move
like
say
we
shipped
fetch
and
then
some
library
authors,
you
know
added
because
frankly,
like
we're,
never
we're
not
going
to
put
our
users
onto
purely
the
fetch
api.
They
need
a
ton
more
than
just
fetch.
You
know
offers
on
the
server
side,
and
so,
if
that's
the
case,
we're
going
to
be
using
a
library
interface,
even
if
it's
on
top
of
fetch
and
if
and
fetch
promise
based,
it
introduces
a
lot
of
the
same.
You
know
performance
concerns
that
we
have
and
we
do
not
want
to
maintain
hey.
K
My
daughter's,
in
the
background
we
do
not
want
to
rewrite
our
own
thing,
all
on
top
of
the
socket
like
I
mean.
Obviously
we
would
if
we
had
to
get
the
performance
profile
we'd
want,
but
then,
at
that
point
like
we'd,
be
either
replica
we'd
either
be
replicating
the
the
open
source,
stuff
or
we'd
need
to
rely
on
the
open
source
stuff
coupling
right
to
it,
and
I
don't
think
maintainers
have
got
want
that
low
level
right.
They
want,
I
think
they
want
somewhere
in
between,
like.
K
If
I
look
at
the
ndc
api,
it
really
offers
the
breadth
of
apis.
I
would
think
we
would
want
in
core,
because
you
can
go
basically
ratchet
one
step
down
at
a
time
from
the
high
level
api
all
the
way
to
a
much
much
lower
level
implementation,
and
I
think
that
really
is
what
we
should
continue
to
model
around
to
make
sure
we
serve
the
most
use
cases.
N
And
that's
fine,
you
know
I
didn't
mean
to
imply
that
the
the
that
middle
does
not
exist
at
all.
You
know
what
I'm
saying
is
kind
of
you
know.
If
we
look
at
80
20
rule
that
either
the
really
low
level
or
the
higher
level
you
know
fits
the
majority
of
the
of
the
cases
and
and
I'm
sure,
there's
there's
definitely
some
middle
ground
there.
For
you
know
for
that
remaining
20
use
cases.
A
One
quick
question:
I
would
have
on
those
the
lower
level
api
and
the
induci
level
api.
Is
it
possible
to
have
those
be
agnostic,
2,
1,
2
3
as
well.
N
For
all
three,
the
http
semantics
remain
the
same.
It
really
just
goes
into
the
where
it
starts
to
get
a
little
murky
is
in
the
connection,
connection
management
pieces
since
hb1
is
you
know
just
the
assumption?
Is
you
know
one
request,
one
one
connection,
you
know
if
we
ignore
the
pipelining
there,
but
with
two
and
three
they're
expected
to
be
persistent.
D
At
this
point,
so
the
way
things
apis
are
are
layered
up
in
on
the
c.
There's,
that's
not
a
big
problem
in
in
supporting
that,
because
you
can
have
literally
have
http
3
pool
implementation
and
that's
what
automatically
you
don't
need
the
pull
logic
that
like
sorry,
you
can
have
an
http
client
implementation
without
having
the
pool
the
pool
implementation
for
http
for
http
3.
You
just
have
the
client,
because
the
client
is
enough.
Okay.
So
it's
why
you
need
the
pool
for
for
http
one.
D
That's
not
the
problem
now.
You
might
still
want
to
have
a
pool
for
http
3,
just
with
different
logics,
okay,
and
I'm
mentioning
it
because
there
is
still
even
though
you're
using
the
same
socket.
So
given
that
you're
using
the
same
socket,
there
are
operating
system
limits
on
the
amount
of
data
you
can
buffer
on
the
short
end
and
all
the
other
things
that
might
want
to
point
you
to
having
multiple
sockets.
Anyway,
I
mean
that's.
N
Yeah
any
other
issue
with
hp3
I
mean
it's
technically
connection-less
connection
pool
doesn't
necessarily
make
sense.
We
just
have
to
be
able
to
maintain
the
persistent
sessions
and
the
other
complicating
factor
there
with
hp.
3
is
that
it
survives
network
changes.
So
if
you
switch
off
of
you
know,
yeah.
D
N
Right,
if
you
switch
off
wi-fi
to
to
mobile.
D
D
Exact,
that's
what
that's
what
I
said
like
the
apis
that
ronald
and
myself
have
designed
is,
I
think,
is
super
robust
in
that
sense,
unfortunately,
there
was
not
much
interest
as
wes
said,
to
to
add
the
http
2
layer
like
a
few
people,
I've
tried
and
they
just
you
know,
the
effort
was
not
worth
the
reward.
It
seems
so.
K
I
just
re-raised
it
just
to
make
a
point
on
that
and
I'm
not
sure
how
valuable
it
is
to
talk
a
lot
about.
But
if,
if
interest
is
the
problem,
I
think
you
know
going
at
that
from
a
end
user
backward
perspective
is
probably
a
good
idea
like
if
we
you
know,
wanted
people
to
start
moving
their
hdp
node.
You
know
node
to
other
service.
You
know,
usage
onto
http,
2
or
3.
K
like
what
we'd
want
to
do
is
like
hey,
here's,
a
graphql
implementation
that
is
five
times
faster
because
we
re-implemented
it
on
top
of
the
http
3
stack
and
like
here's,
a
great
blog
post
about
how
we
did
it
and
like
sell
people
on
the
you
know,
end
user
experience
and
then
work
our
way
back
to
getting
support
to
getting
support
commitment
from
users
to
like
keep
maintaining
the
the
core
layers,
because
I
think
that's
where
we
went
wrong
with
http
2.,
it's
like
at
first.
K
There
was
just
nobody
using
it,
so
nobody
cared
to
support
it,
and
then
it
went
that
state
went
on
basically
long
enough
that,
like
really
the
only
people
we
would
have
been
able
to
wrangle
in
to
getting
to
support.
It
would
be
the
grpc
folks
and-
and
that
was
just
not
really
right
so
like
if
we're
gonna,
if
we're
gonna,
go
toward
the
client
and
really
getting
a
lot
of
commitment
from
you
know,
companies
and,
and
you
know,
end
users
to
come,
contribute
back
into
core.
K
N
I
kind
of
disagree
with
that.
You
know,
because
we
did,
we
did
go
out
there
and
we
talked
about
hp2.
We
showed
demos,
we
you
know
we
we
we
talked
about
the
benefit,
but
the
the
the
reason
it
really
never
picked
up
was
largely
because
of
the
ietf
and
the
way
that
the
browsers
handled
it
the
browser,
the
browser
implementers
from
the
beginning,
where
we
don't
care
about
developers
actually
using
this
directly.
We
want
it
to
be
hidden
behind
everything
and
nobody
should
have
to
care
that
it's
there
and
then
immediately.
N
The
ietf
started
talking
about
hp
and
the
the
benefits
of
hp2
as
a
protocol.
The
way
it
was
designed,
never
materialized.
I
mean
they
and
that
had
nothing
to
do
with
nodes
implementation.
It
had
to
do
with
the
the
the
fact
that
it
was
just.
You
know
the
the
benefits
that
the
working
diet
working
group
had
originally
had
in
mind:
never
really
actually
materialized,
particularly
with
the
head
of
line
blocking.
N
You
know,
and
a
certain
type
of
network
network
environments,
that
kind
of
thing,
so
they
immediately
started,
jumping
on
hp3
and
that
ended
up
and
that
alone
killed
the
momentum
on
on
hp2.
N
So
but
I
mean
you
know,
for
the
most
part
yeah
I
mean
yes,
it'd
be
great
to
have
an
hv3
implementation.
There
we
start
putting
some
demos,
we
start
showing
that
you
know
hey
the
benefits.
Are
there?
You
know
I've
had
the
the
pull
requests
there
for
a
while,
as
far
as
I
know,
only
one
person
has
looked
at
it,
they're,
not
even
a
core
contributor.
N
It's
massive
pr
granted,
but
you
know
you
know
it's
there.
People
can
start
playing
with
it.
A
A
little
bit
is
like
a
clear
focus
on
the
apis.
We
still
think
is
is
about
you
know,
add
value
like
it
sounds
like
innovation
around
the
api
and
how
you
consume.
It
adds
value.
The
protocols
themselves
is
a
bit
more
based
on
demand
and
if
we
came
up
with
a
way
where,
like
we
had
an
api,
that
was
not
specific
to
the
protocol,
but
you
could
use
one
two
or
three
and
then
the
actual
implementation
of
that.
Behind
that
those
apis
was,
you
know
as
as
demand
and
interest?
A
I
don't
you
know,
I
don't
know
if
that
would
end
up
with
like,
like
one
of
the
challenges
I've
heard
is
like
well
http
2,
there
haven't
been
enough
maintainers
and
that's
kind
of
driven
by
interest,
and
is
that
because
it's
kind
of
its
own
api,
its
own
thing,
would
that
be
lessened.
If
we
had
a
single
api
with
the
different
protocols
behind
it,
I
don't
know.
N
Yeah,
so
it's
hard
to
say
you
know
the
one
thing
you
know:
for
the
most
part,
most
client-side
users
shouldn't
have
to
care
what
what
version
of
the
protocol
mean?
They're,
not
the
one
making
the
decision
anyway
about
what
protocols
is
to
be
used
even
on
the
server
side.
Most
server-side
folks
should
not
have
to
care
at
all
right,
they're,
not
necessarily
the
ones
making.
N
The
decision
on
which,
which
version
of
the
protocol
to
use
you
know
is
so
there's
got
to
be
some
middle
ground
there,
where
we
can
make
it
eliminate
the
the
need
to
know
what
protocol
you're
using
on
both
the
client
and
the
server
side.
A
K
I
very
strongly
agree
with
that.
I
think
that
was
sort
of
the
idea
behind
the
multi-layers
of
apis
that
we
had
been
talking
about
in
the
http
server
observer
frameworks
group
and
I
think
that's
a
great
approach.
I
also
when
I
made
my
comment
about
why
http
2's
interest
didn't
pick
up.
It
was
more
about
the
the
end
user
side,
not
as
much
about
the
the
protocol
side,
so
I
think
that's
maybe
where
we
were
missing
there.
I
I
you
know
you
are
by
far
the
expert
on
the
the
protocol
side.
K
I
was
thinking
more
along
the
lines
of
like
how
this
worked
in
the
express
ecosystem.
When
you
know
people
would
come
to
ask
and
we'd
sort
of
dig
into
why
they
were
asking
for
support,
and
it
would
turn
out
that
you
know
it
just
wasn't
really
going
to
be
important
use
case
or
you
know
it
wasn't
going
to
be
a
really
like
lasting
impact
value
add
to
to
get
it
there,
and
so
that's
why
I
was
hoping
if
we
can
find
a
way
to
reframe
the
conversation.
K
If
we're
going
to
get
try
to
get.
You
know
libraries
and
end
users
to
switch
to
a
new
api.
I
would
like
to
make
sure
we
just
have
a
really
good,
like
user.
First
focus,
not
necessarily
like
a
protocol
first
focus
and
I
think,
having
an
api
that
paves
over
some
of
those
differences.
It
is
really
you
know
in
that
realm.
It's
achieving
the
goal
that
I
that
I
would
hope
we
we
have
set
up
to
to
achieve
so.
J
I
think
also
part
of
the
problem
with
http
2
is
you
know,
a
lot
of
us
are
still
on
http
one,
and
then
you
still
have
to
use
the
http
one
api,
and
then
you
have
to
use
the
http
2
api.
If
I
made
a
new
api
that
works
with
all
the
protocols,
then
I
can
just
okay.
I
build
my
code
base.
This
api
just
having
to
re-implement
everything
in
two
different
apis
is
problematic.
J
But,
but
I
think,
there's
two
parts
of
this,
so
we
need
to
like
design
a
user
level
api
that
you
know
works
with
the
different
protocols.
I
would
even
like
to
see
an
api
that
is
very
similar
on
the
client
and
the
server
side,
they're
just
inverse
of
each
other
and
then
there's,
of
course,
the
transport
implementations
and
the
lower
level
stuff
that
the
james
has
been
working
on,
and
I
don't
think
one
of
them
have
blocked
the
other
yeah
say
like
with
unditchi.
A
So
if
I,
if
I
summarize
a
little
bit
like
with
the
perfect
world,
what
would
the
perfect
world
look
like,
like
people
have
mentioned,
say
fetch
as
one
level
and
then
you
know,
there's
we've
talked
about
like
an
intermediate
level
and
then
the
socket
level
right.
A
D
D
Then,
on
top
of
it,
we
have
the
concept
of
a
pool
which
implements
the
same
api
of
the
client
and
which
it's
very
it's
a
very
basic
api.
By
the
way,
it's
a
very
low
level
api,
this
pool
it
allows
you
to
manage
multi
more
than
one
connection,
essentially
one
and
more
than
one
subject
and
with
some
you
know
way
with
some
dispatching
logic,
like
the
dispatching
algorithm.
D
The
way
the
pool
selects
which
socket
to
use
is
actually
very
important
for
performance
reason,
so
that's
part
of
the
reason
that
there
is
a
pool
concept.
Finally,
on
top
of
that,
there
is
the
agent
which
still
implement
the
same
api
of
the
other
two
okay,
that
supports
more
than
one
target
destination.
D
Okay,
you
need
those
three
levels
to
to,
or
at
least
two
of
those
three
levels
if
you
on,
if
you
want
to
generalize
between
protocols,
because
you
want
something
that
can
deal
with
multiple
destinations
and
something
that
can
deal
with
the
single
destination
and
and
so
on,
the
way
roanoke
did
dronac
did
some
magic
here,
because
it
layered
things
up
in
a
way
that
the
api
surface,
for
this
is
very,
is
very
nimble
and
then
all
the
developer
experience
part
is
actually
layered
on
top
of
this
shared
api,
so
adding
new
more
of
these
is
actually
simple.
J
Yeah,
I
think
you
summed
it
up
pretty
well,
so
it's
pretty
easy
to
add,
I
mean
an
http
is
basically
you
receive
headers
and
you
receive
a
body
and
you
send
up
headers
and
you
send
body,
so
I
think
and
that
maps
to
all
the
protocols-
and
I
think
that
would
make
sense
to
have
at
the
low
level
and
then
have
high
levels.
On
top
of
that-
and
I
think
fetch
is
a
high
level
api
that
we
can
ship
in
core.
N
If
I
was,
you
know
going
back
to
michael's,
you
know
you
know
question
there
about.
You
know
what
would
be
ideal
like
you
know.
If
I
was
looking
just
at
node
today
greenfield
and
what
what
I
would
look
to
node
core
to
provide.
It
would
be
the
socket
api
and
a
set
of
utilities
that
you
know
almost
like
a
like
just
a
tool
kit
or
projects
like
undichi
or
express
to
build
something.
N
You
know
you
know,
you
know,
build
that
hp
layer
on
top
that
api
layer,
and
so
I
would
prefer
node
itself
not
to
have
a
hp,
client
or
a
http
server
I'd.
Rather
it's
a
here's,
a
socket
api
that
you
can
use
to
build
those
things
and
there's
a
set
of
utilities
that
make
it
easier,
but
I'd
rather
see
that
that
the
innovation
on
that
actual
api
happened
in
individual
projects
like
undigi.
N
I
think
that
those
those
those
projects
you
know
are
closer
to
the
users
and
are
able
to
evolve
at
a
much
much
more
rapid
pace
than
what
we
can
do
in
node
core
and
I'd
rather
see
that
work
there.
Now,
if
that
work
gets
to
a
point
where
it's
stable
right,
it's
it
you
know
and
functional,
and
it's
and
we
know
that
that's
what
users
want,
then
a
decision
can
be
to
be
made
about.
Do
we
move
that
into
no
course
of
vendor
dependency.
J
D
D
At
some
point,
and
one
of
my
goals
for
this
meeting
is
agreeing
that
we
need
to
have
that
that
fetch
as
a
global
and
then
this
will
mean
essentially
that
some
from
my
point
of
view,
the
preferred
way
would
be
for
undigi
to
be
ideally
vendored
in
as
a
dependency
or
potentially
or
brought
in
as
part
of
the
tree.
I
don't
know
how
that
would
happen
so,
but
the
mechanism,
it's
it's
up,
really
up
for
discussion,
but
I
think
the
end
result
might
not
be
so.
It's
yeah.
A
I
I
agree
that,
like
that
strategy
of
what
should
be
in
core
or
not
as
apis
is
one
key
thing
to
agree
on
and
then
I
think
that
leads
naturally
almost
to
the
layering
like
so
for
I'll.
Just
you
know,
this
is
not
necessarily
the
right
answer.
What
would
be
but,
like
you
could
see
a
future
where
you
know
say
fetch
and
in
dc
are
public
apis
and
then
things
like
a
socket
level.
A
Api
is
internal
and
we've
built
in
dc
on
top
of
that
for
to
pull
in
the
http
3
support,
so
it's
kind
of
like
because
I
think
our
challenge
is
like
the
more
we
put
in
the
more
we
have
to
support.
So
it's
like
what
apis
do.
We
have
to
clearly
support
publicly
can
most
can
be
a
separate
thing
for
what
do
we
have
inside
of
node
core
to
support
those,
but
they
don't
necessarily
have
to
be
exposed
directly.
It's
kind
of
where
I'm
getting
to.
N
And
and
and
there's
there's
also
a
difference
in
the
pace
of
developments,
and
you
know
the
pace
of
changes
and
decision
making
processes
and
things
that
go
into
it.
You
know
undigize
is
able
to
evolve
much
at
a
much
more
rapid
pace
than
node
core
decisions.
Around
api
can
can
progress
at
a
much
more
much
more
rapid
pace
and
while
things
are
being
developed,
I
think
you
know
separating
those
out
from
the
node
core
process
right,
so
we
can
work
on
those
things
faster
and
evolve
them
faster.
N
I
think,
makes
a
hell
of
a
lot
of
sense
right
and
then
once
there's
once
they
reach
that
point
of
stability.
At
that
point,
then
we
answer
the
question
of
you
know:
do
we
bring
it
in
and
how
do
we
bring
it
in
or
not?
But
while
things
are
still
in
active
development
right
separating
them
out
should
be
perfectly
fine
and
we
don't
necessarily
have
to
feel
like
we
should
not
necessarily
have
to
feel
like
no.
No,
we
have
to
have
this
api
in
node.
It's
got
to
go
through
the
node
cores
development
process.
N
N
You
know
yes,
node
core
has
these
hp
apis
that
are
there
right,
but
that's
not
necessarily
that
doesn't
necessarily
mean
that
any
changes
in
innovation
that
we
do
around
these
apis
has
to
happen
in
node
core
touching
those
apis.
We
can
just
let
those
be
work
on
everything
else
on
the
side
right
and
then
make
the
decision
to
pull
them
in
later
and
then
at
that
point
decide
what
we're
going
to
do
with
the
existing
aps.
There's
people
that
have
their
hands
up.
Sorry,
yeah.
K
I
raised
my
hand
specifically
on
this.
This
path
is
being
paved.
I
think
in
like
a
few
different
forms
right
now,
so
I
noticed
that
ben
opened
up
the
parse
args
library
in
the
pkgjsorg
we've
got
udichi.
I
think
there's
at
least
two
or
three
other
cases
where
it's
like
there's
work
that
someday
people
picture
being
you
know
quote
unquote
part
of
core
that
they're
doing
in
these
other
people.
K
I
think
that's
great,
I
think,
investing
in
whatever
process
it
takes
and
having
some
guidelines
around
like
how
that
should
work,
I
think,
would
be
awesome
totally
separate
from
this
conversation.
Maybe
part
of
the
10-year
plan
is
like
figure
out
a
better
way,
for
you
know
things
to
go
from
experimental
libraries
to
exposed
as
part
of
the
binary
end
users
get.
K
You
know,
however,
we
talk
about
that,
whether
the
code
moves
into
core
or
still
lives
as
a
library,
but
it's
vendored
in
like
I
actually
you
know,
don't
care
so
much,
but
I
think
this
is
a
great
process,
so
I
think
we
should
definitely
invest
in
it
and-
and
I
don't
think
it
is
a
problem
for
things
to
be
long
lived
in
a
s
in
a
vendored
in
dependency
maintained
by
the
project
directly.
K
So,
like
you
know
my
reasoning
there,
what
I
specifically
mean
is,
I
think
it
is
important
that
the
project
provide
things
like
you
know,
code
of
conduct
support.
You
know
just
general
maintenance.
Things
like
this
is
one
of
the
big
pushes
with
the
pkg.js
org
to
make
sure
that
we
got
it
fully
in
the
fold
right
like
we
wanted
people
to
innovate
and
innovate
in.
K
As
long
as
we
have
that
sort
of
you
know
working
well,
I
think
it's
a
great
idea
to
let
these
things
live
in
a
separate
repo,
even
if
it's
in
a
separate
org,
but
give
people
like
sort
of
that
that
light
at
the
end
of
the
tunnel
that
says
hey
here
is
the
way
you
can
go
from
a
library
like
kundichi
to
having
it
be,
bundled
and
documented.
As
part
of
the
node.js
experience,
I
think
would
be
like
a
really
strong
move
for
us.
F
Yeah,
but
I
think
I
can,
I
can
say
it
now
so
yeah
I'd
like
to
say
that
we
could
bundle
on
dc
in
node
without
actually
exposing
its
api.
Just
for
the
sake
of
implementing
fetch
with
it.
A
Yeah
and
that's
exactly
the
kind
of
thing
I
was
thinking
of
is
like
we
can,
we
can
define
like
what
apis
do.
We
need
to
expose
and
then
behind
the
scenes,
there's
things
like
the
other
levels
that
we're
not
ready
to
expose
or
never
will
you
know
including
them,
but
not
exposing
them
is
a
good
path
right.
P
I
think
bradley
had
his
hand
up
as
well
yeah,
so
I
have,
I
guess,
different
concerns.
Just
I've
followed
along
with
historical
efforts
along
this
path,
especially
readable
stream,
and
how
that
is
a
little
bit
weird,
it's
extremely
stable
for
the
most
part
in
the
ecosystem,
and
all
this
talk
about
being
able
to
innovate,
faster
and
stuff
and
being
able
to
do
things
that,
I
think,
is
a
little
bit
against
the
idea
that
we
would
expose
it
in
some
way.
As
notes
core
node's
core
apis
tend
to
be
very
stable.
P
So
if
we
expose
it
by
default,
the
node
core
that
by
nature-
and
it
gets
rid
of
a
whole
style
of
innovation,
breaking
changes
become
things
that
node
core
may
reject,
and
then
it
would
go
out
of
sync
with
whatever
these
are.
So
those
projects
need
to
basically
have
some
level
of
commitment
not
to
do
breaking
changes.
K
To
that,
that's
specifically
what
I
mean
by
managed
by
the
project
in
that
case,
if
the,
if
the
library
was
going
to
make
a
breaking
change
that
they
were
concerned
with,
I
think
it
would
be
something
that
could
be
raised
to
the
node.jstsc
right,
like
that's
what
I
meant
by
having
support
directly
from
the
project,
to
make
sure
that
those
kind
of
things
are.
J
N
It
goes
back
to
the
you
know.
Is
it
part
of
note
or
is
it
a
vendor
dependency?
You
know,
are
our
vendor
dependencies
have
their
own
processes
for,
for
you
know
when
to
make
breaking
changes,
and
then
we
just
decide
when
those
breaking
changes
happen.
When
we're
gonna
update,
I
apologize
for
the
barking
dogs
in
the
back,
but
they
you
know
so
you
know
we.
We
do
need
to
look
at
that.
A
I
think
I
think
that
bradley
one
of
the
the
key
thing
I
got
from
bradley's
point,
though,
is
that
as
soon
as
we
expose
a
vector
dependency
directly,
that
is,
that
is
going
to
have
a
backward
pressure
on
the
innovation
that
the
vendor
dependency
can
have.
If
we
want
to
keep
them
in
sync
like
say
we
we
exposed
him
to
ichi,
just
because
node
core
is
conservative.
A
N
A
P
Yep,
it's
only
if
it's
exposed
and
being
exposed
is
actually
something
node
does
to
a
lot
of
internal
apis.
We
set
properties
and
things,
so
I
am
sure
people
out
there
will
get
a
hold
of
the
internals.
If
we
expose
mdg
in
a
way
that
people
can.
A
A
What
is
it
that
we
think
we
need
in
core
and-
and
I
guess
even
things
that
aren't
in
core
but
like
what
that
we
need
to
support
to
make
sure
that
there's
good
ecosystem
support
to
get
to
where
we
think
we
should
be.
I
mean
I
think
we
I
hear
general
consensus
that
we
want
to
have
apis,
which
the
clients
server,
like
the
the
end
users,
whether
they're
a
client,
they're
implementing,
client
or
server,
don't
have
to
know
about
the
protocol
right.
P
A
Right,
I
think,
part
history,
may
you
know
we
have
http
1
and
http
2,
which
are
basically
we're
stuck,
I
think,
with
them
being
fairly
specific
right.
So
in
terms
of
legacy
apis,
I
think
we'll
have
a
few,
because
we
can
everybody
correct
me.
If
I'm
wrong,
I
don't
think
they're
going
to
be
the
path
to
getting
one
getting
to
a
place
where
end
users
don't
have
to
care
about
that,
and
I
think
we're
not.
A
My
take
is
like
we
can't
let
that's
that
basically
mean
we
can't
innovate,
can't
make
things
better.
We
just
have
to
accept
that
as
a
as
as
where
it
is
right,
but
like
going
forward,
our
principle
is:
let's
not
introduce
a
new
api
which
is
tied
to
any
one
protocol
and
doesn't
support
the
other
ones
like.
If
we
introduce
a
new
protocol
or
api
sorry,
we
introduce
a
new
api.
A
N
O
N
D
You
we
need
also
to
be
able
to
provide
those
low-level
details
when
needed,
so
it
needs
to
be
that
ninety
percent,
like
the
the
reason
why
is
there,
are
especially
when
you
talk
about
security,
securing
http
and
points.
You
have
a
huge,
wide
range
of
settings
that,
depending
on
your
deployment,
you
might
want
to
set
or
not,
and
well
I
mean,
if
you
just
look
at
clicks,
configuration.
D
See
that
there
is
massive
amount
of
protocol
specific
details
that
we
need
to
ship
safe
defaults,
but
those
safe
defaults
might
not
be
first
safe
for
everybody
and
second
good
for
the
production
usage
of
everybody.
Okay
on
one
side
or
the
other,
like
more
people,
wants
them
more
lenient.
Other
people
when
they're
more
strict-
and
you
just
need
to
provide
all
them
all
the
options
right
now.
This
is
a
little
bit
over
the
place
and
collapsed
with
the
previous
one,
with
the
with
that
with
with
the
layers.
D
D
D
That
it's
yes,
and
no,
because
a
lot
of
people
would
want,
as
wes
mentioned,
like.
Let's
consider
the
case
of
of
of
netflix.
Okay
they're,
probably
doing
a
lot
of
server
to
server
http
calls
and
for
sure
they
want
to
configure
certain
details
about
how
those
the
pulling
for
those
http
calls
how
many
sockets
I
want
to
keep
alive.
How
many
there's
a
lot
of
details
around
those
things?
Okay,.
A
Right
but
maybe
they're
forced
to
use
the
next
level
down
like
I,
I
could
see
a
future
where,
like
the
more
sophisticated,
a
user,
you
are
the
lower
level.
You
have
to
go
like
it's,
it's
a
trade-off
because
I
think
the
more
you
know
if
you
take
the
high
level
api
but
then
expose
all
the
internals,
I
think
we're
going
to
get
into.
D
A
Okay,
so
right,
okay,
so
you
can
drop
down.
If
we
have
the
layers,
you
can
drop
down
a
layer
and
affect
what
the
higher
level
so
yes,
you're,
not
but
you're,
not
building
it
into
that
higher
layer.
Api
you
just
have
the
layering
is
such
that
yeah.
That
makes
a
lot
of
sense
to
me,
so
you
still
have
to
drop
down
to
the
lower
layer,
but
you
can
get
that
through
the
higher
layers.
If
you
do
that,
yeah.
D
Yeah
wes
has
this
and
yeah.
K
I
was,
I
was
kind
of
waffling
and
whether
or
not
I
I
wanted
my
hand
raised,
but
I
I
almost
see
that
as
not
fully
dropping
down
right,
like
providing
some
options
that
configure
the
high
level
api
is,
I
think,
a
really
acceptable.
It's
not
even
really
a
middle
ground.
I
think
it's
just
a
it's
a
good.
It's
a
good
api
choice.
When
I
think
about
stepping
down
to
the
lower
layer,
I
was
worried
that
we
were
gonna,
you
know
say
like
no.
K
No,
you
get
rid
of
all
the
fetch
semantics
you
go
down
to
the
pier.
You
know
either
http
when
you're
back
into
the
world
of
having
to
know
whether
it's
one,
two
or
three
layer
and
I'd
like
to
have
it
I'd
like
to
have
like-
and
I
think
passing
an
agent
well,
but
that's
even
sort
of
tied
to
the
the
concept
of
how
we
do
the
the
protocol.
K
K
I
know
there's
going
to
be
trade-offs
all
over
the
place,
and
so
I'm
just
expressing
like
the
want,
not
necessarily
like
how
we
get
there
or
you
know
the
details
of
it,
but
I
think
you
know
really
keeping
if
we
can
find
the
right
knobs
that
most
people
who
want
to
go
a
little
bit
deeper
than
just
call
fetch
and
forget
about
it,
haven't
and
have
those
like
in
a
pretty
consumable
way.
I
think
we're
gonna,
you
know,
even
if
it
is
the
80
20
rule.
K
I
think
now
we're
talking
to
like
99
and
one
rule
right,
we're
like
if
we
can
get
fetch
and
some
little
tweakables
that
like
are
really
easy
to
consume,
then
I
think
we've
we've
covered
like
the
99
case
and
I
think
we're
great
like
we're
doing
a
really
good
job
with
that.
N
There
is
always
going
to
be
a
need
for
us
for
a
quick,
specific
api
that
has
nothing
to
do
with
hp3
and
the
reason
for
that
is
that
there
are
more
protocols
being
built
on
top
of
quick
other
than
hp3
all
right
sophie.
If
we,
you
know,
consider
it
like
the
difference
between
http
and
websockets
right,
there's
going
to
be
other
protocols
and
in
fact
there
might
be
there.
N
There
has
been
talk
of
an
all
of
a
new
version
of
websockets,
which
is
based
on
quick,
so
there's
going
to
be
need
to
have
a
quick
api
and
this
http
api.
That's
agnostic,
that
that,
under
the
covers,
when
it's
using
hp3
is
going
to
be
using
the
quick
transport
also,
so
we're
still
going
to
have
distinctions
like
that.
N
N
Circumstances
you
know,
and
it
does
get
complicated
like
like
with
quick
and
hp3.
You
know
part
of
that
implementation.
Part
of
that
hp
semantics
is
actually
at
the
native
level.
It
you
know
before
it.
It
goes
out
to
the
javascript
level,
where
we're
building
these
these
apis
and
the
reason
for
that
is
because
of
the
way
that
http
3
uses
quick,
where
you
actually
have
multiple
streams
and-
and
you
know,
and
we
have
the
nghp3
library-
that's
actually
parsing
a
lot
of
that
state
for
us.
N
So
you
know,
there's
there's
still
aspects
of
http
3
that
we
have
to
move
into
the
lower
level
protocol
implementation
simply
because
of
that's
how
it's
defined
once
we
you
know.
So
I
think
that
part
we're
talking
about
separating
is
the
hp
semantics
from
the
actual
mechanism
of
how
it
gets
transported
right
so
but
they're
they're
we're
still
going
to
have
some
of
those
edges
bleeding
into
each
other.
A
I
mean
what
it
makes
me
wonder.
A
little
bit
is
like.
Does
it
make
any
make
any
sense
for
us
to
start
so
like
when
we
brought
something
like
quick
in
it
wouldn't
be
exposed,
but
it
would
be
used
and
proven
out
through
the
http
3
layering.
So
you
would
be
able
you
know,
we'd
be
using.
It
would
be
part
of
core,
but
we
don't
have
to
add
an
api
which
we're
now
going
to
have
to
support
forever,
and
you
know
like
http
2.
N
N
A
I
don't
know
what
people
think
like
that.
That
means
we've
not
committed
anything
externally,
but
it's
it's
usable
and
that's
you
know
that
would
make
it
much
easier
for
me
to
say.
Well,
okay,
we
can
be
less
careful
pulling
it
in
because
we
haven't
committed
ourselves
to
something
forever
right
and
we
can
use
it
internally
and
build
on
top
of
it
and
those
kinds
of
things.
Yep.
N
I
mean
so
I
mean
if,
if
that's
what
we
want
to
do,
I
mean
you
know
I
got
to
look
at
timeline
exactly
when
I
can
get
back
to
it,
but
you
know
I
I
could
actually
remove
all
of
the
javascript
bits
from
that
from
that
pull
request,
focus
just
on
the
native
internals
and
the
api
that
you
know
yeah
through
the
surface
through
the
internal
binding,
and
you
know-
and
we
can
back
off
that
entirely-
that
we
can
see
where
we
need
to
go
from
there.
A
See
if
two
people
have
their
hands
up
so
like
tierney
did
was
your
hand
related
to
that
topic.
Yep,
okay,.
M
I
guess
with
that
like
is
there
a
path
forward
for
like
indici
to
be
able
to
consume
that
and
and
implement
it
in
whatever
their
you
know?
Api
desires
are.
N
If
so,
undici,
if
we
look
at
it
as
an
ecosystem
user,
land
module
that
has
to
use
public
apis
from
node,
then
no
because
it
would
be
exposed
only
through
the
internal
binding.
If
we
look
at
unduchiti,
as
this
is
a
node
core
thing,
and
it's
okay
for
them
to
use
internal
bindings,
then
we
give
them
some
path
for
doing
so.
You
know
you
know
where
they
can,
but
I
think
it
would
have
to
be
brought
in
as
a
vendor
dependency,
though,.
P
I
I'll
call
in
is
bradley
sure
I
really
like
this
idea
of
being
able
to
pull
in
stuff
for
internal
use.
We've
had
pushback,
at
least
for
me
in
the
past.
Whenever
I've
tried
to
do
this,
because
if
it's
not
exposed
publicly
people,
don't
want
it
to
land,
and
that
makes
a
lot
of
pressure
to
make
something
that
you
will
support
forever
land
in
node
core
and
it
makes
it
so
the
moment
you
try
to
upstream
something
into
node
core
pretty
much
all
innovation
stops.
N
P
So,
on
the
counter
side,
like
james
was
saying,
I
think,
was
james,
said
it
having
a
way
for
udc
to
use
internal
bindings
would
also
be
interesting
and
nice.
P
D
Yeah
I
I
wanted
to
say
that.
D
It's
if
we
want
to
use
onlgi
to
validate
those
internal
apis,
we
will
need
them
to
be
exposed
somehow,
so
it
might
be.
That
is
a
process
binding
or
a
process,
something
that
enables
people
to
get
those.
But
the
result
is
that
we
should
be
able-
or
you
know
or
say
it
another
way
we
can.
If,
when
it
is
in
core,
then
we
can
add
some
added
implementation
that
is
core
specific
to
to
core
itself
that
uses
those
apis.
D
A
Yeah
one
thing
that
that
comes
to
mind
on
that
line.
If
we
basically
said
like
it's
strategic
to
add
a
fetch
level
api
yeah,
then
what
we
might
do
is
pull
in
indici
is
the
level
that
it's
built
on
top
of
and
then
you
know,
pull
in
quick
as
the
level
that
indica
uses
to
get
http
3,
but
not
exposed,
and
you
know
either
in
dc
or
quick
to
start
with.
D
A
D
Yes,
exactly
right:
well,
the
api
is
not
super
big,
but
we
need
to
export
some
part
of
it.
Specifically,
there
is
the
mock
system
that
it's
already
in
place
that,
if
you
want
to
because
the
one
of
the
problem
of
mocking
http
is
that
a
library
like
knock
and
stuff
like
that,
go
and
monkey
patch
hell
of
a
lot
from
co
of
core
making,
funnily
enough
core,
even
harder
to
to
change
those
apis.
D
Because
then
you
know
they
are
monkey
patching
it
so
ships
with
his
own
mock
system,
which
might
need
some
love
from
a
devex
perspective.
So
if
somebody
wants
to
take
a
look
that
that
would
be
great,
but
nevertheless
it's
those
things
we
need
to
be
exposed,
so
people
could
actually
mock
that
fetch
call
essentially-
and
this
is
an
example-
but
the
same
is
true
for
configuring-
the
number
of
socket
used,
the
timeouts
and
those
things
that
are
important
so.
A
So
I
so
I
think
you
know
we
we're.
We
have
a
half
hour
left.
The
thing
I
think
would
be
good
is
to
maybe
loop
back
to
like
in
the
perfect
world,
some
future
state.
A
What
apis
would
we
like
to
expose
that's
separate
from
when
we
will
expose
them,
but
it
would
be
like
we
want
to
get
here
and,
in
my
mind,
like
you
know,
there's
bradley's
pointed
like
in
the
past,
there's
been
resistance
to
pull
things
in,
but
not
expose
them,
and
I
think
in
my
mind,
if
we
have
a
strategy
documented
that
says,
for
you
know,
for
http.
Support
is
key
to
to
node
success.
This
is
where
we
want
to
get
to.
That
seems
like
a
good
thing
to
point
to
in
terms
of
saying.
A
Well,
we
want
to
pull
in
this
component,
but
not
expose
it,
because
it's
a
piece
that
will
be
used
to
provide
that
in
the
future
right
and-
and
so
if
we
can
have
that
view
of
like
where
should
we
get
to
in
terms
of
public
apis,
we
can
use
that
to
to
explain
why
these
things
are
coming
in
and
why
you
know
we're
not
exposing
them
now,
but
they
make
sense
in
the
future
right.
N
Yeah
and
I
think
they're
yeah
as
part
of
that
we
there
has
to
be
a
tolerance
for
yes,
we're
going
to
land
this
piece
in
now.
Even
if
it's
not
perfect,
it's
not
exposed,
it
can
be
changed.
It
can
be
evolved
as
we
go
through
the
rest
of
the
process.
We
can
continue
to
refactor.
This
thing.
There's
almost
been
this.
N
This
idea
that,
if
something
new
comes
in,
it
has
to
be
a
complete
thought,
all
done
and
exposed
publicly
right
from
the
start,
and
that
I
think
that's
the
thing
that
actually
kills
us
being
able
to
make
progress
faster
on
these.
Like
you
know,
if
we're
not
exposing
the
quick
implementation,
not
all
the
eyes
have
to
be
dotted
and
all
the
teams
have
to
be
crossed
in
order
for
us
to
land
the
basics
and
then
iterate
from
there.
A
A
N
I
I
I
I
think
that
that's
likely
going
to
require
a
bit
more
looking
at
it,
but
I
think
like
based
on
what
I
was
seeing.
If
we
were
talking
just
client
side,
I
think
dc
is
going
in
the
right
direction
for
giving
us
the
proper
layering
of
of
apis.
I
I
think
that
there
might
be
might
be
opportunities
there
to
make
it
kind
of
clear
separations
like
we
have
fetch.
N
We
have
undigi,
we
have
socket
right
and
you
know,
and
we
kind
of
get
a
better
definition
of
what
those
boundaries
are.
A
N
And
I
think
it's
clear
to
capture
the
fact
the
socket
api
might
be.
You
know
it
it's
it's
likely
to
be
very
protocol
dependent
right,
so
you
know
we're
going
to
have
tcp
sockets
we're
going
to
have
quick
sockets.
Now
those
might
share
a
common
api
surface
or
be
similar,
but
at
that
level
we
have
to
care
about
the
protocol
more
details.
A
A
N
We
have
the
udp
modules
and
those
kind
of
things.
Now
we
can
clean
those
up,
there's
work
that
can
be
done
there
to
unify
those
apis,
and
that's
that's
a
project
that
I'm
taking
on
this
year,
but
at
that
level
right,
it's
not
protocol
agnostic.
It's
going
to
be
very,
you
know,
there's
going
to
be
details
that
are
specific,
quick
details
that
are
specific
to
the
tcp
right.
It's
those
that
intermediate.
You
know
when
we
go
above
that
socket
layer
when
we
go
to
the
intermediate
http
and
then
the
fetch.
A
I
guess
the
that
makes
me
think
we
started
out
and
what
we
have
documented
in
our
like
technical
things
that
are
key
to
future
is
http
and
lower
level.
Socket,
like
you
know,
socket
level
support
like
tcp,
quick
protocol
support
are
those
two
different
things.
Are
they
some?
Are
they
related
separate.
A
That
could
almost
be
like
a
separate
priority
for
future
success,
whereas
at
the
http
level,
what
we're
really
saying
is:
we
need
an
intermediate
level
api
and
a
fetch
level.
Api
yeah.
N
Okay,
it's
typically
built
around
hp
semantics
now
on
the
socket
level,
like
the
work
that
I'm
going
to
be
doing
this
year
is,
is
as
much
as
possible
to
define
a
socket
api,
that
is,
that
is
itself
agnostic
as
much
as
possible
on
whether
you're
using
tcp
or
udp
or
quick
and
in
hiding
as
many
of
those
details
as
possible
there.
But
that's
a
separate
concern
than
the
http
semantics
right
right.
A
Like
yeah,
I'm
thinking
like,
if
you
separate
that
out,
you
could
say
well,
we,
the
the
http
use
case,
supports
pulling
in
quick
as
a
non-exported
api
yeah
right
because
it
supports
doing
http
3,
but
it
it
doesn't
drive
making
it
public
right.
Exactly
it's
a
separate
discussion
that
says.
Well,
you
know
it's
important
for
node
to
be
able
to
let
you
do
protocol
interactions
at
a
lower
level,
and
you
know
for
that.
A
A
D
Is
I
think,
that's
a
minimum
minimum
level
of
requirements
but,
as
wes
said
in
a
few
other
during
some
of
the
others
stopped
a
few
times
to
this,
the
advanced
user
will
need
something
a
little
bit
more
nuanced
than
something
like
fetch
to
build.
The
thing.
D
A
A
And
an
intermediate
level
api
and
like
in
the
perfect
world,
those
would
be
the
two
apis
we
expose
and
underneath
them
they
both
support
http
one
two,
three,
five,
six
whatever
comes
out,
but
those
are
the
apis
that
we
and
and
yeah.
If
you
want
something
more
like
fetch,
as
you
mentioned,
I
think
exposing
some
things
like
an
agent
that,
let
you
do
a
little
bit
of
configuration,
would
be
good,
but
then,
if
you're
really
getting
sophisticated,
you
drop
down
to
the
intermediate
one,
which
is
dc
right.
N
We
we
also,
we
also
can't
forget,
servers
and
all
this
coming,
you
know
servers
are
going
to
have
more
of
a
reason
that
they
need
the
lower
levels
right.
You
know
to
be
able
to
specify
hey
what
sockets
and
ports
am
I
listening
on
and
what
protocols
am
I
am
I
listening
for.
N
So
on
the
server
side.
We
absolutely
need
to
have
a
lower
level.
You
know
lower
level
api
for
being
able
to
decide.
Yes,
this
is
gonna
support,
hp,
one
and
two
and
three
all
right.
So
from
a
security
point
of
view,
they
can
in
a
performance
point
of
view
they
can.
They
can
do
the
right
things.
N
No
indici's
clients,
client
side
right.
It
only
deals
with
the
client
side
concerns.
What
I'm
talking
about
for
low
level
on
the
server
side
is,
I
want
to.
I
want
to
expose
an
hp
server
right
and
it's
going
to
be
it's
going
to
deal
with
just
http
semantics,
so
we're
getting
our
requests
and
responding.
But
what
ports
am
I
going
to
listen
on
right
and
what
protocols
are
those
ports
going
to
be
going
to
be
exposed
on?
And
you
know
what
are
the
tls?
N
You
know:
what's
the
tls
configuration
for
those
right,
it's
it's
a
much
lower
level
set
of
apis
than
what
you
you
know
that
the
client
needs
to
deal
with
all
right.
A
D
It
was
that
was
the
major
pain
point
like
in
my
experience.
While
the
server
is
slow,
it
has
some
pro
has
some
problems,
the
the
biggest
part
of
the
pain
that
I
felt
in
operating
the
js
scale,
we're
on
the
client
side
on
the
server
side.
That
api
is
not
great,
but
it
does
not
suffer
from
all
the
limitations
of
the
node
core
http.request
api.
N
No,
I
I
will
say
there
even
on
the
server
side,
there's
still
two
layers
here
right
there
there's
there's
the
I
just
want
to
to
respond
to
hp,
requests
right
and
it
would
be
nice
to
be
able
to
say
if
I
get
an
hp
request,
no
matter
what
protocol
it
is,
yeah,
here's
the
response,
send
it,
regardless
of
whatever
protocol
it
is
so.
N
D
Yeah,
I
I
totally,
I
totally
agree
on
on
the
on
the
first
front,
what
I
can
I
I
know
pretty
much
what
people
would
like
in
term
of
that
first
api?
D
Okay,
so
that
sense,
okay,
so
I've
been
tinkering
with
with
it
enough
on
the
fastify
community
to
to
know
part
of
the
massive
problems
that
we
have
on
the
server
is
that
it's
aventimeter
based
which
creates
a
yeah
a
hell
of
a
lot
of
problem?
Okay,
I
was
using
a
band
termed
from
whatever
from
recording
speech
so
and
it
was
yeah.
That's
it
essentially
so.
N
D
N
That's
fine
yeah
on
the
server
side,
again,
there's
two
layers:
yeah
on
the
http
semantic
layer.
I
don't
care
what
protocol
is,
is
being
used
on
the
server
side
at
the
server
layer
right
all
right,
where
I'm
actually
establishing
what
what
ports
and
sockets
I'm
going
to
be.
Listening
to
there,
I
have
to
care
what
protocols
are
and-
and
you
know
there
might
be
protocol
specific
apis
there
for
configuration.
A
So
I
guess
that
pulls
us
back
into
the
socket
level
protocol
not
being
separate
from
from
the
http
world
at
the
client
side.
I
think
we've
said
that
should
be
protocol
independent
support.
All
the
you
know
you
shouldn't
care
whether
it's
http
one
two
or
three,
and
we
want
an
api
at
the
fetch
level
and
the
mgc
level
for
the
server
side.
It
sounds
like
we're
saying
we
need
more
than
that.
N
N
H
N
And
then
there's
an
application
that
responds
to
hp
requests
that
you
know
those
are
those
have
to
be
two
distinct
layers
right
now.
I
have
to
know
that
I'm
setting
up
an
http
server.
I
have
to
know
that
I'm
setting
up
an
hp2
server
right
right,
yeah
and
that's
that's
where
the
fundamental
problem
is
right.
We
have
to
separate
those
things.
A
N
I
think
I
think
I
think
we
still
need
the
same
layering.
I
think
we
need.
We
need
a
high
level
right,
which
is
just
here's.
A
request
gave
me
the
response.
We
will
need
an
intermediate
level
to
support
projects
like
fastify
in
in,
and
you
know
express
or
whatever
that
that
are
they're
building
additional
stuff
on
top
of
that,
and
then
we
need
the
socket
layer
right
now.
The
socket
layer
may
be
where
we
actually
say.
N
A
The
question
is:
would
we
that
we
could
still
have
as
an
internal
api
but
expose
some
aspects
of
it
like
the
oh?
Well,
how
do
you
say
a
protocol
like
we
would
need?
We
would
need
the
intermediate
level
api
for
servers
to
be
able
to
say
I'm
using
tcp,
I'm
using
whatever
connection
details.
I
guess
is
that.
N
If
I
was,
if
I
was
gonna
just
you
know,
back
of
a
napkin
design,
something
like,
rather
than
having
an
http
server
class
in
a
hp2
server
class
and
a
tcp
server
class,
I
would
have
a
server
class
that
I
would
say,
expose
this
protocol
and
this
port
all
right,
right,
right
and
and
that
server
class
could
actually
expose
multiple
ports
right
right
and
then
and
then
there's
a
layer
built
on
top
of
that,
which
is
the
application
using
that
server.
A
A
N
N
A
Okay,
so
we're
down
to
like
about
10
minutes
until
I
think
it
would
be
good
for
us
to
take
a
bit
of
a
break
the
so
I've
written
down
like
you
know,
it
seems
like
we're
going
towards
like
the
client
would
need
you
know
two
levels.
The
server
would
need
two
levels.
A
A
P
P
We
want
a
least
common
denominator
api
that
works,
regardless
of
the
features
of
all
the
protocols
that
we're
talking
about
http
one
two,
three,
whatever
http
versus
https,
is
a
different
issue.
I
think,
but
we
want
a
least
common
denominator
api
that
works
the
same,
even
if
it
has
less
features.
P
It
can't
use
advantages,
that's
fine
and
then
the
other
layer
is
going
to
be
the
one
that
is
potentially
what
implements
the
least
common
denominator
api,
but
it
is
where
all
these
specific
apis
are
exposed
that
are
features
for
specific
things.
So
I
would
not
expect
things
like
2
stream
functionality
and
http
3
stream
functionality
to
actually
necessarily
have
the
same
apis,
even
though
they
have
a
similar
feature
set
like
these
other
layers
are
not
the
least
common
denominator
and
they're
you're
going
to
have
n.
P
N
Yeah
examples
include
very
practical
examples.
Are
the
response,
status
text
and
push
streams?
Fetch
today
doesn't
care
about
either.
One
of
them
doesn't
expose
any
mechanism
for
push
streams,
and
you
know
doesn't
care
if
an
hp
server
doesn't
return
the
status
text.
It's
gonna.
It
actually
fills
in
some
defaults
based
on
the
code,
so
I
mean
those
kinds
of
differences
are
easily
papered
over
in
in
in
in
fetch
that
it
becomes
that
least
common
denominator
api.
N
Now
that
intermediate
level,
if
we
drop
down
right,
it
is
realistic
that
a
client
might
want
to
expose
an
api
for
receiving
a
push
stream
right
on
the
server
side.
It's
conceivable
that
you
know
either
the
status
text
is
just
ignored
for
a
particular
protocol.
N
But
if,
if
we
offer
an
api
to
set
it,
then
someone
might
be
surprised
and
file
a
bug
report
when
suddenly
their
custom
text
is
not
actually
transmitted
or
communicated
anywhere
because
they
didn't
know,
it
wasn't
supported
by
a
particular
protocol
right
and
we
have
had
cases
where
people
have
tried
to
put
like
application.
Specific
information
in
response
text
and
you
know
suddenly
find
out
with
hp2
that
no
that
doesn't
actually
get
communicated.
A
Okay,
I
think
in
in
the
interest
of
our
five
minutes,
so
like
there's
some,
it
sounds
like
they're
still,
obviously
like
at
that
intermediate
level,
some
things
to
work
through,
but
I
think
the
you
know
it's
back
to
that
question
on
for
the
fetch
level
api
like
do
we
have
any
consensus
on
what
that
should
be
in
terms
of
you
know
our
future
direction.
A
The
answer
could
be
no,
but
I'm
just
throwing
that
out
there
is
there
something
we
we
would
agree
on
from
this
group
that
and
I'll
I
see
people
like
wes
has
his
hand
up.
So
ask
us:
ask
us
to
talk.
K
Yes,
so,
as
far
as
having
fetch
and
then
something
quite
a
bit
lower
to
me,
that
seems
fine.
I
would
say
you
know,
like
I've
said
before
in
the
meeting.
I'm
you
know,
I
don't
see
us
using
fetch
in
our
things.
I
think-
and
I
think
you
know,
90
percent
of
people
need
a
lot
more
than
fetch
provides
like
in
in
your
their
applications.
So
I
actually
don't
see
despite
everybody
asking
for
it.
K
I
think
when
the
you
know,
the
rubber
meets
the
road
they're
gonna
find
that
they
they
don't
wanna
just
use
the
global
fetch.
They
want
to
use
a
library
that
does
all
of
the
extra
nice
things
for
them.
K
I
mean
there's
a
reason
why
people
don't
use
http
and
use
festifying
express
like,
and
the
same
thing
is
going
to
happen
in
the
client
space
which
leads
me
to
you
know
it's
sort
of
funny
that
we're
gonna,
you
know
everybody
say
everybody's
asking
for
fetch,
but
all
the
library
maintainers
that
are
gonna
see
the
the
most
you
know
brunt
of
this
are
probably
going
to
have
to
jump
down
the
layer
right
because
that's
just
the
way
it's
going
to
work
right.
K
K
Yeah,
I
I
people
say
talk
about
fetch
all
the
time
and
I
think
it's
just
that
they're
annoyed
that
that
node
doesn't
have
the
thing
that
they
use
in
the
browser
to
do
like
trivial
things
right.
So
it's
not
like
the
the
90
case
needs
to
be
an
application,
uses
a
library
that
wraps
up
fetch
or
something
and
gives
them
all
the
nice.
Well,
if
it's
a
404,
you
got
these
nice
special
handlers.
K
Here's
some
like
interceptors
that
you
run
on
every
http
request
that
add
common
headers
for
application,
like
all
of
those
features
that
would
never
land
in
a
browser
spec,
because
you
don't
they
don't
live
there,
that
make
don't
make
sense.
There
are
the
things
that
app
users
actually
need
right
and
so
like
to
me
spending
a
lot
of
time.
K
Talking
about
fetch
has
always
been
sort
of
just
a
fool's
errand
like
we
should
be
talking
about
what
apis
can
browsers
use
to
build
fetch,
compatibly,
sorry
that
library,
authors
can
use
to
build
fetch
compatible
apis
plus,
all
the
you
know,
so
you
don't
have
to
write
called
dot
response.
You
know
wait
dot
response,
then
await.json,
like
those
things,
users,
just
really
shouldn't
be
doing
library.
Authors
should
and
at
that
point
fetch
is
actually
a
bad
api
for
library.
Authors,
in
my
opinion,
so.
P
I
have
a
very
different
opinion
for
the
most
part
for
many
apps
that
I've
written
over
many
years
of
using
node.
I
don't
do
that
when
I'm
using
requests
for
servers.
I'd
agree,
I
do
those
things
with
middlewares
a
lot
for
actually
sending
outbound
requests,
it's
kinda
rare.
P
P
O
Yeah,
if
I
could
jump
in
and
also
I
apologize
for
the
background,
I
want
to
agree
with
with
bradley
in
my
in
my
professional
experience
day
to
day.
One
of
my
main
driving
factors
of
building
fetch
on
indici
is
I've,
seen
firsthand
developers
struggling
using
adichie,
and
I
know
that
we
probably,
as
a
group
like
directly,
are
very
comfortable
with
dc
or
some
of
the
lower
level
apis.
O
But
a
lot
of
developers
out
there
are
not,
and
we
should
first
of
all
try
not
to
make
too
many
assumptions,
and
this
is
what
like
good
surveying,
is
for
or
like
getting
and
getting
asking
the
community
for
their
direct
responses.
But
I'd
say
that
there's
in
my
opinion,
there's
definitely
a
need
for
fetch,
or
at
least
just
because
from
what
I've
seen
and
it's
usability.
N
Yeah,
I
I'd
have
to
agree
with
that,
and
you
know
so
I
I
I
don't
think
it's
a
either
or
I
mean
I
I
think,
having
fetch
in
core
is
something
we
absolutely
need
to
do,
but
also
having
the
intermediate
api
is
also
something
we
absolutely
need
to
do.
There's
a
comment
in
the
in
the
chat
there
that
it's
a
difference
between
you
know,
end
users
and,
and
you
know,
app
developers
and
like
and
library
developers
we're
serving
two
different
audiences.
N
A
Okay,
so
I
think
just
again
because
we're
we're
running
low
on
team
time,
we
can
always
continue
these
discussions,
but
it
it
sounds,
like
you
know,
best
based
on.
What's
his
comment
in
chad,
saying
didn't,
didn't,
suggest
we
don't
ship
it.
We
could
leave
this
as
like
strategically.
We
think
we
need
these
two
levels,
the
fetch
level,
the
intermediate
level
it's
back
to
like
I'm
just
you
know.
Maybe
we
don't
need,
we
don't
have
consensus
but
like
if
we
were
going
to
pull
in
a
fetch
level,
a
level
api
would
would
we
choose?
A
D
Yeah
yeah,
so
I
just
wanted
to
to
say
that
it's
yeah,
I
think
the
upper
le
you
need
so
from
a
marketing
and
positioning
perspective
of
the
node.js
runtime.
D
So
it's
it's
becoming
unsustainable
on
a
medium
to
you
know
from
a
in
a
tactical
perspective,
not
a
fetch
in
like
to
be
to
the
point
that
we
should
support
having
some
experimental
version
of
it
in
node
18..
Like
again,
I'm
I'm
going
to
be
very
bold
in
that
statement,
but
we
might
even
try
okay,
it's
that's
the
starting.
D
That's
my
starting
point:
it's
we're
giving
ammo
to
the
defractors
of
node.js
and
what
we
stand
for,
so
we
need
to
defuse
them
essentially,
and
it's
it's
not
too
much
like
to
some
extent.
I
agree
with
all
of
things
that
was
said,
but
on
the
other
hand,
we
need
it.
Okay,
even
if
it's
like
the
the
percentage
of
users
that
needs
it
are
very
vocal.
D
So
even
though
they
don't
want
to
use
it
in
practice-
and
this
is
the
funny
stuff
about
it.
So
it's-
and
I
totally
request
most
of
the
use
case
of
of
that
are
going
to
go
in
production-
would
probably
need
to
use
a
lower
level
api
or
a
high,
both
a
lower
either
a
lower
level
api
or
a
higher
level
api
on
top
okay.
D
So
that's
the
so
in
that
I
completely
agree
now
the
higher
level
api
unt
offers
a
slightly
lower
higher
level
api
compared
from
the
bottom
layer
that
it's
available.
So
there
is
a
very
low,
extremely
low
level
api
in
english.
That
is
very,
very,
very
bare
bone.
I
would
not
recommend
people
to
use
that
unless
they
know
what
they're
doing.
D
However,
that's
the
part
of
the
api
that
we
use
to
build
the
others
so
and
then
robert
added
a
few
more.
So
there
is
a
request
method
and
a
few
others
that
offers
a
different
level
of
different
levels
of
the
api
and
different
for
different
skills,
essentially
so,
which
it's
it's
very
nuanced
in
undigi.
That's
what
I
wanted
to
to
say
on
on
that
so
yeah,
and
then
I
leave
the
the
mech
to
the
mic
to
robert
okay.
Q
J
Yeah
robert
sorry,
we
do
have
a
lot
of
different
apis,
in
which
I
honestly
feel
we
maybe
have
too
many
it's
it's.
It's
been
more
of
a
you
know,
experimenting
which
are
apis
that
make
sense,
and
then
you
know
from
go
from
there
to
see
which
one
we
actually
want
to
continue
on
words
with
and
the
other
thing
I
wanted
to
bring
like
my
vision.
A
little
bit
with
the
http
is
to
have
something
like
unbichi,
both
on
server
and
client
side.
That
has
the
same
feel.
A
Okay,
so
on
old
server
right
so
okay,
so
I
I
think,
I'm
hearing
like
I
hear
no
nobody's
saying
that
the
fetch
level
shouldn't
be
fetched.
I
hear
a
bunch
of
people
saying
like
we
should
pull
in
fetch.
So
I
speak
up.
If
you
don't
agree
with
this,
but
I
think
we
could
say
we're
saying
we
need
a
fetch
level
and
it
should
just
be
fetch.
A
Is
there
any
reason
or
any
other
like
api
standards,
whatever
that
we
would
say
that
we
should
use
instead
of
that
or
look
at
or
is
it
like,
hey
yeah?
We
would
you
know
the
team's
been
working
on
indici.
They
have
a
they're
comfortable
that
that's
the
the
sort
of
apis
we
should
target,
as
rona
said.
Maybe
we
would
be,
let's
filter,
that
down
a
bit
or
something,
but
like
is
that
kind
of
the
direction
that
we're
agreed?
We
should
we
should
use
to
fill
that
requirement.
A
Again,
the
question
is
like
we've,
said
and
agreed
that
we
need
an
intermediate
like
for
the
client.
We
need
two
two
levels
of
api,
one
which
is
fetch
level
and
we've
said:
let's
just
make
that
fetch.
We've
also
said:
we
need
a
more
intermediate
level,
one
which
is
protocol
independent,
and
the
question
is
like.
Are
we
at
the
point
where
we
can
just
say
our
strategy
is
to
deliver
that
through
indici.
P
A
Any
other
like
if
we
said
that,
as
you
know,
that's
our
strategy
like
yeah.
We
need
these
two
levels,
we're
doing
fetch
on
the
client,
we're
doing
a
fetch
and
we're
going
to
provide
a
new
intermediate
level.
This
protocol
dependent
and
it
may
be
a
subset
of
indici
or
something
but
like
that's,
where
we're
going
to
start
in
terms
of
our
focus.
Anybody
disagree
with
that.
F
I
just
have
a
question
to
mateo
or
or
ronag.
F
If
somebody
would
like
to
reimplement
gut
or
not
fetch
or
any
other
like
axios
with
indici,
would
they
be
able
to
do
it.
J
H
A
You
know
any
any
opposition
to
us
saying
that
you
know
indices
the
the
apis
that
we
focus
on
in
like
long
term,
you
know
we're
not
necessarily
agreeing
on
timeline
or
the
exact
shapes
of
the
apis,
but
like
at
some
point
in
the
future.
Our
strategy
is
to
expose
an
api.
That's
based
on
that
to
fulfill
that
intermediate
level.
A
D
I
would
target
note
5,
no,
not
18
as
experimental
as
I
said
like
it's,
I
want
to
make
it
very
real,
yep,
okay,
it's
it's
a
couple
of
months.
From
now
the
api
is
is
based
on
our
node
score
stream.
Implementations.
Those
have
dropped
their
experimental
warning.
We
can
ship
fetch
with
an
experimental
warning
and
then
I
don't
know.
A
Okay,
well
I'll
include
that
as
one
of
the
the
concrete
next
steps
in
terms
of
you
know
what
we're
going
to
try
and
do
in
terms
of
the
server
I
think
we've
agreed,
we
need
the
same
like
highlight.
We
need
a
high
level
api
and
an
intermediate
level
api,
but
I
don't
know
that
we
have
like
and
and
ronag
said,
that
we
would
like
to
develop
something
that's
consistent
with
indici,
so
I
think
we
could.
You
know.
Maybe
that's
an
agreement
we
could
have.
A
Is
it
you
know
that
api
should
be
consistent
with
indeed
dc.
You
know
I'll
probably
felt
right
this
time,
but
I
don't
know
if
there's
any
standards
or
things
like
we
have
on
the
client
that
would
that
would
you
know,
restrict
what
we
would
look
look
for
in
terms
of
how
we
would
expose
those
server
level
apis.
K
Like
it
would
be
nice,
it
would
be
nice
if
somebody's
learning,
the
new
apis
and
we
could
say
hey,
you
know
how
you've
used
fetch
in
node.
Well,
there's
a
backing
thing
behind
fetch
and
we
have
the
same
thing
in
http.
We
have
the
you
know
high
level
api,
which
is
like
fetch,
general
use,
and
then
we
have
the
lower
level
api.
That
is,
you
know,
allows
you
to
customize
more
things
right,
robert.
Does
that
sort
of
align
with
what
you
were
thinking.
P
P
K
K
K
Not
streams,
not
node,
streams
right
like
like
even
today,
pipe,
you
say
like:
can
you
pipe
the
res
to
their?
You
know
the
res
from
a
request
to
a
to
a
response.
Even
that
today
is
actually
pretty
darn
difficult,
like.
I
think
we
should
shoot
for
something
that
you
know
is
a
little
bit
more
fun.
Don't
do
it
yeah.
D
D
D
N
Through
there's
concerns
here
with
with
this
in
particular
like
if
we
talk
about
hp2
and
hp3
in
quick,
the
un,
unlike
hp1,
where
at
that
socket
layer,
socket
api
layer,
you're,
writing
and
it's
writing
directly
out
to
the
socket
both
hp2
and
hp3,
have
to
buffer
that
data
internally,
while
the
and
allow
the
framing
layer
to
figure
out
what
chunks
of
data
to
write
in
in
in
you
know,
from
what
streams
it's
going
to
you
know
me
take
me
text,
those
things
out,
so
there's
there's
going
to
be
some
fundamental
differences
there
and
how
that
flow
of
data
goes
and
where
it's
going
to
be
optimized
right
for
hp2
and
hp3.
N
It's
gonna
be
better
for
us
to
optimize
that
at
the
native
layer,
completely
away
from
the
streams
api
so
like
whatever
performance
improvements
we
can
make
there.
It
just
has
to
write
data
into
that
native
queue
made
of
layer
q
as
quickly
as
possible
or
read
data
from
it
as
quickly
as
possible.
That's
it
right!
We
don't
need
all
the
streams.
N
A
Okay,
we
we,
we
really
should
take
a
break
soon,
so
I
think,
like
in
terms
of
the
server
we
have
a
few
higher
level
principles
like
the
client
server.
Api
should
be
consistent
and
allow
easy
integration.
Things
like
piping
output
from
client
api
to
server
should
be
easy,
but
I
don't
think
we
have
anything
more
specific
to
point
to
in
terms
of
like
here's
the
standard
we
should
implement,
or
here
hear
the
apis
implementation.
We
have
to
start
with.
Is
that
fair?
A
A
So
what
I'd
say
is,
let's
take
a
say,
15,
maybe
20
minute
break.
I
don't
know
which
one
people
would
prefer
15
or
20.
D
A
So,
let's
say,
let's
say:
20
minutes,
so
we
are
going
to
come
back
at
and
I'll
round
it
up
a
little
bit,
it's
20
after
so
that
would
give
us
if
I
can
do
some
math
12
40
my
time
so
basically
20
minutes
from
now
and
we'll
pick
up
with
the
discussion
on
the
documentation
at
that
front,
we'll
go
through
that
and
then
at
the
end,
we'll
have
a
little
bit
more
time
to
sort
of
summarize
where
we're
at
the
next
steps
and
stuff
like
that,
yeah.
A
A
A
A
Okay,
so
I
think
actually
it
looks
like
most
people
are
back
and
since
we're
at
time,
and
we
got
lots
to
cover
I'm
thinking,
we
should
get
started,
so
everybody
can
put
their
hands
down
and
we'll
launch
into
the
session
of
documentation
just
like
http
kind
of
our
top
level.
A
Key
goals
are
to
discuss
whether
the
state
of
the
current
documentation
is
good
enough
to
ensure
future
success,
or
are
there
things
that
the
project
should
be
doing
to
improve
improve
them,
and
if
our
answer
is
while
they're
seeing
to
to
improve,
then
let's
try
and
document
the
specific
things
we
can
do
in
terms
of
you
know
what
should
our
strategic
direction
be
and
what
are
some
concrete
actions
we
could
take?
A
A
B
Well,
I
can
chime
in
and
say
a
couple
of
things.
You
know
rich
trott,
who
you
know
it
would
be
great
to
have
them
here,
but
I
think
that
they
have
other
obligations,
but
they
did
leave
a
note
in
one
of
the
issues
somewhere
and
I
can
find
that
and
put
it
to
the.
I
think
it
might
already
be
on
the
notes,
I'm
not
sure
yeah.
B
I'll
just
add
real
quickly
before
we
do.
You
know.
The
other
aspect
of
this
conversation
is
the
the
integration
of
docs
into
the
new
website,
redesign
work,
and
so
that's
another.
You
know
angle
of
the
conversation
that
we
could
have
and
it
could
even
relate
you
know.
Perhaps
in
the
integration
work
we
could
make
some
improvements.
You
know
in
that
effort.
A
Yeah,
I
think
that's
a
good
point.
I
kind
of
see
that
as
one
of
the
maybe
slightly
lower
level
like
after
we
talk
about
the
docs
themselves
and
then
like
how
do
we
surface
the
docks
because,
for
example,
if
our
docks
are
all
in
great
shape,
then
maybe
it's
all
about
how
we?
How
do
we
get
them
out
there?
But
if
there's
lots
of
work
to
do
on
the
docks
themselves,
we
might
want
to
talk
about
that
before
we
dive
into
like
how
do
we
get
out
what
we've
got
kind
of
thing?
A
Yep,
so
does
anybody
want
to
add
or
or
start
a
discussion
or
or
we
could
go
through
the
notes
that
rich
started
to
do
that
would
which
would,
I
guess
I'll
say,
speak
up
if
you
think
we
should
do
something
other
than
starting
through
the
notes
that
rich
left
as
joe
suggested.
A
Okay,
joe
I'd,
ask
if
you
wanted
to
go
through
that,
although
I
see
you're
still
chewing
so,
but
if
you'd
like
to
take
us
through
that
list,
that
would
be
great
sure.
B
Yeah,
I'm
just
eating
some
fruit.
I
can
take
a
break.
Let
me
bump
back
to
the
notes
here
so
rich
said:
wow
scrolling
scrolling
scrolling.
Here
we
are
from
notes.
Some
notes
from
rich
search.
Functionality
was
one
and
and
do
we
have.
Let
me
actually
look
at
if,
if
rich
kind
of
sets
it
up
so
he's
in
case,
I
can't
make
it
which
is
likely
things
that
could
improve
documentation,
but
that
also
I'm
not
entirely
sure,
are
needed
or
should
be
priorities
over
other
doc
and
non-doc
things.
B
So
that's
kind
of
the
context
of
these
comments,
search,
search,
function,
functionality
and,
in
parentheses,
is
google,
bing,
yandex,
etc
sufficient.
You
know
one
thing
we're
looking
at
on
the
the
website.
Redesign
work
is
in
integrating
algolia.
If
I'm
not
mistaken,
that
could
integrate.
You
know,
search
functionality
into
the
docs
as
well,
automated
generation
from
jstoc
in
a
consistent
format
and
parentheses,
or
is
js
doc,
not
something
that
provides
all
the
information
that
we
need.
Question
mark
and
I'll
go
through
these
and
we
can
dig
into
them.
B
You
know,
as
we
want
separation
of
here's,
the
api
reference
and
here's
a
breezy
explanation
of
how
to
use
the
thing,
or
maybe
it's
good
that
they
appear
in
the
same
place.
I
think
this
is
something
that
we've
talked
about
in
the
past
as
well.
You
know
documenting
the
api
itself
versus
you
know
how
to
implement
certain
aspects
of
the
apis,
also
more
consistent
layout,
slash
organization
and
editorial
voice,
which
which
is
interesting.
Something
to
dive
into
a
couple.
B
More
is
the
one
page
per
module
approach
working
or
should
we
adopt
something
more
like
an
mdn
approach,
where
it's
one
page
per
function,
which
says
I
like
our
current
approach,
but
I
find
it
hard
to
imagine
the
alternative,
so
I
might
not
be
comparing
it
against
anything.
Next
bullet
point
is
stuff
is
in
surprising
places.
B
If
you
don't
know
where
to
look
as
an
example,
if
I
see
processed
standard
in
unref
method
in
code,
I'm
going
to
look
in
the
process
dock,
it
won't
be
there
if,
I
know
a
thing
or
two
about
how
node.js
works
under
the
hood,
which
I
shouldn't
have
to
in
order
to
use
the
docs.
I
might
look
in
streams
where
I
will
also
have
no
luck.
B
Maybe
I'd
eventually
find
it
in
nets
and
wonder
why
I
had
to
go
on
the
wild
goose
chase,
a
good
example
of
how
it
can
be
hard
to
find
specific
things.
Two
more.
Let
us
please
get
rid
of
the
knowledge
base
leave
tutorials
to
the
community.
There
are
some
things
in
the
knowledge
base
that
should
be
preserved
on
the
site,
let's
move
them
to
the
docs
and
then
the
final
one.
B
The
team
splintering
of
the
nodejs.org
website
team,
dachshund
core
the
core
docs
team
and
the
nodejs.dev
website
redesign
team
is
a
problem,
and
then
he
says
in
parentheses,
and
yet
is
it
question
mark?
And
I
I'll
just
comment
on
that
one.
I
think
it
is.
B
I
don't
know
if
problem
is
the
right
word,
but
something
that
we
should
remedy,
and
I
think
that
that's
the
point
where
we
are
at
on
the
website
redesign
team
that
we
want
to
work
more
with
the
docs
core
team,
as
well
as
the
website
team
itself,
and
then
even
like
the
build
and
release
team
to
make
sure
that
all
the
things
that
they
would
need
would
be
covered
as
well.
B
So
I
think
you
know
that's
the
point
that
we're
at
on
the
redesign
effort
and
want
to
start
to
make
those
connections
and
cross
collaboration
I'll
leave
it.
There.
A
P
So
I
will
say
that
right
now,
I
definitely
feel
even
as
somebody
who's
used
node
for
a
long
time,
the
page
for
modules
getting
unwieldy,
especially
now
that
we
have
various
pages
that
are
not
related
to
modules
but
features
as
well
like
packages
and
things
like
that
and
there's
a
side
effect
of
having
single
pages
per
api
like
unref
or
something
like
that
is.
You
can
link
to
them
from
many
places
pretty
easily
they're
not
associated
with
the
net
module,
for
example,
necessarily
yeah.
So
that's
it.
I
Yeah,
I
was
just
gonna
sort
of
mention
that
you
know
we
talk
about
docs
as
sort
of
one
one
whole
encompassing
topic,
but
I
mean
it
is
actually
in
like
different
bits.
So
you've
got
the
api
documentation
and
that
is
part
of
the
core
repo
it's
built
as
part
of
the
the
sort
of
node
builds.
So
when
we
do
release
builds
or
the
nightly
builds,
we
build
the
api
documentation
and
then
that
is
uploaded,
as
is
to
the
current
node.js
or
website.
I
So
in
that
respect,
we
are
building
the
api
as
part
of
the
node
build.
There
are
other
bits
of
documentation,
like
the
current
website
has
like
knowledge
base
articles
they're
built
as
part
of
the
website
build,
so
they
are
outside
of
the
call
repo
in
a
different,
build
workflow
and
then
yeah.
I
You
know
I,
I
guess
one
of
the
questions
I
have
is
things
like
as
part
of
the
build
we
spit
out
like
a
json
file
as
along
with
the
html
documentation,
and
I
wonder
whether
there
are
flows
where
we
should
perhaps
be
doing
less
sort
of
end
user
formatting
in
the
node
sort
of
release,
builds
and
sort
of
just
trying
to
get
information
published
and
then,
like
the
actual
sort
of
end
user
sort
of
formatting
search
on
top
of
it.
I
You
know,
and
the
actual
presentation
should
be
perhaps
outside
of
the
static
build
that
currently
exists,
because
at
the
moment,
if
you
actually
wanted
to
change
documentation
on
the
website,
our
process
is
actually
then
the
api
documentation.
The
process
is
that
it
has
to
go
through
a
release
cycle.
I
You
know
you
have
to
pr
into
into
core
and
then
actually
cause
a
release
to
happen,
even
if
it
was
just
to
update
like
a
typo
in
one
of
the
api
pages.
So
so
that's
the
sort
of
current
status
of
where
we
are.
A
A
We've
said
we
documented
we've
documented
the
documentation
is,
is
is
one
of
the
key
things
that
we
need
to
focus
on
for
the
success
of
nord.js,
but
actually
that's
a
pretty
wide
scope,
so
we
should
maybe
start
by
listing
out
some
things
like
you
know,
there's
the
api
documentation
there
is,
I
guess,
the
knowledge
base,
which
is
I'm
not
I'm
not
when
you
say
knowledge
base,
I'm
not
quite
as
sure
what
people
mean
by
that.
But
like
is
that
like
like
how
to
do
things
stuff
on
the
website?
And
yes,
we.
I
Assume,
like
okay,
it's
very
good
yeah.
I
know
I
was
just
saying
we
do
have
articles
on
the
node.js
on
the
main
node.js
website
they're.
Quite
they
tend
to
be
quite
old
in
that
I
I
don't
know
if
they
were
leftovers
from
earlier
incarnations,
or
we
tend
not
to
publish
new
knowledge
based
articles
to
the
main
website.
I
I've
got
a
feeling
on
the
dev
website.
That's
probably
more
current
in
terms
of
the
articles
that
are
outside
the
api
docs
I
mean
joe
joe,
probably
knows
more
about
that
that
sort
of
contributions
I
know
rich-
has
views
on
the
knowledge
based
stuff,
that's
currently
on
node.js
org
and
it
being
out
of
date
and
not
being
being
less
helpful.
Being
there
then
sort
of
dot.
A
M
Name
is
canonically
guides
and
it's
it
goes
everything
from
getting
started
with,
like
you
know,
the
classic
hdb
server
in
like
11
lines
of
code
into
like
it
goes
from
getting
started
to
debugging
to
easy
profiling.
M
It's
all
over
the
place,
yeah.
A
M
I
I
would
also
say
joe
joe
linked
it,
but
I
would
say
the
learn
thing
on
node.js
dev
is
different
than
guides.
It
is
a
you
know.
20
000,
word
piece
that
was
donated
to
us
or
licensed
to
us,
or
I
don't
know
what
the
correct
word
is,
but
that
is
fundamentally
different
of
like
it
goes
through
everything
from
the
beginning
to
end
of
node.
Well,
not
everything,
but
it
goes
through
a
lot
of
like
getting
people
to
intermediate.
I
think
that
is
fundamentally
different
than
the
guides
is
that.
M
Would
just
say
right
now
it
is,
it
is
learned
on
the
node.js.dev
site
that
is
like
you
know
the
the
structure
of
what
it
is.
B
And
interestingly,
I
was
talking
to
manish
yesterday,
where
I
I
can't
remember
where,
but
people
are
linking
to
node.js.dev
as
like
a
place
to
learn
more
and
also
as
an
example
of
the
gatsby
implementation.
But
my
point
being
like
I
don't
know,
I'm
actually
getting
off
topic,
never
mind,
but
people
are
using
the
learn,
section
and
nodejs.dev
pointing
to
it.
B
Learning
path,
yeah,
and
I
see
many
posted
the
link
that
I
was
thinking
about-
that
he
shared
with
me
yesterday,
technical
documentation,
links
to
nodejs.dev.
A
Okay,
so
any
other
sort
of
broad
categories
of
documentation
that
we,
you
know,
should
discuss
this,
maybe
frame
the
discussion
in.
A
Going
to
note
that
down
as
like
aspects
that
we
should
think
about
too,
because
I
think
that's
important
like
we
should
come
out
of
this
to
say
well
like,
is
it
key
to
the
future
success
that
our
documentation
be
internationalized
then,
maybe
which
subsets
and
stuff
like
that
right?
So
I
just
want
to
so,
but
but
I'll
put
that
on
that
other
list
and
just
kind
of
keep
trying
to
drill
down
here
and
like
are
there
any
other
large
categories
of
documentation
that
we
think
we
should
have,
even
if
we
don't
have
it
like?
A
I
A
E
P
P
P
A
A
A
This
is
like
you
know,
in
a
perfect
world,
in
terms
of
documentation
that
would
be
available
for
the
project.
What
what
are
the
major
categories
that
we
should?
You
know
that
that
would
that
we
could
have,
and
then
we
can
go
through
the
process
of
saying
like
well,
which
ones
are
the
most
important?
A
M
I
I
think
observable
observability
and
tracing
and
all
of
that
stuff
monitoring
that
that
space
is
something
that
we
should
care
about,
but
I
realistically
don't
know
if
we'll
get
people
to
actually
be
able
to
create
that
content,
but
in
the
perfect
world.
That
is
something
I
would
like
to
see
right.
A
A
M
I
mean
in
in
that
vein.
I
also
think
you
know
we
talk
a
lot
about
how
to
write
node.
We
don't
talk
about
a
lot
about
how
to
actually
deploy
it
and
like
we
leave
that
up
to
a
lot
of
people
so
like
how
do
you
use
meaningfully
use
node
in
docker
or
in
you
know,
other
containers
yeah,
I
think,
there's
like
actual
like
real
world
usage
of
node
is
fundamentally
different
than
here
is
how
you
use
these
modules,
and
I
think
that
that
deployment
side
of
things
is
another
one
right.
A
I
I
guess
that
could
be
rolled
into
like
installation.
I
think
we
have
had
in
the
past
people
asking
just
basically
how
to
install
node.
We
have
a
wiki,
I
think,
on
the
with,
like
a
page,
but
not
actually
on
the
website
other
than
the
bit
that
directs
people
to
alternate
like
package
managers
and
things.
A
Yeah,
I
know
I
think,
that's
another
good
one
like
if
we
start
to
think
through
what
typical
people
are
trying
to
do.
It's
like
yeah,
I
gotta,
install
it.
I'm
gonna
operate
it
I'm
gonna,
deploy.
A
A
B
And
the
one
thing
that
that
popped
into
the
chat
is
like
you
know,
I
know
currently
the
the
blog
the
news
section
on
the
nodejs.org
is
is
for
like
releases
and
stuff,
but
we
have
medium
and
all
this
other
stuff,
as
well
with
the
new
website,
we
could
do
a
blog
easily
and
get
rid
of
medium,
which
is
a
more
problematic
platform.
M
Like
I
don't
wanna,
I
don't
wanna,
pin
things
on
the
new
website
shipping
to
take
action
in
other
areas,
yeah.
A
And
let's,
let's
yeah,
I
think
that's
like
a
total
different
sort
of
path
we
could
go
down
through.
I
think,
though,
we
should
I'll
put
it
for
later
discussion.
We
should
talk
about
where
different
types
of
documentation
make
sense,
so
we
can
go
back
to
like
not
necessarily
like
new
versus
old
website,
but,
like
we've
got
a
good
list.
A
A
Okay,
if
not
maybe
what
I'm
thinking
is,
is
going
into
that,
where
makes
sense
so
we
could
like.
I
can
take
that
list
and,
if
you're
following
around
in
the
notes,
I'll
paste
it
into
the
where
now-
and
I
guess
you
know-
might
be
a
little
bit
premature-
if,
like
you
know
in
terms
of
priority,
I
don't
know,
may
that's
a
good
question
I'll,
throw
it
out
to
this
group
like
should
we
we
can
look
at.
A
You
know
prioritizing
these
different
things
in
terms
of
like
how
important
we
think
they
are
relatively
into
our
future
in
terms
of
the
the
project's
future
success,
we
can
look
at
where
they
should
go.
We
can
look
at
like
how
good
a
state
we
are.
We
are
on
each
of
these
I
don't
know.
Maybe
the
prioritizing
is
a
good
one,
so
that
like,
if
we
run
out
of
time,
we'll
we'll
start
it
with
the
most
important
ones.
What
do
people
think.
M
M
B
I
was
gonna
say
you
know,
like
I
think,
like
michael
was
saying
we
have
less
than
an
hour.
We
should
figure
out
what
the
most
impactful
use
of
our
time
is
right
now,
and
my
thinking
is
like
api
documentation
and
like
kind
of
examples.
M
The
the
thing
I
would
say
is,
I
I
think,
rather
than
looking
at
what
we
can
like
add.
I
I
think
we
should
try
to
look
at
what
we
can
get
rid
of
and
like
what
we
can
improve
by
shifting
things
around
or
deleting.
Quite
honestly,
like,
I
think
the
guides
is
a
very
low
hanging
fruit,
one
it's
not
maintained,
but
you
know
outside
of
that.
M
I
think
you
know
bradley
brought
up
a
point
earlier
about
the
the
interspersing
of
like
pages
docs
pages
for
concepts
rather
than
docs
for
api,
and
so
like
figuring
out
how
we
can
make
improve
that
and
then
also
improve
the
actual
experience.
Like
you
know,
I
I
talking
to
people
who
have
been
using
consumers
of
node,
but
not
necessarily
contributing
to
the
project.
For
you
know
a
decade
they
hate
the
doc
site.
M
The
dark
side
is
useless
in
many
cases
to
them
and
like
rich
brought,
that
up
of,
like
you
know,
rich,
pointed
out
a
very
specific
experience
that
that
he's
had
around.
Like
you
know
some
specific
concept.
I've
had
very
similar
experiences.
Where,
like
I
am
looking
at
a
a
a
api
thing,
I
haven't,
if
there's
no
code
example,
I
have
to
go
to
a
different
thing:
to
try
to
figure
out
what
it
means.
M
I
go
to
another
thing
and
there's
a
code
example
for
the
first
thing
I
was
looking
for
and
so
like
that.
That
is
not
a
good
flow,
and
I
think
we
should
really
be
trying
to
focus
on
improving
the
developer
experience
of
the
docs,
rather
than
perhaps
adding
or
changing
what
we
currently
well,
rather
than
adding
to
what
we
currently
have.
B
Yeah
I
I
would
generally
agree
with
that.
I
think
that
we
should
focus
right
now
on
api
documentation.
I
I
don't
disagree.
That
guide
should
probably
just
be
killed,
but
I
think,
like
everything
below
that,
should
be
a
separate
discussion,
so
we
can
focus
on
what
is
you
know
the
most
important
here
and,
and
frankly,
you
know,
is
complex
and
has
a
lot
of
aspects
to
it.
There's
just
the
api
documentation
work.
B
A
B
A
Priority
priority
one
is
api
documentation.
Is
there
anything
else
like
basically
for
saying?
Let's
ignore
everything
else.
Does
everybody
agree
that
that
you
know
getting
that
right
and
making
progress?
There
is
more
important
than
looking
at
any
of
the
other
documentation
aspects,
or
should
we
have
a
few?
Are
there?
Is
there
anything
else
that
fits
into
that
priority?
One.
A
B
Yeah
yeah,
I
mean,
I
think,
those
other
things
below
the
list
are
all
important
things.
I
just
think
that
api
documentation
alone
is
a
very
big
thing
to
tackle,
and
I
kind
of
get
the
impression
that
that's
the
main
thing
that
when
people
say
we
need
to
improve
documentation,
that's
what
they're
talking
about
like.
Like
you
know,
tierney
was
saying
I
know
we
have
a
mutual
friend
that
comments
that
they've
been
using
them
for
years
and
still
gets
no
value
out
of
them.
A
Right
so
I'm
just
looking
through
the
rest
of
the
list
of
like
so
you
know
the
release,
change
notes.
I
think
if
we
didn't
have
that
there'd
be
screen,
but
we're
probably
good.
If
I
look
through
all
the
other
things
like
the
how
to
install
how
to
upgrade
yeah,
I
could
see
they're
all
important
but
they're,
not
necessarily
you
know
we
haven't
had
them
so
far
and-
and
we
probably
should
fix
our
api
docs
stuff
first
right
yep.
Can
anybody
sort
of
disagree
with
that.
B
I
think
if
we
were
to
define
like
some
sort
of
working
group
around
this,
I
think
all
of
those
other
things.
This
whole
list
would
be
great
to
have
that
be
a
part
of
that,
but
again
api
documentation
being
priority.
One
right.
B
And
I
think
that
comes
back
go
ahead.
I
was
gonna
say
the
current
guides
as
they
exist.
I
think
we'd
probably
get
some
agreement
that
they
should
maybe
just
be
removed
because
they're
old
and
not
updated,
but
similarly
there's
the
learning
path
on
the
node.js.dev
site,
which
has
you
know,
been
more
active
and
more
current.
A
Right,
so
I
guess,
but
it's
it's
getting
rid
of
what
we
have
today
versus
like
do.
We
believe
the
project
should
be
hosting
guides
because
it
comes
back
a
little
bit
to
the
discussion.
I
think
that
rich
had
in
his
list,
which
was,
should
our
api
docs,
be
just
the
facts:
here's
the
apis,
or
should
they
be
here's
the
apis
and
the
descriptive
information
that
tells
you
how
to
use
them,
which
ends
up
being
a
bit
more
of
a
guide
than
here's.
The
api
right.
B
M
I
yeah
I
it's
funny
to
bring
up
india
mdn
because
I
feel
like
what
we
have
now
is
very
similar
to
mdn,
in
that
I
never
find
those
guides
on
mdn,
because
it's
the
information
architecture
is
real
wonky
like
I.
I
think
that,
or
at
least
in
my
experience
and
like
my
how
I
perceive
things
it
is,
I
think,
in
a
perfect
world.
M
Yes,
we
should,
we
should
absolutely
have
content
and
guides
and
and
that
kind
of
stuff
I
think
in
the
world
that
we
live
in
historically,
we
have
never
been
able
to
staff
that
work
over
an
extended
period.
Right
like
we
might
get
someone
who
can
come
in
and
contribute
something,
and
then
we
don't
maintain
it,
and
then
we
perpetually
have
this
problem.
I
I
think
the
answer
to
that
question
should
be.
M
We
should
do
what
we
can
commit
to
maintaining
right
like
we
should
do
what
we
can
maintain
over
time
and
if
that
is,
if
that
is
presently
the
bare
minimum
of
you
know,
api
docs
and
doing
that.
Well,
I
would
prefer
that
we
put
our
effort
into
api
documentation
and
not
have
a
distraction
of
guides
or
something
else
yeah
and
then
like
eventually,
if
we
get
that
as
a
stable
base.
M
B
M
Yeah-
and
I
I
think
the
the
learn
page
on
that
site
is
genuinely
good
and
I
think
we
we,
I
think
we
should
keep
that
like
that.
I
think
we
should
keep.
I
I'm
pretty
strong
on
that
that
we
should
keep
that,
but
I
don't
think
we
should
have
the
existing
guides
or
you
know
a
number
of
other
things
that
kind
of
exist.
A
Then
the
question
is:
should
we
provide
a
place
where
people
can
contribute
guides
or
is
the
fact
that
you
know
that's
what
we've
tried
like
you
know?
People
could
contribute
them
there,
but
then
they
never
get
maintained.
They
get
out
of
date,
so
we
should
just
say:
no
guides
belong
somewhere
else.
M
I,
like
I,
am
happy
to
figure
out
a
way
to
basically
syndicate
stuff
from
the
community.
I
do
not
want
us
to
at
least
at
present
be
in
the
the
business
of
maintaining
content.
We
we,
we
cannot
maintain
content,
I
don't
think
right
and
if
we
want
to
syndicate
out
and
like
link
to
people
or
whatever,
I'm
fine
with
that,
I
think
that's
a
discussion
that
we
can
have,
but
I
I
don't
think
we
should
be
checking
content
into
get
and
then
publishing
it
to
energize.org.
A
So
that
that
that's
good,
because
I
think,
like
our
strategy,
let
me
just
I'm
just
going
to
write
here
like
you
know,
an
outline
of.
Maybe
what
we're
talking
about
in
terms
of
our
strategies
like
strategy
to
ge
is
like
and
correct
me
if
I'm
not
reflecting
what
we're
talking
about
like
the
first
one
is
like
focus
on
api
documentation.
A
A
So
we're
saying
that
kind
of
information
should
be
like
outside
of
the
scope,
but
maybe
we
provide
links
to
it
and
just
looking
through
the
other
categories
that
we
had,
like
you
know,
internal
documentation,
I
think,
is
maybe
still
that,
like
that
sort
of
goes
into
a
different
category,
right,
that's
internal
docs.
A
Maybe
what
we're
saying
is
that,
like
this
discussion,
should
focus
on
external
documentation
versus
internal
documentation.
I
agree
that
okay,
sorry
gee,
so
in
scope,
external
documentation,
external
documentation.
A
So
that
would
say,
okay,
that
in
scope
for
this
discussion
is
we're
going
to
focus
on
external
documentation
and
in
terms
of
external
documentation,
are
where
we
believe
we
should
focus
in
terms
of
actually
maintaining
things
is
on
the
api
documentation
and
the
release
documentation.
We
would
syndicate
everything
else.
B
M
I
I
don't
think
we
should
delete
the
learning
path.
I
I
think
the
learning
path
should
continue
to
exist.
However,
I
I
like,
I
also
don't
I
I
think,
of
the
list
of
priorities.
The
like
blinking
out
stuff
is
like
500th
there's
like
a
ton
of
other
things.
I
prefer
we
work
on
and
I
I
think
that
that
is
like
a
potential
thing
that
we
could
do
that
we
can
investigate
later
yeah.
I
I
don't
think
that
needs
to
be
a
priority.
M
B
A
A
I
Terms
of
priority
are
we
prioritizing
for
this
discussion
or
we
prioritizing
for
the
projects
as
a
whole,
because
they're
different
things,
for
example?
I
would
I
would
class
installation
as
quite
high
on
the
priority
list,
because
if
you
can't
install
nodes,
then
what's
the
point
of
the
api
docs,
but
we
don't
need
to
talk
about
that
right
now
I
mean
we.
We
might
acknowledge
that
it
would
be
good
to
improve
the
installation
docs,
but
I
don't
think
it's
a
productive
use
of
our
time
to
have
a
discussion
on
that
in
this
session.
I
Just
to
acknowledge
that
agreed.
So,
in
terms
of
for
this
session,
I
would
put
api
docs
at
the
top
priority.
It
might
not
be
the
very
most
top
priority
if
we
were
considering
from
an
overall
project
perspective.
You
know
what
is
important
to
the
project
as
a
whole,
but
in
terms
of
what
makes
sense
to
talk
about
now,
the
api
docs
would
be
the
one
place
where
I
think
we
would
get
the
most
value
from
having
discussions
agreed.
A
Just
trying
to
to
get
a
little
bit
of
an
agreement
on
our
strategy
of
like
what
do
we
think
is
in
scope
for
us
versus
out
of
scope.
So
for
what?
For
the
project
for
this
session,
yeah
in
terms
of
for
the
for
the
project
in
terms
of
like
we've,
said,
documentation
is
important
yep,
and
I
think
we
could
scope
this
to
external
documentation.
B
A
I
E
A
M
I
don't
know
how
you
don't
have
apis
without
examples
like
you,
you
have
to
show
people
how
to
use
them
like
you
can't
not
have
a
code
example
for
an
api,
which
is
a
problem
that
I
have
with
the
docs
of.
We
don't
have
good
examples
for
everything,
but
we
we
you
have
to
have
that
stuff,
like
I
don't
think
those
things
are
separable.
B
I
I
think
that
one
thing
that
we
could
discuss
here
as
well
too,
is
just
the
way.
Docs
are
you
know
a
part
of
the
repo
and
a
part
of
the
build
like
like
what
richard
was
talking
about
earlier?
Should
we
be
decoupling
docs
to
some
extent
or
you
know,
are
there
any
changes?
We
think
we
should
be
made
in
that
regard?.
A
Okay,
I
think
that's
that's
a
good.
I
just
added
that
as
a
bullet
point
to
dive
into
the
so
in
terms
of
scope,
I
think
people
have
said
yeah.
The
api
specs
obviously
have
to
be
there,
but
examples
are
part
of
good
api
docs.
Are
there
any
other
things
that
you
know
we
should
be
on
our
checklist
before
we
would
say
that
they're
good.
G
I
think,
generally
across
each
of
the
different
modules,
there's
not
really
a
consistent
format,
even
within
the
api
documentation.
So
if
we
did
agree,
yes,
we
need
the
api
methods
and
then
we
also
need
the
examples.
Having
that
consistent
across
all
of
the
docs,
I
think,
would
make
sense
at
the
moment
the
layout
is
different
in
each
module.
I
think.
I
This
this
partly
goes
back
to
the
whole
question
about
separating
the
actual
content
from
the
presentation
and
at
the
moment,
because
it's
all
sort
of
merged
sponge
together
in
one
you
get
the
inconsistencies,
because
if
you
want
to
change
the
presentation
of
certain
structures,
you
have
to
go
and
edit
each
individual
one,
whereas
in
theory,
if
we
had
a
slightly
higher,
you
know
if
we
were
publishing,
I
guess
information
only
like
content
only
but
then
left
it
up
to
something
else.
To
do
the
presentation.
I
The
presentation
then
could
decide
to
surface
the
information
in
different
ways.
You
know
it
could
decide
to
keep
things
in
separate
pages
or
merge
them
into
the
same
page.
I
I
don't
know
how,
but
it
would
it
would
sort
of
make
keeping
things
consistent
slightly
easier.
I
feel
if
things
were
sort
of
in
more
granular
sort
of
basic
blocks
in
in
the
repository
and
then
the
the
the
value-added
information
was
sort
of
somehow.
On
top
of
that,.
B
I
suppose,
and
I'm
not
familiar
enough
with
the
process
that
builds
the
docs,
but
you
know-
and
I
I
don't
want
to-
I
hesitate
to
bring
up
the
website
redesign
because
you
know
it's
not
ready
yet,
but
it
is
a
you
know:
static
site,
generator
type
platform
and
we
could
potentially
integrate
it
more
into
our
build
that
that
type
of
build
keep
the
presentational
aspect
separate.
B
Potentially
even
this
output,
you
know
markdown
files
with
special
tags
or
whatnot
for
all
of
the
different
versioning
and
things
I'm
not.
B
A
You
know
from
from
what
I'm
hearing
from
like
what
I'm,
what
what
richard's
thoughts
make
me
think
of
is
like
if
we
like
put
our
our
docs
we're
actually
in
just
in
a
structured
jason's.
Today
today
we
like
write
it
in
markdown,
which
is
readable.
Then
we
try
and
parse
it
back
into
a
structured
format.
A
If
the,
if
the
the
the
the
canonical
place
where
we
maintained
it,
was
actually
something
like
jason,
then
it
would
be
very
structured
in
terms
of
like
okay,
you
need
to
have
this
description
and
then
you
need
to
have
parameters
and
then
keeping
that
consistent
would
be
a
lot
easier
and
you
could
even
run
tools
to
transform
it.
The
flip
side,
though,
is
it,
wouldn't
be
readable
right.
So.
M
It
wouldn't
be
writable
either.
I
think
that's.
The
other
problem
is
like
writing.
The
documentation
of
node
out
in
jason
is
very
hard
right.
We
could
just
use
yaml
well.
I
But
what
one
thing
I
would
point
out
is
we
do
build,
so
we
at
the
moment
we
we
write
the
docs
in
markdown
the
build
process,
processes
that
and
spits
out
html
pages,
and
it
also
spits
out
a
json
file.
I've
always
been
a
little
bit
unsure
as
to
who
is
using
the
json
file.
It
does
sound
like
it
might
be
being
used
by,
for
example,
code
editors
like
ides
that
they
they
may
be
consuming
the
json
file
to
do
like,
like
the
sort
of
code
hints
or
help.
I
I
I
No,
I
was
just
good,
I
was
gonna,
say
I
I
I
don't
object
to
there
being
a
build
step
in
build
for
docs.
I
I
just
think
it's
at
the
moment.
It's
going
too
far
in
spearing
out
the
end
html
documentation.
I
think
there
should
be
a
separation
somewhere
between
the
build
process,
builds
something
and
then
something
else
is
consuming
that
data
to
turn
it
into
to
to
what
the
people
reading
reading
it
outside
of
developing
core
node
we'd
actually
be
looking
at.
A
So,
just
just
as
context
in
the
in
the
session
on
typescript,
we
did
get
into
that.
That's
where,
like
you
know
the
jason
so
the
session
on
types
I
should
say
the
json
is
consumed
by
them
and
it
and
we've
got
some
actions
and
goals
to
improve
that,
so
that
it
will
be
better
structured
and
more
easily
consumable
and
stuff
like
that.
So
it
that
that
part,
but
I
think
it's
interesting
you're
making
me
wonder
if
we
could
also
use
it
to
generate
our
html.
I
That
that
that
would
be
my
sort
of
preferred
route,
because
then
we
have
even
more
more
more
reason
to
keep
the
json
format
consumable,
because
if
we
were
consuming
it
ourselves
right,
then
another
sort
of
use
point,
because
at
the
moment
I
know
we
had
discussions
about
the
types.
But
I
I
don't
actually
have
confidence
that
you
know,
even
if
we
make
changes
we're
almost
relying
on
them
to
tell
us
if
we
break
anything,
we
are
looking
at.
A
B
Output,
but
it
seems
odd
to
me
to
write
in
markdown,
convert
it
to
json
and
then
convert
that
to
html.
That
seems
strange,
but
that
being
said
vanessa
you
had
your
hand
up
and
then
put
it
down.
I
just
want
to
make
sure
that
you.
A
A
B
Well,
well,
it
depends
because
I
don't
know
if
we
can
build
our
html
documentation
from
the
json.
I
don't
know
if
all
of
the
metadata
that
needs
to
go
along
with
it
like
versioning
and
whatnot
is
outputted
into
the
json.
Maybe
it
is
and
we
could
well,
I
guess
what
I'm
saying
is.
It
sounds
like
we
would
be,
making
more
work
for
ourselves
just
to
kind
of
have
this
validated
pipeline,
which
maybe
is
important.
B
M
Can
I
also
ask,
is:
have
we
validated
that,
like
the
release,
information
is
important
like
the
the
metadata
that
we're
attaching
to
different
documentation?
Is
that
important?
Do
we
know
that.
B
M
Like
it
would
be
no
so
that
that's
different,
though
what
you're
saying
is
different
than
what
we
have
okay
you're
saying
that,
because
our
documentation
is
built
per
version,
if
you're
looking
at
a
version
of
docs,
you
should
be
looking
at
the
version
you're
using.
Not
you
know
not
and
and
like
basically,
in
the
docs.
M
The
metadata
is
the
very
inconsistent
from
what
I've
seen
inclusion
of
like
references
of
what's
changed
per
thing
and,
like
all
all
of
the
changes
or
some
of
the
changes
selectively
per
you
know,
methods
or
whatever
kind
of
api.
So,
for
example,
like
I
don't
know,
hdb
like
some
listen
method
on
http
right
like
there
will
be
a
block
of
like
cool
this
pr
changed
this
and
the
spirit
changed.
I
Sorry
richard
I
was
going
to
ask:
how
do
we
do
that
validation?
So,
even
though
we
publish
versions
of
docs
for
every
release,
I
believe
that
most
people
are
going
to
the
website
to
read
the
docs
and
the
docs
are
only
pub
the
the
docs
are
published
for
every
version,
but
they're
only
linked
to
from
the
main
site.
I
No,
that's
not
true,
they're,
not
only
the
easiest
path
to
the
docs
is
the
latest
docs
for
a
particular
release
line
so,
for
example,
for
node
17.
If
you
go
to
the
website
and
you
click
docs
you'll
be
taken
to
the
latest
docs
for
the
latest
version
of
note
17.
I
Now
you
quite
right
in
saying
that
you
should
be
looking
at
the
version
of
the
docs
for
the
version
you're
using
but,
for
example,
if
you're
using
17.1
and
something's
been
introduced
in
17.4,
you
are
probably
not
directly
looking
at
the
171
docs
you're,
probably
on
the
website.
Looking
at
the
17
docs
for
the
current
17
release-
and
I
guess
then
the
value
of
the
metadata
is
to
point
out
when
the
variable
will
sort
of
help
post
or
discussion
occurs
and
says.
I
I
M
Right,
I
guess
the
other
way
of
solving
that
problem
is
having
explicit,
explicit
docs
published
for
every
version
and
then
using
the
version
you
you're
on
yeah,
and
I
guess
that's
fair-
that,
like
that
metadata,
like
I,
I
guess
like
having
a
definition
of
why
this
metadata
exists
and
what
the
use
case
is
and
then
like,
basically
having
a
thesis
of
like
this
is.
This
is
what
this
should
be
used
for
and
then
following
up
later
of,
is
this
being
used
for
this?
M
Is
this
actually
accomplishing
the
goal
that
we
have
that
we
have
for
it?
I
I
think
we
need
to
do
that
for
this,
because
it
does
seem
to
be.
This
metadata
is
particularly
a
painful
piece
for
us
and
we
don't
have
a
particularly
strong
answer
for
like
I,
I
like
there's,
no
there's
no
kind
of
decision
log,
I
guess
of
like
this-
is
why
we
added
this.
This
is
what
our
goal
is,
that
we
can
go
reference
of
like.
Are
we
accomplishing
that
goal?
M
I
think
that's
that's
more
of
what
I'm
poking
at
with
this
is
like.
Is
this
doing
the
thing
it
was
added
to
do
and
is
it
succeeding
in
that
and
is
there
in
if,
if
it
is,
is
it
the
most
successful
path
to
that
and
if
it's
not,
how
do
we
find
a
successful
path
for
that.
A
I
think
I've
added
that
to
a
future
actions
as
a
like
or
follow-on
actions
like,
I
think,
documenting
why
things
are
there
and
why
they're
important
does
make
a
lot
of
sense.
Yeah,
it's
part
of
like
sort
of
our
strategy,
is
like
this
is
what's
in
our
docs
and
here's
why
these
different
pieces
are
in
the
docs
will
help
us
surface
those
things
right.
M
I
mean
additionally
like
realistically
we're
all
going
to
die
someday
like
there
is
going
to
be
someone
who
has
to
maintain
this
and
making
sure
that
I
mean.
Maybe
maybe
I
don't
know
if,
when
we
are
we're
all
dead,
maybe
people
won't
be
making
this,
but
you
know
making
sure
that
we
can
have
people
continue
to
take
this
on
and
not
kind
of.
M
Have
it
stop
when
we
stop
working
on
this
would
be
like
and
having
informing
them
of
why
the
decisions
we
made
were
made
is
probably
a
good,
a
good
approach.
A
So
I
I
I
wanna,
we've
got
20
minutes
left,
so
I
think
what
would
be
good
would
be
to
try
and
figure
out
what
are
the
key
things
we
need
to
work
on
to
improve
them.
I
think
we
we've
agreed
that,
like
the
the
api
docs
most
important
part
and
what
they
actually
are
are
api,
specs
and
examples,
and
then
the
the
question
is
like
what
is
it
that
we
can
change
in
terms
of
what's
there
today?
That
will
give
us
us
a
you
know,
a
specific
improvement.
I
think.
A
Like
beth
mentioned
consistency,
you
know,
I
think
you
know
tony
you
just
mentioned
like
if
we
could
explain
why
the
different
pieces
of
the
information
are
there
and
like
use
that
to
drive
what's
useful
or
not
yeah,
and
what
what
else
would
people
add
to
that
list
of?
You
know
key
things
to
do.
M
I
I
also
think
just
expanding
on
that
tiny
one
like
we're
talking
about
getting
rid
of
guides
documenting.
Why
we
think
guys
shouldn't
exist
right
now
is
another
thing
that
I
would
include
in
that
kind
of
category.
A
Okay
right,
so
I
think,
like
I
will
say,
like
to
document
our
strategy
document,
our
documentation
strategy,
which
is
the
like.
That
would
explain.
Well,
we
think
you
know
the
the
these
are
the
areas
of
documentation.
These
are
the
ones
that
we
think
are
most
important,
and
this
is
where
we
believe
they
should
exist
like
in
guides.
We
could
say
yeah
they're
important,
but
they
belong
outside
or
curated,
or
something
right
like
that.
A
That
I
think
is,
would
be
documenting
what
you're
kind
of
talking
about
right,
because
that
could
that
would
be
used
to
support
like
okay,
let's
get
rid
of
the
guys
right,
like
that's
a
very
concrete
action:
yep
yep,
100.,
so
documentation,
documentation,
strategy,
document,
documentation,
strategy,
consistency
across
packages
and
and
that,
where
you
know
maybe
we
can
we
have
time
we
can
get
back
to,
but
like
that
gets
back
into
like
how
do
we
build
them?
How
do
we
structure
them?
A
The
the
document
you
know
document
the
document
metadata
and
what
it's?
For?
What
else
can
we
like
the
key
things
to
work
on
in
terms
of
those
api
docs,
I
mean
somebody
mentioned
internationalization
before
I
think
that
that
would
be
great.
I
don't
know
if
that's
like
our
you
know,
is
that
one
of
our
top
priorities
in
terms
of
success
going
forward
or
is
it
like
we
got
to
fix
a
bunch
of
other
things.
First,.
A
M
More
code,
examples
like
more
consistent,
good
examples
like
ideally
I
I
would
honestly
love
to
have
in
the
same
way
that
we
did
with
tests.
I
would
love
to
have
a
basically
a
list
of
every
single
method.
Every
single
you
know
piece
of
the
api
that
does
not
have
a
good
example
and
basically
try
to
start
working
on
that
tripping
that
down
and
giving
every
single
one
of
them
a
good
example.
M
Also
I
mean
that
ends
up.
You
know
that
ends
up
being
a
skill
thing,
but
we
can
deal
with
that
later.
I,
I
think,
that's
a
big
one,
I
think
making
sure
we
have
more
pros.
I
think
there's
a
lot
of
things
that
are
very
lightly
documented
and
assume.
M
You
have
knowledge
like
what
you
know
like
what
rich
mentioned,
making
sure
that,
like
basically
that
it's
a
a
well-connected
piece
of
information
right
so
like
if
you're
talking
about,
I
don't
know
one
one
module
in
your
your
you're
referencing,
another
module.
M
A
A
M
Under
every
method
like,
for
example,
I
don't
know,
let's
not
use
cluster,
I
don't
like
cluster.
Let
me
for
url,
for
example
url
I
don't
know
url
to
string,
have
a
you
know.
I
mean
this
one
does,
but
you
know,
url
seems
to
be
pretty
well
documented.
M
Url
is
actually
what
I
would
want
to
see,
although
I
okay,
so
I
was
scrolling
url
to
string,
is
the
one
codex
one
method
that
does
not
have
an
example
on
this
page
so
like
having
a
code
example
for
everything
that
shows
you
how
to
use
it
or
multiple
examples.
If,
in
the
case
of
there
are
multiple
ways
to
use
this
thing.
M
Like
it
is
useless
to
me
to
see
url.2
string
and
then
not
have
an
example
that
I
can
look
at
and
like
read
what
the
code
should
look
like
yeah,
I
don't
know,
I
I
think
we
really
need
to.
That
is
a
primary
thing.
We
need
to
do
and
I
I
don't
think
it
needs
to
be
in
line
in
the
under
the
heading
as
a
part
of
the
you
know,
as
a
part
of
the
markdown
for
that
portion.
A
M
I
really
don't
care
about
repeating
things.
Oh,
I
think
that
repeating
things
is
fine
like
specifically,
if
you're,
if
you're
saying
like
you
know
like
repeating,
requires
or
repeating
imports,
that's
fine,
it's
it's!
That
is,
that
is
very
normal
in
in
documentation.
At
this
point
and
like
how
I
mean
this,
is
you
know
a
very
normal
piece
of
content?
Is
people
skim
to
the
thing
that
they
need?
They're,
not
gonna,
be
re
they're,
not
reading.
F
I
agree
with
that,
but
I
don't
know
if
it
was
mentioned
before,
but
should
we
maybe
move
to
one
page
per
method
or
per
thing
like
many
more
pages
than
what
we
have
now,
instead
of
one
per
module.
F
Like
it,
it
would,
I
feel,
like
the
pages,
are
very,
very
crowded
now
and
if
we
add
more
examples,
it
seems
better
to
have
only
what's
relevant
to
the
the
thing
that
you
are
looking
at
on
the
screen.
M
I
I
think
one
of
the
the
things
that
I
would
prefer
is,
I
I
think,
having
you
know,
all
of
the
you
know,
net
docs
or
whatever
on
one
page
is,
is
generally
good
and
if
you,
if
you
like,
if
we
want
to
split
everything
up
into
their
own
pages
and
have
those
be
in
addition
to
like,
basically
compile
them
all
together
into
a
single
page,
I
I'd
be
more
okay
with
that,
but
being
able
to
control
f
and
like
cool
like
this
example
uses
net.connect,
and
I
want
me
to
figure
out
what
that
is
I'd
rather
not
have
to
like
navigate
away
from
the
page,
I'm
on
to
figure
that
out.
M
M
We
just
toss
a
crapload
of
like
docks
at
you
and
expect
you
to
kind
of
figure
it
out,
having
a
little
bit
more
structure.
M
To
that
I
think
would
be
good,
so
like
going
through
and
saying
like
here
are
all
of
the
methods
here
or
the
instance
methods,
like
here's
all
of
the
x
thing
and
like
going
through
and
basically
like,
separating
everything
out.
So
it's
more
structured
and
having
that
structure
be
consistent
across
the
entire
documentation.
M
Because
that's
another
thing
that
happens
a
lot
is
the
physical
shape
of
the
page
changes
from
page
to
page
or
from
doc
to
doc,
and
that
is
really
challenging
to
like
read
as
api
documentation
because
you're
having
to
mentally
remodel
every
time
you
change
a
page
or
you
know
half
the
time
you
change
a
page
so
having
applying
a
consistent
shape
and
structure
and
allowing
people
to
hold
that
in
their
head
and
then
go
to
like
kind
of
narrow
down
the
scope
that
way
to
get
to
the
things
that
they
need.
F
A
And
manish:
do
you,
have
you
had
your
hand
up
again.
H
M
H
Like
in
the
incremental
part,
I
just
had
one
thing
to
add
is
like
right
now
how
our
documentation
is
has
made.
Is
we
have
one
single
file
and
then
we
have
yaml
comments
in
them
that
separate
out
the
world
so
like
personally,
I
think
that
we
should
first
work
on
like
separating
them
out
and
separate
like
different
files,
like
version
files.
Maybe
we
can
get
them
out
from
the
single
page
that
we
have
single
md
finder
there,
and
then
we
will
have
more
scope
on
working
on
all
the
things
that
we.
A
The
one
thought
I
had
along
those
lines
was
what,
if
we
moved
each
method
instance
method
method
into
its
own
file
as
a
markdown
file,
like
we
said
writing
the
documentation,
markdown
is,
is
the
best
way
to
go,
but
we
had
a.
We
had
a
a
a
file.
I
don't
know
what
format
that
actually
pulled
together
the
methods
for
for
a
grouping.
So
basically,
like
you
know,
a
markdown
file
would
be
like
here's
the
method
and
it
would
talk
about.
A
Everything
would
have
a
certain
structure
and
then
there
would
be
like
categories
of,
like
instance,
methods,
regular
methods,
and
then
we
would
actually
pull
all
those
together
into
the
generated
documentation
through
some
more
structured
file.
That
told
us
like
okay,
well,
this
class
has
these
methods
and
then
it
would
go
and
pull
those
in,
and
that
would
let
us
do
things
like
if
you
want
to
totally
rearrange
the
order
of,
like
instance,
methods
and
methods
you
could
do
that
without
having
to
change
the
docs.
M
I
I
think
it
makes
sense,
I
think,
it'll
be
a
challenge
like
one.
It
does
get
rid
of
completely
get
rid
of
what
we
currently
have.
It
could
allow
us
to
have
metadata
separate
from
the.
M
Yeah
I
mean
it
could
be
nice
for
sure.
I
think
it
might
be
a
challenge
like
it
might
be
a
technical
challenge
and,
if
someone's
willing
to
do
the
work,
sure
I'm
not
opposed
but
yeah
it
it.
It
seems
like
it's
a
decent
amount
of
work,
but
yeah,
I'm
not
I'm
not
opposed
really.
I
I
think
if
we
decide
that
there
is
still
value
in
metadata,
I
kind
of
think
that
it
it's
more
beneficial
if
it's
together
in
the
same
file,
because
otherwise,
what
will
happen
is
they?
They
will
drift
and
not
be
updated.
In
sync,.
M
M
It
yells
at
you
to
update
the
the
the
docs
right
like
if
it
does
this
in
a
based
off
of
how
some
of
their
build
tooling,
which
is
very
nice,
and
what
we're
trying
to
implement
or
what
I'm
trying
to
implement
in
node.
M
But
you
could
you
could
very
if,
if
we
went
down
the
path
of
like
having
every
single
method
in
its
own
file
and
having
an
associated
metadata
file,
that
would
be
very
easy
of
like
if
you
change
one
and
there's
not
a
change
in
the
other
something's
wrong
yell
at
the
user,
in
the
pr
to
change
both
so
yeah,
like
I'm
less
concerned,
if
we
were
to
do
that
in
individual
files,
but
yes,
I
agree
if
we're
keeping
everything
together.
A
Okay,
so,
unfortunately,
we
have
six
minutes
left
and
I
have
a
pretty
hard
stop
just
thinking
of
like
next
actions.
A
Out
of
this
discussion,
you
know
if
I
pulled
a
few
things
out
from
this
from
what
we've
talked
about
is
like
documenting
our
strategy,
I
think
would
be
helpful
in
terms
of
like
if
we
get
consensus,
async
and
some
of
the
key,
the
key
aspects
that
we've
been
talking
about,
so
one
is
like,
I
think,
documenting
the
metadata
and
what
it
sports,
I
think
also
that
maybe
falls
into
that
is
like
the
the
getting
consensus
that
there
is
an
example
for
each.
G
O
M
A
I
I
was
gonna
say
we.
We
can
be
sort
of
naive
and
assume
that
that
they
need
to
at
least
have
some
code
fence
section
that
that
is
currently
how
we
sort
of
document
the
examples
there's
sort
of
co-fence
and
I
think
in
a
lot
of
places,
they're
co-founded
by
either
common.js
or
esm
in
some
places,
but
well
actually
that
that's
a
that's
a
point
as
well,
but
maybe
we're
looking
for
codefence
sections
with
appropriate
code
flags.
M
I
I
assume
there
is
some
way
to
figure
out
like
through
a
remark
plugin
or
something
if,
if
a
heading
exists,
that
is
a
like
in
inline
code
code
block,
like
you
know,
which
is
how
we
put
all
the
all
of
the
method,
names
and
stuff
assume.
I
H
So
like
on
node
on
the
new
website
redesign,
we
actually
had
some
like
in
page
live
examples
with
the
help
of
stack
blitz.
So
that
was
one
thing
that
was
added.
You
can
go
and
check
it
out,
so
we
can
check
for
those
blocks
like,
for
example,.
A
So
there
any
other,
like
I'm,
writing
down
document
next
actions.
I
have
document
the
documentation
strategy,
so
that
includes
document
the
metadata
and
what
it
supports
and
add
examples
which
is
like,
and
you
know
basically
document
documentation,
get
consensus
for
the
you
know.
Basically
that
every
example
has
every
method
has
an
example.
The
example
is
in
line,
and
you
know
part
of
that
would
be
then
figuring
out.
Can
we
actually
enforce
that
somehow.
A
I
I
I
believe
we
have
currently
got
docs
in
two
different
places
about
writing.
Docs
one
is
concentrated
on
style.
There
is
a
sort
of
readme
that
talks
about
structure,
but
the
it
only
talks
about
it
in
that
it
gives
you
an
example.
I
It
sort
of
sketches
out
an
example
file
with
some
mark
down
in
and
saying
make
your
thing
look
like
this,
but
it
doesn't
actually
go
beyond
that
in
terms
of
more
structures.
For
example,
it
doesn't
talk
about
the
difference
between
instance
methods,
or
you
know
other
things
like
that.
I
don't
believe
it
talks
about
examples,
although
there
might
be
one
that
just
happens
to
be
in
the
skeleton
document.
I
I
can't
remember
right.
I
remember
in
the
past
that
it's
confusing
to
have
those
the
style
and
the
structure
in
two
different
places,
and
I
was
kind
of
hoping
that,
with
some
of
the
stuff
that
was
going
on
that
came
out
the
last
session
in
terms
of
documenting
like
how
we
would
add
types
and
stuff,
we
would
try
to
slowly
build
out.
Yes,
please
sort
of
yeah.
A
M
I
I
need
to:
I
didn't,
remove
the
original
file
but
yeah
I
I've
got
to
drop
thanks.
Y'all.
A
So
yeah
I
do
have
to
drop
as
well.
I
have
a
few
next
sections,
so
I
will
take
the
action
to
try
and
write
something
out
from
this.
So
if
everybody
can
kind
of
review
that
and
add
in
and
and
then
help
to
pick
up
the
next
actions,
I
think
we
we
had
at
least
a
good
start
here
and
then,
following
that,
we
can
figure
out
whether
you
know
we
should
get
together
and
have
another
follow-on
or
something
like
that.
B
I'm
going
to
talk
to
trot
and
you
know
we
can
start
that
conversation.
I
think
it
would
be
a
good
thing.
A
Thanks
everybody
everybody's
time
and
we'll
see
you
in
github
and
hopefully
at
some
future
mini
summits
as
well.