►
From YouTube: Node.js N-API Team meeting - January 17 2019
Description
A
Okay,
so
I
just
think
we
should
start
with
this
one,
because
it's
kind
of
important
and
there's
it
links
in
with
some
stuff.
That's
timely
with
the
release
working
group
so
I
know
Gabe
really
you've
been
in
some
of
the
discussions
about
getting
TVs
and
backported
I.
Think
there's,
there's
basically
agreement
that
it
can
go
into
a
cember
minor
and
that
there
will
be
assembler
minor
done.
I
think
like
end
of
March
kind
of
timeframe,
yep.
C
A
A
So
steps
you
know
it's
basically
one
make
non-experimental
and
I.
Don't
think
that
needs
to
wait
like
we
can
make
things
a
non
experimental
and
master,
so
master
will
have
support
for
one
nappy,
one
for
nothing
else,
we'll
right,
yeah
and
then,
as
we
roll
it
backwards.
You
know
I
think
that's!
That's
fine!
Okay,.
C
A
A
That's
why
I
wanted
to
have
it
on
the
agenda?
It's
like
I
think
we
need
to
get
into
master.
Ten
will
will
should
happen
just
naturally,
but
eight.
You
know
we
want
to
I
think
we
have
this
one
chance
right,
yeah,
yeah,
exactly
I
mean
in
the
release
meeting.
There
was
also
a
discussion
about
saying:
hey.
We
should
plan
for
something
like
releases
kind
of
for
napping,
but
not
necessarily
specifically,
but
like
releases
where
you
can
get
important
changes
in
quarterly.
A
D
A
C
A
A
But
it's
if
you're,
if,
if
you,
if
we
argue
that
it's
not
cember,
minor
or
major,
to
change
it
while
it's
experimental,
then
when
is
it
cember
minor,
except
for
when
you
America
is
not
experimental?
Well
yeah,
so
that's
that's.
My
point
is
like
I
I
would
make
the
argument
that
when
you
market
is
not
experimental,
that
is
cember
minor
right,
because
it's
at
that
point
where
the
commitment
is
that
if
you
build
something
with
it
you
you
know,
you
could
depend
on
it
being
there
right,
whereas.
C
C
A
So
this
is
the
test:
I
always
uses.
If
I
built
against
something
in
version
say,
say:
we've
got
version
1.1,
right,
yeah
and
I
go
back
to
1.0
and
that
won't
work.
That's
ember
minor
right
right.
So
that's
that's
my
standard
thing.
However,
when
we
mark
something
as
experimental,
we're
basically
saying
December
rules
don't
apply
right
right.
So,
even
though
you
know
it's
so
it's
experimental,
we
make
a
change.
We've
added
a
whole
new
API
in
in
1.1.
Well,
it's
under
experimental.
So
there's
no
guarantee!
Oh
well,.
C
C
A
C
A
C
C
A
A
A
D
D
D
D
A
A
Jim
has
reached
out
to
the
maintainer
to
ask
for
some
of
his
cycle
time.
Also
on
that
front,
Anisha
I
think
is
figured
that
she
doesn't
have
enough
time
to
continue
working
with
us
at
IBM
or
or
on
as
a
student
on
call.
So
we're
not
gonna
have
her
to
help
push
that
forward,
but
Jim,
if
you,
if
you
sounded
like
you'd,
have
some
cycles.
So
if
you
kind
of
want
to
take
that
over,
that
would
be
great.
Okay,.
A
A
A
A
D
A
A
D
C
A
A
C
This
that
that
was
the
first
commit
the
one
the
one
I
landed
from
the
PRS
trying
to
figure
out
yeah,
I,
guess:
I,
guess
yeah.
This
isn't
that
used,
because
otherwise
people
would
have
complained
about
not
being
able
to
attach
that
at
these
descriptors,
but
doesn't
seem
to
be
that
much
in
demand
yeah,
so
yeah
we're
good.
Okay,.
C
When
we,
when
we
load
add-ons
and
they
are
being
loaded
using
the
classical
mechanism
whereby
you
know
you
pass
a
data
structure
to
know,
then
the
node
picks
out
the
the
the
initializer
from
the
data
structure.
At
that
point,
we
allocate
memory
because,
because
normally
the
the
node
module
data
structure
is
a
global
static
inside
the
inside
the
the
the
add-on
right,
because
you
declare
it
using
node
module
and
that
that
basically
declares
a
global
static,
variable
called
underscore
module
or
module
underscore
or
whatever.
You
know.
C
The
macro
evaluates
the
Declaration
of
such
a
structure,
but
in
our
case
we
need
to
heap
allocates
the
node
module
structure,
because
our
modules
and
API
modules
they
do
not
allocate
a
node
module
structure,
they
allocate
an
API
module
structure
which
incompatible,
and
so
so
so
when,
when
the
library
constructor
comes
in,
it
gives
us
this
napi
module
structure
and
we
create
a
node
module
structure.
And
then
we
call
node
register
or
node
module
register,
and
then
it
ends
up
calling
us
back
and
so
forth.
So
it's
it's!
C
It's
a
bit
of
a
dance,
but
this
these.
These
are
these
structures
that
we
keep
allocate.
They
we
never
free
them
right,
which
was
not
a
problem
so
far,
but
now
that
we
have
module
unloading,
I
was
thinking
about
how
we
might
be
able
to
sort
of
not
either
not
heap-allocated
them
or
or
somehow
free
them.
C
D
C
Any
integration
with
with
the
nodejs
environment
at
all
the
other
solution
would
be
to
do
to
statically
declare
it
like
modify
the
implementation
of
the
Nappy
module
macro
to
to
sort
of
follow
the
the
Nappy
module
definition
with
the
node
module
definition.
But
the
problem
with
that
is
that
the
size
of
the
node
module
structure
we
do
not
know,
because
we
cannot
include
note
h
from
from
from
node
API
dollar
8,
because
it's
supposed
to
be
a
C
file
and
no
dot
H
is
not
a
C
file.
D
C
You
know
it's
not
as
it's
not
as
if
we
had
like
an
explosion
of
allocations
if
the
module
gets
loaded
in
multiple
times
Brett,
but
it
is
sort
of
untidy
the
way
we
do
it,
and
so
that's
the
only
thing
I
was
thinking
about
is
maybe
we
want
to
tidy
that
up
somehow,
but
that's
yeah
I
haven't
had
a
lot
of
time
to
look
into
it.
It's
just
something
that
we
might
want
to
look
at
is
to
avoid
this
heap
allocation.
Yeah.
C
C
C
A
C
C
So
and
another
thing
that
that
is
sort
of
looming
on
the
horizon,
but
potentially
no
big
deal
is,
is
this
is
this?
You
know
this
node
module
version
issue
that
that
we're
having
yep
with
add-ons
in
general,
where
you
know
it,
it
announces
itself
as
no
module
version.
You
know
64,
but
you're
running
it
against
Debian,
and
so,
even
though
the
node
module
version
is
correct,
you
know
the
some
of
the
api's
are
incorrect,
and
so
you
know
we
were.
C
We
were
thinking
about
potential
solutions
to
that
and
I'm
trying
to
figure
out
how
any
PI
fits
into
this,
because
an
API
is
kind
of
above
the
fray.
In
this
case,
however,
if
the
if
the
n
API
module
uses
other
a
be
eyes
as
well
from
though
you
know
like
over
the
cell
or
libuv
or
whatever,
the
answer
is
today.
A
C
Yeah
exactly
that's
right.
Yeah
like
we
can't
cover
everything
right,
but
what
I'm
saying
is
that
if
we
introduced
a
mechanism
for
for
declaring
that
this,
this
addon
supports,
you
know
a
bi
version,
X
of
open
SSL
and
a
bi
version,
Y
of
libuv
and
API
versions,
end
of
node
itself,
then
then,
how
does
n
API
fit
into
that
right
like
do
we
become
one
of
the
many
ABI?
Is
that
that
node
exposes,
or
do
we
sort
of
stay
special
in
that
we
don't
really
care?
We
have
our
own
module
loading
mechanizing.
C
A
C
Yeah
yeah
yeah,
those
are
those
tools
will
definitely
have
to
be
have
to
be
updated
like
in
the
same
way
that
that
Jim
updated
them
for
an
API
right.
They
would
also
have
to
be
updated
for
for
all
these
various
api's,
because
yeah,
you
could
have
potentially
many
more
modules
for
like
if
you
want
to
cover
all
the
different
places
where
spawns
and
yeah
right.
A
C
A
A
C
But
then,
but
then
we
have
this.
We
have
this
situation
where
our
ability
to
multiply
load,
the
module
depends,
depends
on
the
load
they're,
finding
a
certain
specially
named
symbol
in
in
the
in
the
in
the
add-on,
and
so
so.
If
we
have
a
very,
very
complicated
version
which
which
supports
zeroing
out
this
and
that
and
then.
D
D
D
A
A
C
D
C
A
C
A
C
B
A
A
C
A
A
A
Be
more
flexible
if
you
could
say
well:
I
I
do
care
about
the
other
ones,
but
I
don't
care
about
the
node
API,
because
I'm
using
an
API
right
that
would
like
you
know,
even
though
you've
reached
in
and
it,
for
example,
on
the
lip
UV
front
if
it
hasn't
changed,
which
it
rarely
does,
you're
still
good,
you're
effectively
a
bi-stable
yeah,
so
ya
know
yeah
I,
think
that
puts
us
in
a
better
state.
That's
true!
Okay,
all.