►
From YouTube: Node.js N-API Team meeting - Aug 9 2018
Description
A
A
The
first
thing
we
have
is
SQLite
an
API
port,
so
resolve
Mac
issue,
I,
think
that
were
passed,
a
Mac
specific,
but
there
was
some
issue
around
types
and
stuff
I
believe
in
Esha
submitted
a
PR
which
I
just
already
haven't
had
a
chance
to
look
at.
So
that's
on
my
plate
to
look
at
that
as
the
next
step
on
that
front,
investigate
use
of
pre
build
with
an
API,
so
I
think
Jim.
You've
made
some
progress
on
that
one
yeah.
B
I've
made
good
progress.
It
I've
got
all
of
the
technical
issues,
resolved
I'm,
able
to
build
and
upload
and
download.
So
it's
really
good
I
appreciate
your
feedback
on
the
issue,
so
I
will
make
that
change
and
use
just
an
API
instead
of
node
NPI
for
the
runtime
label.
That
will
make
the
package
names
consistent
with
what
we're
doing
for
node
pre
chip,
C.
B
C
B
A
A
D
D
This
results
in
that
in
that
leak,
right
where,
where
no
dad
on
API,
creates
this
data
on
the
heap
and
associated
with
each
function,
which
is
kind
of
okay
ish
if
you're
dealing
with
bindings,
but
if
you're
dealing
with
function,
factories
that
turns
into
a
leak,
yep
and
so
so
I
spoke
to
JSON
of
what
am
I
saying.
You.
D
C
D
We
need,
and,
and
by
the
way
here,
some
data
you
may
free
it
you
may
not,
but
the
bottom
line
is
I
need
to
know
when
the
object
dies,
yep,
so
so
I'm
working
on
that
and
it's
I'm
calling
it
nappy,
add
finalizer
and
internally,
it's
basically
a
copy
of
nappy
wrap,
so
I
moved
nappy,
wrap
too
v8
in
pull
and
and
I
added,
like
a
template,
parameter
for
whether
you
want
to
store
it
anonymously
or
not.
So.
D
A
D
That
won't
leak.
Yes,
you
can,
if
you
afterwards,
if
you
nappy
rat,
but
if
you
nappy
rap,
then
you
use
up
the
wraps
lot,
and
so
you
can't
wrap
anything
else
with
that.
So
it
can
be
done
and
it
can
also
be
done
and
no
the
add-on
api
by
using
nappy
rap.
But
then
but
then
we
create
a
distinction
between
objects
which
are
wrapped
using
just
plain
and
api
and
objects
which
are
wrapped
using.
D
A
D
No,
no,
no,
the
function
is
itself
a
JavaScript
object.
So
so,
if
we,
if
we
didn't
make
any
additions
to
an
API,
you
could
say
nappy
create
function.
It
returns
a
nappy
value.
That
is
a
function.
That
is
also
an
object,
because
functions
are
objects
right
right
and
then
you
and
then
you
pass
the
result
of
nappy,
create
function
to
nappy,
wrap
and
you're
done
right
because
wrap
has
a
destructor
exactly
exactly
so.
You
could
do
it
that
way,
and
in
fact,
in
fact
there
there
is
it's
a
fairly
strong
argument
for
doing
it.
D
This
way
and
therefore
not
making
an
API
addition,
because
functions
are
not
normally
things
that
Rapp
objects,
which
are
instances
created
from
constructors.
Yes,
those
things
you
do
rap
very
alright,
but
the
functions
you
don't,
however,
since
since
since
I
mean
conceptually
since
functions
are
objects
themselves,
it
is
conceivable
that
it
might
get
treated
as
an
object
and
wrapped.
So
so
you
know
we
could
go.
D
We
could
go
another
way
here,
which
is
to
change
the
documentation
and
say
that
if
you
need
the
data
associated
with
a
function
to
be
deleted
along
with
the
function,
then
just
call
nappy
wrap
right.
That's
the
function
to
not
be
wrapped,
however,
you
cannot.
You
cannot
use
it
for
anything
else
that
so,
if
you
have
one
byte
modules
and
one
treats
the
function
as
an
object
and
tries
to
wrap
it,
that
would
throw
an
epi
invalid
art
right,
but
but
okay,
so.
A
If
you
write
your
your
thing,
and
you
know
that
this
function,
you
created
is
gonna,
be
wrapped,
like
I'm
just
I'm
just
trying
to
think
of
when
it
would
actually
be
a
problem.
So
if
you're
only
wrapping
the
function
so
that
you
get
it
to
be
cleaned
up
yeah,
then
if
you
actually
want
it
to
be
wrapped
and
used
as
a
an
object
yeah,
you.
D
A
A
D
Okay,
okay,
but
okay,
but
there
there
could
be
two
reasons
for
wrapping.
One
is
is
that
okay,
some
native
data
needs
to
be
associated
with
this
function
and
to
the
function
itself
was,
was
created
by
a
function
factory
rather
than
a
binding.
So
if
you
create
like,
if
you,
if
you
have
a
function
factory,
then
then
you're
using
the
same
native
function,
but
for
different
reasons.
A
It
gets
you
the
the
freeing
of
data
that
the
data
the
function
itself
for
free
or
you
have
to
do
something
special
to
say:
okay,
I'm,
wrapping
it,
but
I'm
passing
in
the
you
know
the
extra
data
in
a
particular
way,
so
that,
in
the
end,
that
does
the
right
thing,
in
which
case
you're
sort
of
you
know
working
around.
You
know
you're
you're,
saying
well
by
passing
in,
say
the
extra
data
pointer
as
the
pointer
to
the
native
function.
C
D
Yes,
yes,
that
that
I
mean
the
thing
is
the
thing
is
yes,
it's
it's
an
unusual
use
case,
but
but
we
have
the
following
arguments:
working
in
favor
of
not
ending
a
new
API
and
that
is
functions,
aren't
normally
wrapped
relay
in
JavaScript
objects
or
instances
of
constructors.
Those
are
usually
wrapped
right.
C
D
D
The
hint
is
that
it's
just
there
just
in
case
you
need
an
extra
pointer
and
now
you've
used
up
the
extra
pointer
so
right
away,
you're
using
up
something
that
that
we
didn't
intend.
But
the
question
is:
is
this?
Is
this
a
corner
enough
case
so
that
so
that
we
can
just
say
just
go
ahead
and
do
that?
Because
you
know
it's
possible.
D
A
D
A
I
guess
what
I'm
you
know
not
looking
at
the
code
in
front
of
me
I'm
trying
to
understand
what
is
it
that,
having
so
say,
III,
do
an
object,
wrap
right,
yes,
I
just
want
to
do
my
regular
object
wrapped,
but
I
also
want
the
function
to
be
cleaned
up
because
it
happens
to
be
a
function.
Yes,
what
do
I
do?
That's
that's
different
from
just
a
normal
wrapping,
an
object
in
the
first
place.
Well,.
D
A
C
A
D
A
D
D
But
then,
but
then
you
could
only
unwrap
objects
with
know
that
on
API,
that
were
wrapped
would
know
that
on
API,
because
you
would
need
you
would
need
to
to
to
unpack
that
structure
and
return
the
payload
to
the
person
who
wrote
the
code
using
know
that
on
API.
Now,
if
you
pass
that
object
to
another
module
that
was
written
in
plain
an
API,
then
then,
then
the
that
object
would
not
contain
the
expected
pointer
but
would
contain
a
pointer
to
a
structure
that
is
defined.
Internal
means,
I'd
know
that
on
API
right.
A
D
D
A
D
A
D
A
D
That
was
my
starting
point,
but
but
basically
the
reason
why
I
ended
up
with
this
wrap
thing
is
because
I
realized
that
that
doing
it
specifically
for
a
function
is
not
enough,
because
then
you
need
to
do
it
for
nappy,
define
class,
and
then
you
need
to
do
it
for
nap.
You
define
properties,
because
because
a
property
descriptor
can
also
be
a
function
right
and
so,
and
people
need
to
change
their
code
anyway.
To
take
advantage
of
this.
Do.
D
They
do
yes,
the
the
Nappy
define
properties.
If
you
pass
in
a
nappy
callback,
it
also
accepts
a
void
star,
so
it
so
so
the
so
the
structure
of
a
nappy
property
descriptor
satisfies
all
the
parameters
for
nappy,
create
function
and,
as
such
also
has
the
shortcoming
where
you
cannot
add
a
nappy
like
a
nappy
finalized
callback
into
the
structure
we
didn't.
We
didn't
leave
room
for
a
nappy
finalized
callback
in
the
Napa
property,
descriptor
structure,
right.
D
So
so,
so
that's
why
the
best
solution
would
be
to
add
a
new
API
which
which
which
which
will
allow
users
to
retrofit
the
finalizar
onto
all
of
these
use
cases
with
a
second
napi
call,
rather
than
creating
a
version
of
that,
because
then
we'd
have
to
copy
a
bunch
of
stuff
over
and
and
and
it's
it's
very
difficult
to
factor
it
out,
especially
in
a
predefined
class.
Snappy
defined
class.
There's
a
lot
of
things,
and
so
you
cannot
simply
you
know,
write
the
new
API,
which
calls
the
old
API
and
does
one
other
thing.
D
You
know,
because
then
you
have
to
like
iterate
over
all
the
properties
again
check,
which
ones
where
functions
retrieved
the
JavaScript
function,
that
that
was
that
that
resulted
from
iterating
over
those
properties
in
the
in
the
first
place
and
then
and
then
add,
attach
the
finalizar
and
there's
another
problem.
If
you
have
getters
and
setters,
you
need
to
finalize
errs
one
for
together
one
for
the
setter
because
they
could
both
be
dynamic.
D
So
so
that's
why
the
best
solution
would
be
to
just
to
just
add
a
new
API,
because
all
your
values
are
available
to
you.
The
getters
are
available,
the
setters
are
available
as
nappy
values,
and
so
you
you
just
make
a
second
call.
You
pass
in
whatever
nappy
value
was
the
result
of
the
first
call,
and
then
you
attach
your
finalizar
which
which
which
implementation
aliy
is
exactly
the
same
as
doing
a
nappy
wrap
except
you
don't
assign
a
private
property
on
the
on
the
private
static
property,
on
the
object
sure
and
as.
A
D
A
D
D
D
Most
often
this
data
is
null
because,
because
you
have
one
function,
one
native
function
for
one
JavaScript,
the
binding
the
only
time
it's
not
null
is,
if
you
is,
if
you
create
functions
on
the
fly
and
and
we've
we've
had
issues
where
people
created
functions
on
the
fly
so
because
then
you
know,
if
you
create
a
function
on
the
fly,
obviously
it's
going
to
be
the
same.
It's
going
to
be
the
same
native
function.
You
cannot
create
native
functions
on
the
fly
except
there
with
great
difficulty.
D
So
so
so
so
that's
when
you
do
this
like,
for
example,
if
you
have
a
C
API
which
accepts
a
function
pointer,
then
then
you
almost
always
have
to.
You
know
create
this
kind
of
data.
You
know
when
you
have
to
create
a
JavaScript
function
which
behaves
differently
depending
on
depending
on
on
which
callback
it
is
right,
so
yeah,
that's
that's.
D
B
A
D
No
exactly
yeah
yeah,
it's
it's
it's
a
stretch
and
and
I
don't
have
enough
foresight
to
know
whether
that
stretch
would
be
enough.
You
know
like
if
we
just
went
if
we.
If
we
just
went
ahead
and
said,
listen
if
you,
if
you're
doing
function
factories,
then
then
just
use
nappy
wrap
to
to
free
afterwards,
but
be
aware
that
if
you
do
that,
you
cannot
use
nappy
wrap
again.
For
other
reasons.
D
That
may
well
be
enough
because
we're
dealing
with
functions
not
beat
up
with
objects,
but
the
clean
solution
and
and
Jason
Jason
saw
this
immediately
was
to
to
just
add
the
API
like
he.
He
just
reacted
off-the-cuff,
saying:
okay,
yeah!
Then
we
clearly
need
a
new
API,
so
you
know,
and
and
and
he's
he's
coming
from
kind
of
an
outside
perspective,
having
not
been
actively
involved
in
a
while.
So
so
that's
kind
of
a
good
thing.
Yeah.
D
A
A
D
It
creates
it
creates
another
one
of
these
I
don't
know,
I,
don't
know
what
to
call
it
this,
this
sort
of
juggle
where,
where
you
need
to
make
sure
that
everything
supports
it
and
so
forth,
because
you
know,
even
if
we
implement
this
and
if
even
if
the
PR
lens
tomorrow,
you
know,
even
if
we
back
port
it
and
all
those
PRS
lands
tomorrow,
we
cannot
simply
update
no,
that
on
API
and
and
make
use
of
it,
because
you
know
if
you,
if
you
build
against,
if
you
build
against
six
point.
C
D
So
so,
if
there
are
any
other
frameworks
which
which
which
place
like
an
in-between
sort
of
function,
signature
massaging
layer
like
a
thunking
layer.
Basically,
then,
those
two
will
be
faced
with
this
problem,
in
that
they
cannot
add
their
own
data
because
they
would
be
using
up
the
wraps
all
right.
Well,.
A
Yeah
I
guess
we'll
still
have
to
think.
Like
you
know,
does
it
make
sense
and
know
that
on
API
to
say
well
for
version
6,
if
you're
building
against
that,
maybe
we
use
wrap
behind
the
scenes
and
in
you
know,
10
we
would
use
the
the
newer
one.
D
A
C
A
C
A
A
D
A
D
A
I
guess
the
the
well,
because
you
said
PR
not
be
no
doubt
on
API
right.
If
we
actually
build
it
into
the
wrapper,
then
you
know
we
could
fix
the
leak.
So
people
don't
get
it,
but
we
assumed
this
lot.
Yes,
if
there's
a
way
actually
to
say
using
no
data,
API,
here's
a
way
to
wrap
it
yourself.
Oh
yeah,.
A
A
D
D
Funny
thing
is,
though,
if
people
use
this
and
they
do
the
the
wrapping
themselves,
then
eventually
the
you
know
yes,
I
could
be
a
very,
very
hard
requirement
to
actually
use
the
new
API,
because
everybody
will
already
have
solved
their
cleanup
problems
using
wrap.
D
Yeah
I
mean
yeah,
but
but
what
I'm
saying
is
there
would
have
to
be
a
very,
very
hard
boundary
at
that
point,
because
only
if
it's
impossible
to
to
use
to
use
nappy
wrap
as
a
workaround.
Only
then
will
there
be
a
definite
need
for
the
new
API.
You
know,
so
that's
that.
That's
why
I
was
saying
earlier,
like
nappy
wrap
may
just
be
a
sufficient
solution.
You
know
right.
A
D
A
A
A
A
Okay,
so
I
am
going
to
these
are
done,
it's
pretty
sure
these
real
done
so,
okay,
so
that's
good
we're
making
progress
there
I
think
that's
what
we
had
in
the
current
milestone.
So,
let's
flip
over
to
the
issue
where
we
were
talking
about
content
for
the
next
milestone,
we
have
it
just
a
few
more
things
to
finish
off
on
those
but
sounds
like
we're:
making
good
progress.
A
A
D
A
So
but
we
should
I
believe
right.
We
might
want
to
figure
that
out
then
and
then
say
like
if
we
can
understand
the
context
around
that,
because
we
we
do
want
to
actively
continue
to
have
examples,
and
we
just
need
one
place,
probably
where
it's
obvious
and
if
nothing
else,
if
we
can
make
that
note
out
on
examples,
point
to
ours,
that's
great
or
or
whatever
else,
but
yeah.
A
C
C
C
C
A
A
A
Be
able
to
ask
somebody
who's
made
one
or
I
think
who's
made
one
and
sounds
good.
Okay,
so
we've
got
focus
on
async
worker
racing
workers,
so
that
definitely
I
think
that's
good
continue,
focus
and
bring
them
the
issues
evangelism.
So
we
do
have
to
prepare
for
Jess
interactive
breakout
session
at
the
collaborator
summit.
So
one
thing
I
will
highlight
is
there
was
an
issue
opened
they're
gonna
have
like
a
community
corner,
so
there
is
the
possibility
to
submit
some
ideas
there
for
talks.
D
D
A
Is
let
the
collaborator
summit?
It's
basically,
you
know,
group
of
interested
people
break
out
into
a
separate
room
and
you
go
through
the
topic
and
have
a
discussion.
So
though
those
are
our
you
know
sometimes
they've
been
somebody
puts
a
presentation
up
front.
Sometimes
they're,
like
an
intro,
followed
by
discussion.
They're
meant
to
be
more
along
sort
of
a
working
session,
kind
of
thing.
D
A
I
was
even
I,
don't
think
you
were
at
the
last
call,
but
I
was
even
thinking
that
you
know
you
might
volunteer
to
put
time
that
together
it's
or
we
could
do
it
together
right.
It's
basically
a
here
the
structure
of
the
files
where
you
find
them,
and
then
you
know
generally
how
we've
been
working
to
add
things.
Yeah.
D
B
A
Don't
think
it
needs
to
be
more
than
like
10-15
minute
kind
of
intro,
and
then
you
know
we
have
time
to
talk
with
people
if
they
have
questions
answers
whatever,
but
we'll.
We
can
kind
of
sense
that,
as
we
see
who
shows
interest
when
we
get
a
little
bit
closer
sure-
and
we
can
think
of
other
topics
too
like
if
it's
often
a
work
group
gets
together,
so
we
can
use
it
as
a
Hayward's
we're
face
to
face
time
mm-hmm,
so
we
can
use
it
as
like.
You
know
that
week's
our
meeting.
A
A
Some
of
this
other
stuff
is
kind
of
like
a
way
to
pull
new
people
in
as
well
yeah,
but
the
thing
I
was
mentioning
is
that
they're
having
this
know
Jess
community
corner,
which
is
separate
from
this,
which
is
on
during
the
main
two
days
and
they're.
Basically
saying
you
know
it's
a
it's
a
way
to
get
more
node
focused
content
into
the
project,
because
there
was,
you
know,
a
few
comments
that
there
wasn't
quite
enough,
and
so
there's
like
30
minute,
15
minute
or
10
minute
talks
I.
A
A
We
might
come
up
with
something
else
on
the
evangelism
site
as
we
go
through,
but
I
think.
That's
to
my
mind.
Unless
anybody
else
has
things
we
should
add,
that's
probably
a
good
start.
Yep,
okay,
so
I
think
we'll
leave
it
at
milestone,
10
for
at
least
next
week,
and
then
you
know
once
we
close
out
the
last
couple
of
issues
we
can
move
on
to
focusing
on
11.
A
Good
I'm
a
heads
up
I'm
away
next
week,
so
I
won't
make
the
meeting
I,
don't
know
I,
guess
hopefully
aronia
sure
or
does
if
we
still
haven't,
figured
out
how
to
let
other
people
a
lot.
Everybody
hold
the
zoom
meeting.
So
maybe
you
can
fall
back
to
the
hangouts
for
that
one.
For
that
week,
yeah
probably
can
we
have
a
volunteer
to
chair.