►
From YouTube: 2020-08-19 JavaScript SIG
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
B
B
B
B
D
Let
make
this
a
little
bigger,
so
this
first
one
here
missing,
update
button.
I
didn't
add
this
and
I
don't
know
who
did.
D
Oh
okay,
well,
good!
Thank
you!
D
I'm
glad
that
that
is
fixed
without
having
to
mangle
the
history.
I
was
okay,
cool.
D
D
I
forgot
what
they
call
a
dist
tag,
or
something
like
that.
So
I'd
like
to
would
like
to
be
able
to
do
it
by
like
npm,
install
open,
telemetry
api
next
or
something
like
that
or
like
alpha,
and
that's
not
working
right
now.
So
currently
you
have
to
do
like
0.10.3,
alpha
28
or
something
like
that,
which
is
too
too
specific.
D
D
D
Caching
and
the
bootstrap
isn't
working
properly
or
it's
saying
cannot
find
the
module
for
all
the
dependencies
which
is
sort
of
weird
I've
seen
this
before
and
we
fixed
it
by
blowing
away
the
cash,
but
I'm
trying
to
figure
out
why
this
happens
in
the
first
place
so
that
it
doesn't
come
up
again.
So
hopefully
the
canary
build
should
be
working
soon.
D
I
know
that
at
least
the
guys
at
the
city
of
montreal
we're
waiting
for
that,
and
I
think
maybe
microsoft
also
yeah,
so
hopefully
that
will
be
working
soon.
Sorry,
it's
been
taking
so
long.
D
I
put
this
in
here
bart:
this
is
the
the
collector
split
pr
that
you
made.
I
was
hoping
that
you
could
walk
us
through
this
pr
a
little
bit.
It's
huge
honestly,
like
90
90
files.
Changed
is
really
hard
to
review.
I
was
trying
to
look
at
it
earlier
and
it's
just
not
immediately
obvious
what
the
change
is.
D
B
Well
previously,
we
had
one
package
and
basically
we
had
something
which
was
called
utils
and
what
is
for
grpc.
It
is
for
proto
and
just
a
general
and
doesn't
matter
which
version
you
needed.
Everything
was
installed,
so
the
speed
is
basically
to
keep
the
first
version
of
node
as
a
base
for
web
and
for
node.
B
This
is
just
a
js,
but
nothing
more
so
this
is
for
the
web,
and
for
now
that
this
is
a
gtp
json
over
http,
and
then
you
have
the
proto
version,
for
example,
which
basically
extends
the
basic
version
and
all
those
suites
that
were
just
only
for
the
protobuf,
the
other,
so
the
classes
are
called
exactly
the
same.
All
you
have
to
do
just
install
a
different
package,
and
then
it
will
use
just
a
protobuf
for
the
transport
layer,
so
it
basically
extends
the
the
the
version
from
the
exporter
node.
B
Okay
and
the
same-
and
this
is
for
grpc-
I
also
I
did
two
more
things
just
because
previously
you
had
the
issue
like,
for
example,
when
you're
using
sdk
and
basically,
if
you
want
to
use
grpc
or
protobuf
and
for
any
reason
you
would
like
to
instrument
either
a
grpc
or
proto.
B
The
collector
was
loading
the
grpc
already,
so
I
just
moved
this
require
for
grpc
to
be
lazy
loaded.
It
basically
look
like
that
for
init
method
and
for
sending
method.
Here
there
is
a
immediate
which
basically
includes
the
require
of
grpc
model
so
that
whenever
you
load
the
modules,
sorry
the
plugins-
you
shouldn't
have
this
situation-
that
you
will
see
the
warning
that
the
grpc
was
already
required
yeah
before
so
you
can
create
your
collectory
next
line.
B
You
can
create
sdk
package
or
anything
else,
and
then
the
load
module
should
basically
be
able
to
load
this
fast.
So
that's
the
only
change
according
to
what
we
had
originally
in
the
exported
collector
okay.
So
everything
else
is
just
splitting
the
existing
code
into
new
packages
and
including
also
the
test.
Yes,
I
also
divided
the
test,
so
the
base
package
is
it's
running.
B
All
the
tests
that
were
possible
and
the
proton
pc
are
running
just
a
few
more
tests
to
to
prove
it
that
if
you
use
the
protobuf
or
grpc,
the
the
the
spencer
metrics
are
still
exported
okay
and
there
was
one-
and
there
was
one
back
for
the
converting
the
the
labels
which
I
fixed.
Basically,
if
the
label
was
just
a
number,
the
matrix
couldn't
be
exported.
B
Yeah,
okay,
it
was
just
one
lineup
yeah.
I
got
it
okay,
but
other
than
that.
B
That's
that's
more
or
less!
And
now,
instead
of
having
the
proto
inside
the
main
package,
you
will
have
the
proto
ssr
module
in
those
two
packages
for
grpc
and
for
protocol
yeah.
D
I
saw
that
I
was.
D
Pr
earlier-
and
it
was
just
it's
just
so
big-
that
I
wasn't
sure
whether
you
had
changed
any
actual
functionality
or
whether
it
was
just
a
split.
So
I
just
wanted
to
wanted
to
ask.
B
The
there
might
be
some
of
the
duplication
in
the
test.
Alberta
functions,
but
they
might
be
just.
I
know
just
a
very
few,
because
the
grpc
and
proto
they
they
have
just
a
few
functions
that
that
are
the
same
but
other
than
that.
Nothing
more.
D
Okay,
I
did
I'm
not
sure
why
my
computer's
not
working
right
now.
I
can't
honestly.
B
D
B
I
mean
it
would
be
much
easier
if
you
basically
opened
the
pr
on
your
favorite
tool
and
just
cpc,
probably
the
change
and
how
it
looks
because
I
mean,
if
you've
simply
ignored
the
tests
and
you
just
look.
The
codes
you
receive
from
the
classes
for
exporter
collector
are
quite
quite
small.
Maybe
you
can
open
like
the.
B
B
D
B
B
Okay,
and
as
you
see,
this
is
done
just
once
on
here,
because
if
the
sun
doesn't
exist,
then
it
requires
it
sound
and
that's
it.
Okay
and
therefore
it
here.
So
we
exactly
the
same
because
in
it
or
it's,
it's
the
same
file
so.
B
D
D
Right,
okay,
before
we
move
on,
is
there
anything
else
you
want
to
say
here
or
are
we
good
to.
B
D
So
I
did
create
it's
pretty
basic
here.
A
new
base
plugin
the
important
file.
Is
this
one
right
here,
so
this
would
be
the
new
instrumentation
based
class.
D
And
the
idea
is
you
extend
it
and
then
you
implement
these
three
methods
which
are
all
or
these
two
methods
and
a
property
which
are
all
pretty
similar
to
what
we
already
have
in
the
old
ones.
So
it
should
be
pretty
easy
to.
D
A
D
So
essentially,
what
this
does
is
it
splits
the
instrumentation
from
the
sdk
entirely?
So
it
only
depends
on
the
api
and
doesn't
at
all
depend
on
anything
specifically
in
the
sdk.
D
Which
should
hopefully
make
it
easier
to
load
plug-ins
and
to
maintain
plug-in
dependencies.
D
D
But
if
you
create
the
tracer
provider
first,
then
the
resource
detectors
run,
and
you
can't
patch
certain
modules
if
they've
been
used
by
the
resource
detectors
like
node
fetch
is
used
by
the
grpc
resource
detector
and
in
order
to
fix
that,
we
need
to
be
able
to
load
these
plugins
before
the
resource
detectors
run.
D
So
what
I
did
was
I
created
a
separate
pr
that
changes
the
api
implementations
to
use
what
I
called
a
proxy
tracer
and
the
idea
is
any
tracers
that
you
acquire
before
registering
a
tracer
provider
become
full
tracers
when
you
register
the
tracer
provider.
E
D
D
You
don't
have
to
call
anything,
this
all
happens
behind
the
scenes,
so
the
api
works
exactly
the
same
way.
The
idea
is
the
the
idea
is,
if
you
do
api
dot.
D
D
B
Okay
and
what
is
really
the
last
step
before
any
instrumentation,
this
is
the
provider
registry.
Yes,
yes,
so
what?
If,
for
any
reason,
we
will
put
to
refactor
this
in
the
way
that
everything
will
be
will
behave,
some
kind
of
you
can
create
like
resources
and
so
on
so
on,
but
none
of
them
will
really
start
until
you
call
register.
B
B
D
D
Do
you
have
a
potential
solution
in
mind?
Would
you
like
to
give
it
a
try
or.
B
I
mean
just
this
just
idea
so
because
people
might
be
also,
you
know,
okay,
they're,
reading
the
documents,
but
I
mean
the
the
way
they
put
the
stuff
that
can
be
always
different
yeah.
What
really
wanted
to
be
struggle,
why
it
doesn't
work,
but
in
fact,
once
you
call
the
register,
it's
like
the
last
step,
yeah,
it's
once
you
call
it,
then
it
would
be
really
nice
to
just
start
all
the
pipeline.
B
So
it
can
be
basically
deferred
until
until
really
you
call
like
last
step
from
our
from
our
api
and
then
just
start
the
whole
pipeline
correctly.
So
we
have
the
full
control
over
it.
So,
even
if
someone
use
something
in
the
plugin-
or
I
don't
know
some
resources
or
some
third-party
library
that
you
don't
want
to
just
plug
into
load
before
reload,
like
even
maybe
with
the
ordering
of
the
plugins
which
plugins
should
be
load
first.
B
B
D
D
Let
me
try
to
without
without
having
without
trying
it.
I'm
not
sure
that
I
can.
A
B
So
you
can
have
like
a
full
control
like
try
to
defer
the
all
the
plugins
get
only
like
our
plugins
load
them
correctly
and
then
follow
with
the
next
one
situation,
including
the
resource
detectors,
also
just
idea
something
to
you
know.
Think
of
because
I
mean
we
already
have
this
problem
now
and
I'm
afraid
it
might
come
back.
B
B
D
Right:
okay,
let
me
try
it
and.
B
C
Let
me
just
one
thing
to
add:
oh
yeah
go
ahead,
yeah,
just
one
thing
I
was
going
to
add
about
proxy
tracers.
This
is
something
that
I
ended
up
like
looking
into
for
ruby
and
I'm
not
sure
if
the
same
applies
here,
but
I
think
it
maybe
does,
and
what
I
kind
of
realized
was
for
like
instrumentation,
that
we
control
or
instrumentation
that
kind
of
goes
through
through
kind
of
the
main
open
telemetry
system.
C
So
I
guess
that
would
be
something
that
subclasses
the
base
instrumentation
class,
that
you
have
like
it's
possible
to
kind
of
have
full
control
over
all
of
that
and
defer
things
to
sufficiently
late
in
the
process
so
that
you
always
can
get
a
a
valid
tracer.
That's
already
bound
to
kind
of
a
tracer
provider.
C
But
the
one
situation
where
I
found
that
they
will
be
necessary
is
like
kind
of
the
larger
goal
with
open.
Telemetry
is
to
have
instrumentation
built
into
libraries,
and
in
that
situation
like
I
found
that
we
wouldn't
have
control
to
defer
everything,
or
I
wasn't
able
to
find
a
way
to
easily
do
that.
C
D
Yeah
there
actually
used
to
be
wording
in
the
spec
that
required
that,
but
when
I
was
looking
for
it
this
morning,
I
couldn't
find
it.
It
might
be
an
otap.
C
D
Have
been
an
otep
yeah,
but
I
know
that
java
has
implemented
this
for
similar
reasons
to
what
you
just
said.
Where
they
have.
You
know
you
have
a
dependency
module
that
depends
on
the
open,
telemetry
api
and
acquires
a
tracer,
and
it
may
acquire
the
tracer
before
your
telemetry
is
initialized.
C
Yeah
for
me,
I
found
that
there's
something
that
we're
going
to
need
in
ruby.
We
don't
need
them
right
now,
but
as
soon
as
there's
first
party
instrumentation,
you
know
shipped
with
the
library
that
those
those
will
be
necessary.
C
D
Yeah
and
deferring
things
later
was
essentially
what
what
bart
was
suggesting
was
you
have
the
like?
The
the
exporters
defer
loading
of
the
their
dependencies
until
after
plugins
are
loaded,
and
when
we
have
control
over
the
plugins,
that's
fine.
The
other
thing
is
even
aside
from
first
party
instrumentations.
D
Is
that
if
you
have
somebody
that
creates
a
plug-in
that
we
don't
control
right,
some
some
community
member
creates
a
plug-in.
They
may
not
be
aware
of
all
the
load
order
issues
and
you
know
to
to
sort
of
make
it
so
that
they
don't
have
to
think
about
the
load.
Order
would
be
nice.
C
D
D
B
B
B
D
Okay,
so
I
think
that
this
actually
does
solve
the
issue
you're
thinking
of,
but
until
I
have
an
actual
example
of
a
plug-in
and
using
it
with
the
sdk
package.
It
may
not
be
obvious
why
so
I'll
I'll
expand
the
example
to
maybe
include
one
plugin,
maybe
I'll
rewrite
the
my
sql
plugin
or
something
like
that
to
use
the
new
plug-in
base
and
I'll
show
how
it
can
be
used
with
the
sdk,
but
users
shouldn't
have
to
think
about
it
at
all.
D
D
Okay,
should
we
move
on
to
the
next
topic
here?
Yeah,
okay,
I
I
added
this.
I
really
just
wanted
to
ask
people
to
review
it.
This
is
a
follow-up
from
a
pr
that
was
already
merged
by
one
of
the
interns,
and
this
is
essentially
just
cleaning
up
the
work
that
they
did.
D
So
I
want
to
make
sure
that
it
gets
reviewed
and
merged
before
we
do
the
next
release
so
that
we
don't
have
to
release
with
like
the
half
finished
pr.
D
If
that
makes
sense-
and
I
would
like
to
release
this
week
so
I'd
like
to
get
this
shutdown
unification
pr
merged
in
the
next
couple
of
days,
if
possible,
so
that
I
can
cut
a
release
because
we've
had
a
lot
of
changes
since
the
last
release.
D
I
mean
if
we
can,
if
we
can
get
this
merged
while
you're
on,
then
that's
that's
great,
but
if
anyone
has
any
comments
on
it,
then
obviously
we'll
have
to
wait,
but
that's
okay,
but
yeah.
I
just
wanted
to
ask
people
to
review
this
and
I
wanted
to
mention
that
the
the
pr
splitting
resource
detectors
is
merged
so
mark.
I
assume
the
next
step
here
is
to
move
the
split
packages
into
the
contributor.
D
Yeah
this
you're
talking
about
kong's
prs.
He
has
the
the
two
resource
detectors,
one
for
ecs
and
one
for
elastic
stock.
Maybe
yeah,
okay,
so
kong.
I
don't
know
if
you
noticed,
but
the
I'm
sure
you
pro
you
probably
saw.
The
resource
detectors
are
now
split
into
their
own
packages.
D
So
could
you
please
refactor
your
tprs
so
that
the
the
resource
detectors
that
you're
adding
are
in
their
own
packages?
The
way
that
you
can
use
the
ones
that
mark
created
as
an
example.
D
D
To
to
show
those
packages
and
then
we'll
just
move
all
of
them
in
the
same
pr,
I
think
would
is
that
what
you
were
thinking
mark.
E
I
had
set
them
up
for
a
package
per
vendor,
but
since
they're
unpublished,
if
you
guys
think
differently
like
yeah,
feel
free
to
address
it
in
pr.
C
I
think
that
makes
sense,
but
are
are
these
additional
detectors?
Are
they
amazon
so
when
they
go
with
the
aws
ec2
detector
or
I
might
think,
of
different
vrs.
D
F
Maybe
just
something
quick,
I
was
wondering
if
the
bug
I
put
up
last
week
for
the
default
spec
and
the
tracing
meter
provider
could
be
given
an
up
for
grabs
tag.
I
don't
think
I'm
gonna
have
time
to
address.
D
It
yeah
it's
not
assigned
to
anyone
anyways,
but.
F
I
will
there
you
go
great.
Thank
you,
yep.
Thank
you
yeah.
I
also
just
want
to
say
thanks.
This
is
my
last
week
at
google,
so
thank
you.
Everybody
here.
I've
had
a
lot
of
fun
working
on
open
telemetry
and
thank
you
for
all
your
help.
D
Yeah,
thank
you,
and
you
know
just
because
your
internship's
over
doesn't
mean
you
have
to
stop
working.