►
From YouTube: 2020-07-22 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
D
E
E
Earlier
first
things:
first,
I
started
creating
a
pr
for
the
0.10.0
release.
E
I
had
hoped
to
make
it
before
the
meeting,
but
it
was
taking
longer
than
I
wanted
so
I'll
finish
after
the
meeting,
but
it's
been
a
long
time
since
we've
released,
so
I
think
we
probably
should
get
something
out.
E
E
I
suppose
I'm
going
to
open
the
pr
without
it,
but
so
I
noticed
that
the
build
failed
on
that
sdk
package
and
but
I
haven't
really
looked
into
why
yet
so
if
it's
simple
I'd
like
to
get
that
merged
soon,
I
I
think
it's
in
a
good
state.
It
just
needs
reviews,
so
I
think
it
has
two.
Maybe
it
has
three
but
I'd
like
to
get.
You
know
the
the
required
approvals
on
it.
So.
F
Yeah
I'd
like
to
reiterate
that
I
think
it's
in
great
shape
and
it
makes
the
sdk
super
usable.
I
haven't
looked
at
the
test
failures,
but
you
might
need
to
await
sdk's
start
here
and
there,
with
with
the
most
recent
round
of
changes.
E
Yeah,
probably
I
made
the
the
most
recent
changes
directly
in
the
github
ui,
so
I
did
had
no
editor
help
at
all,
so
I'm
not
shocked
at
all,
but
hopefully
it's
easy.
I
think
it's
just
testing
issues.
I
don't
think
it's
any
actual
code
problems
so.
D
E
I'm
also
going
to
merge
the
es
link
change
for
the
contrib
repo
is
a
huge
change,
148
files.
It
has
three
approvals,
but
two
of
them
are
maintainers.
If
nobody
has
an
objection
to
me
merging
this,
then
I'm
going
to
merge
it.
E
Off
we
go
the
other
one
that
I
would
like
to
merge.
Is
this
one
here.
This
is
actually
just
updating
the
code
cov
module,
which
is
dev
dependency
on
all
of
the
packages
and
contrib.
E
It
has
a
few
approvals
here.
Let's
see
what
looks
like
bart
must
have
just
done
that
yeah
15
minutes
ago
cool.
So
I'm
going
to
merge
this
one
to
just
because
it's
a
simple
dependencies
change
is
that,
okay,
with
everyone.
E
I
don't
think
we
I
we
talked
about
changing
the
rules,
but
I
didn't
I
didn't
finish
the
I
still
have
my
notes.
I
didn't
make
that
pr.
That's
actually
a
good
reminder.
I'll
just
add
that.
E
E
E
Because
I
actually
have
that
written,
I
just
need
to
check
it
in,
but
I
think
you're
right,
but
I
think
we
did
change
it
to
two.
E
The
the
the
meter
plug-in
pr-
and
I
guess
the
way
we
constructed
this
pr-
makes
all
of
the
plugins
backwards
compatible
and
we
inject
currently
inject
the
tracer
provider
into
the
enable
method
of
the
plug-in.
E
E
E
It
would
certainly
simplify
the
plug-in
loading
process
and
it
would
make
plug-in
plug-ins
behave
more
similar
to
how
we
would
expect
built-in
instrumentations
to
work,
because
we
would
expect
that
probably
to
use
the
global
apis.
E
H
Well
to
me,
it's
fine,
just
the
only
thing
that
I've
been
thinking
of
like
when
I
started
working
with
plugins.
H
E
H
Yes,
yes,
so
that
that's
my
only
point,
it
could
be
a
bit
more
confusing
that
you
have
to
register
your
tracer
meter
provider
before
you.
You
can
use
it
with
the
plugins.
E
Okay-
currently
you
do
have
to,
but
it
is
actually
in
the
spec
and
it's
one
of
the
deficiencies
that
we
have
is
that
if
you
use
the
global
tracer
provider
before
the
sdk
is
set
up.
So
if
you
acquire
a
tracer
before
the
sdk
is
set
up,
then
when
the
sdk
becomes
set
up,
that
tracer
should
work
right
now.
Ours
doesn't,
but
essentially,
instead
of
returning
it
on
noaa.
E
E
So
that
could
be
one
way
to
fix
this.
Maybe
we
should
implement
that.
I
mean
it's
in
the
specs,
so
we're
going
to
have
to
implement
it
eventually
anyways
right.
So
maybe
that
does
does
that
help
your
problem,
oh
yeah?
What
you're
thinking
right
is
that
you
instantiate
a
bunch
of
plugins
and
then
you
set
up
the
sdk
and
nothing
works,
and
that's
confusing
right
is
that
yeah.
H
E
I
H
Yeah,
but
so
how
do
you
want
to
move
on
with
this?
Do
you
want
to
for
now
for
the
this
pr,
do
you
want
to
just
use
the
global
tracer
or
I'm
not
sure,
if
you
check
what
I
did,
I
updated
pr
last
night
and
I
used
the
global
tracer
and
also
to
get
around
the
backwards
compatibility.
I
added
the
meter
provider
as
an
optional,
like
you
said
as
the
last
argument
in
the
enable
function.
H
So
should
I
remove
that
and
just
use
the
global
tracer
sorry
meter
provider,
or
should
we
continue
with
that.
E
E
E
E
E
H
So
what
if
yeah
true-
I
was
just
thinking
about
this.
If
we
remove
the
tracer
meter
provider,
I
mean
the
plugin
doesn't
have
access
to
oh
well,
I
mean
there's
probably
won't
be
need
for
the
plugin
manager
anymore,
because
that's
I
mean
for
at
least
for
the
web
plugins.
What
it's
doing
is
that
it's
just
passing
the
meter
and
tracer
provider
to
the
enable
method.
E
I
so
you
do
still
need
the
the
plug-in
manager,
at
least
for
node,
because
you
we
intercept
like
the
required
process.
Yes,.
B
Yeah
you
just
put
what
what
plugins
you
want
and
like,
for
example,
in
the
web.
I
might
see
like
reasons
why
people
might
have
want
like
a
couple
of
providers
with
different
plugins.
I
don't
know
that's
because
they
can
so
why
why
to
limit
yourself?
If,
if
you
can
have
it.
H
Yeah
that
I
also
agree
with
that,
like
that's
a
bonus
to
me
like
you,
can
all
use
multiple
providers,
I
don't
know
just
wanted
to
share
my
opinion.
F
Yeah,
I
just
wanted
to
add
a
little
bit.
I've
done
quite
a
bit
of
research
into
this
area
of
the
spec
and
as
it
currently
stands,
it
basically
says
that
you
should
be
able
to
support
a
multiple
tracer
provider
scenario,
but
you
can
only
have
one
global
and
it
seems
extremely
half-baked
and
the
use
case
fairly
unclear
as
to
how
household
actually
work,
because
there's
really
no
api
around
tracer
providers.
F
F
It's
hard
to
get
auto
instrumentation,
I
guess
to
work
with
them
unless
you're
explicitly
passing
them
in
my
gut
feeling.
Is
that
there's
like
a
missing
use
case
and
that
there's
the
need?
The
salute
like
the
need,
is
probably
there's
probably
a
different
solution
that
solves
this
need,
but
it's
just
something
that
hasn't
been
been
given
much
attention,
but
I
think
this
multiple
tracer
provider
use
case
is
the
cause
of
a
lot
of
pain
and
a
lot
of
like
I
don't
know,
a
lot
of
design.
F
There
are
kind
of
complications
and
misunderstanding
around
like
a
lot
of
design
issues
as
a
result
of
this.
So
this
is
like
the
whole
reason
that
I
kind
of
went
down.
This
rabbit
hole
was
figuring
out
like
why
a
resource
needs
to
be
on
every
single
like
span
in
the
export
pipeline
and
every
metric
record
like.
F
Why
can't
it
just
be
on
the
tracer
provider
and
go
directly
to
the
exporter
and
the
reason
ultimately
ends
up
being
this
multiple
tracer
provider
situation,
where
mult,
multiple
tracer
providers,
each
will
have
kind
of
a
static
resource
on
them,
can
technically
share
the
same
exporter
which
yeah
I
I
had
a
point
when
I
chimed
in
here,
but
I
feel
at
this
point
I'm
starting
to
ramble,
but
I
think
earlier
on,
in
the
conversation
I
wanted
to
say
that
I
kind
of
support
this
having
the
global
as
like
the
default,
or
at
least
like
a
fallback.
F
If
you
didn't
pass
something
in
at
a
bare
minimum,
and
I
feel
like
a
lot
of
this
predates
named
tracers
and
named
tracers
would
be
another
way
if
you,
if
you
wanted
to
have,
if
you
didn't
want
to
have
the
default
tracer
for
all
of
your
plugins,
you
could
have
your
own
implementation
with
tracer
provider
that
was
more
selective
and
intelligent
about
what
tracers
it
returned.
Two
different
plugins
based
on
name
tracer
functionality.
That's
another
avenue
to
switch
up
the
tracer
without
switching
up
the
tracer
provider.
E
Yeah,
I
mean
I
kind
of
agree
with
where
you're
going.
I
I
think
the
the
multiple
tracer
provider
use
case.
I
I
agree
that
I
I
don't
fully
understand
why
it
exists
like
what
the
use
case
really
even
is,
but
for
auto
instrumentation
like
the
the
plug-in
manager
is
just
going
to
inject
the
not
the
global.
Is
it
because
the
plug-in
manager
is
on
the
tracer
provider?.
E
Yeah,
I
I
guess,
since
I
don't
see
the
value
of
the
multiple
tracer
provider
use
case,
I'm
more
inclined
to
say,
let's
just
use
the
globals,
but
I
am
open
to
being
talked
out
of
that.
Like
bart,
you
said
that
that
you
don't
think
we
should
throw
away
the
the
multiple
tracer
provider
use
case.
E
B
Yeah,
I
think
it
would
be
easier
for
later,
but
we
can
also
ask
the
guy
from
the
from
the
specification
what
they
think
about
this
and
if
they
have
any
like
strong
opinion,
whether
we
should
have
like
one
tracer
provider
or
multiple,
but
maybe
until
now
you
just
don't
take
some
decision.
Yet
I
mean.
E
Yeah,
that's
fine,
so
I
guess
let's
leave
it
like
that
for
now
it
can
always
be
changed
later.
It's
easier,
it's
easier
to
remove
it.
H
So
I
think
the
global
tracer
meter
provider
returns
a
no
up
by
default.
If
nothing
is
set,
it
does
yeah.
E
And
then
matt
you've
worked
more
with
other
cigs
than
I
have
do.
You
know
in
their
auto
instrumentations.
Are
they
using
the
globals
typically
or
do
they
use
a
specifically
pass
tracer
provider.
F
Ruby
is
using
the
global,
we
kind
of
went
the
other
direction,
or
at
least
that
was
my
thought
is
that
if
we
turn
out
to
need
more
fine
grain
control,
we
could
add
that
in
later.
F
Yeah,
I
I
do
think
that
this
multiple
tracer
provider
use
case
is
kind
of
a
can
of
worms,
and
I
was
trying
to
like
muster
up
the
energy
to
crusade
against
it
and
kind
of
understand
exactly
what
needs
to
be
done
to
either
solve
the
use
case
solve
these
cases
that
it's
supposed
to
be
there
for,
but
in
my
mind,
until
you
have
something
like
a
tracer
provider
provider.
Api
like
like
you're.
F
The
only
way
this
is
usable
is
if
the
the
user
is
like
explicitly
managing
these
things,
which
already
seems
to
be
a
very
a
very
small
number
of
people
who
are
probably
going
to
to
be
doing
that,
but,
like
our
designs,
were
kind
of
bending
over
backwards
in
a
few
spots
to
kind
of
accommodate
this.
F
Usefuls,
I
don't,
I
think,
it's
kind
of
hold
over
from
either
like
a
census.
Use
case
I
feel
like
it
must
be
a
census
use
case
just
based
on
the
people
who
still
regularly
say
that
this
is
the
thing
that
we
must
have
when
I
bring
it
up,
but
I
think
I
think
there
is
a
better
solution.
Probably
I
think
really
what
this
comes
down
to
is
wanting
to
attach
different
resources
to
different
telemetry.
F
I
think
that's,
ultimately,
what
having
two
two
applications
in
the
same
process
means
to
me
is
being
able
to
say
you
know
these
fans
came
from
this
thing
and
that's
that's
generally
kind
of
the
resource
which,
at
this
point
in
time,
is
tied
to
the
process.
I
think
in
a
post,
otep
66
world.
It
becomes
a
lot
easier
to
try
to
get
this
data
onto
your
on
your
spans
through
stuff.
In
the
context,
or
maybe
even
correlations
could
solve
this.
F
I
don't
think
people
have
used
those
to
their
fullest,
yet
I
don't
think
there's
actually
any
spec
on
how
to
get
correlations
onto
your
span,
but
a
while
ago,
josh
mcdonald
did
this
proof
of
concept.
I
think
he
called
it
like
resource
scopes
or
something,
and
I
think
this
is
more
what
what
you
want
is
to
be
able
to
say
you
know
for
for
this
code
running
right
here,
attach
it
to
this
resource,
and
it
would
be
another
way
I
guess,
to
get
multiple
applications
in
the
same
process
without
having
multiple
tracer.
E
No,
it
did
it
just
it
makes
sense,
but
it
doesn't
help
because
it
doesn't
change
the
fact
that
the
spec
is
pretty
convoluted.
I
guess
maybe
I
just
don't
know.
If
that's
a
battle
that
I
want
to
start,
I
was
gonna
say
I
could
bring
it
up
in
the
spec,
but
I
don't
know
if
I
have
the
time
and
energy
to
defend
it.
F
If
you
want
to
raise
questions
about
it,
I
will
certainly
join
the
conversation,
because
I
think
it
does
need
some
clarification
and
I
think
ultimately,
I
think
there
is
like
a
use
case
there.
So
I
don't
want
to
like
rule
it
out
completely,
but
I
don't
think
multiple
tracer
providers
is
probably
the
ideal
solution
like.
I
think
it
would
be
awesome
if,
if
the
conversation
could
at
least
go
that
far
and
recognize
that
okay,
so
there
is
this
use
case
of
multiple
applications
per
process
that
we
want
to
solve.
F
But
maybe
this
is
like
a
post,
1.0
thing
and
possibly
the
complications
that
are
being
introduced
into
into
the
apis
and
just
general
export
pipeline
design
that
we
wouldn't
have
to
consider
trace
multiple
tracer
providers
and
be
able
to
clean
up
some
things.
There.
E
E
Then
you
don't
need
multiple
providers.
The
thing
if
that
doesn't
necessarily
solve
is,
if
you
have
like
separate
exporters,
but
I
don't
know
why
you
would
do
that.
So
I
that's
why
I
asked
who
originally
championed
that,
because
I
didn't
know
what
that,
if
you
have
two
tracer
providers
in
one
process,
monitoring
two
services,
is
it
because
you
have
two
different
resources
or
is
it
because
you're
exporting
to
different
backends
entirely.
F
Yeah,
so
the
thing
that
I
think
that
you
really
need
is
you
want
to
have
multiple
resources
and
since
you
can
only
have
like
one
resource
per
tracer
provider
like
the
the
solution
was
just
add,
multiple
tracer
providers,
but
I
think
what
you
were
just
bringing
up
with
named
resources.
I
think
this
is
more
along
the
lines
of
what
you
want
and
I
think
other
66,
the
context
improvements
make
this
possible.
So
really
you
can
have
one
tracer
provider,
but
have
something
in
the
context
that
ties
this
current
work
to
a
different
resource.
F
So
my
gut
feeling
is.
That
is
a
thing
that
will
solve
the
problem
and
probably
clean
a
bunch
of
stuff
up
but
yeah
in
the
same
way
that
you
have
been
mulling
over.
If
you
want
to
fight
that
battle,
I
kind
of
did
the
same
and
realized
that
I
was
a
little
over
oversubscribed,
but
if,
if
people
want
to
team
up
on
this,
like
I'd
be
game
because
I
think
like
I
think
the
current
situation
is
not
ideal.
E
I
guess
maybe
I'll
bring
it
up
in
the
next
spec
meeting
my
yeah,
if
they
just
have
a
good
answer
for
why
it
exists.
That
would
be
enough
for
me,
but
we've
used
enough
time
on
this
today.
I
think
I
think
this
is
really
a
spec
issue,
so
I
I
will
probably
bring
this
up
with
the
next
spec
meeting
and
we
can
go
from
there,
but
for
now,
let's
keep
it.
Let's
not
strip
out
the
the
inject
model
that
we
have
until
there's
a
more
solid
specification
decision
that.
E
I
don't
know
who
followed
or
is
still
paying
attention,
but
reza
did
you?
Did
you
get
that
we're
just
going
to
keep
the
injection
model?
We
currently
have.
H
Right
now
sure
so,
do
you
think
I
should
be
updating
like
the
documentation
for
plugins,
so
we
can
have
it
ready,
and
I
mean
we
can't
change
it
later,
but
for
now,
how
do
you
use
plugins
or
how
to
write
products?
H
E
E
Okay,
kong
is,
I
don't
know
if
I
pronounced
that
wrong
or
not,
but
would
you
like
to
speak
about
this
next.
G
Yes,
of
course,
with
my
opening
my
questions
mainly
like
several
parts,
the
first
part
is
that
I'm
going
to
migrate
the
original
id
generator
to
with
the
interface-
and
I
just
saw
your
comment
I
want
to
make
sure
here
we
might
would
you
like
to
make.
Let
me
migrate,
the
interface
to
the
under
the
core,
slash
source,
slash,
slash,
chase.
E
G
Okay
makes
sense.
The
other
thing
is
that
for
like,
because
I'm
aws
internet
I'm
going
to
implement
three
components
which
is
aws
x-ray
edge
generator,
also
the
propagator
and
resources.
G
I
saw
your
comment
on
the
on
the
issue
I
open
and
for
the
propagator.
I
think
it
makes
sense.
Maybe
I
should
like
place
my
code
under
the
javascript
country
repo,
but
for
id
generator
and
also
the
resources
I
didn't
see
any
corresponding
wrapper
for
them.
G
G
G
All
right,
I
basically
means
that
it
should
be
similar
to
our
existing
exiting
folder
on
the
main
repo,
which
is
open.
Telemetry
resources,
I
believe,
is
something
similar
to
that
button.
Yeah
yeah.
It
should
be
similar
to
that
seeing
from
the
existing
like
the
resource,
resource,
dot,
dot
resource
dot.
Yes,
it
has
all
provided
like
a
method
which
is
created,
lambda
sdk
resource,
and
what
I
am
going
to
do
is
like
to
re-implement
it
as
to
create
our
aws
resource
yeah.
It's
like
that.
G
Yeah
I
mean
yeah.
G
If
you
look
into
the
open,
telemetry
resources
folder
and
in
this
source
code
there
is
a
resource.ts
and
in
the
resource.js
it
provides
a
static
method
which
is
create
leverage,
sdk
resource,
and
I
believe
what
I'm
going
to
implement
is
more
is
like
it's
like
to
create
a
resource
for
our
aws
and
yeah.
That's
what
I
mean.
E
So
I
think
that
that's
just
a
resource
detector
isn't
that
just
what
this
is.
C
G
Not
a
jet
detector,
I
saw
I
have
a
radius
code,
not
not
not
for
detector
but
but
for
you
could
directly
over
in
the
source
code.
You
just
open
source
code.
You
will
see
a
resource
dot.
Yes,
but
not
under
the
platform.
G
Yeah
yeah,
I
believe
what
I'm
going
to
implement
is
necessary,
like
the
create
language
sdk
resource,
to
create
something
like
resource
for
aws
component.
G
E
G
Okay,
oh
yeah,
since,
since
also
for
me,
I
I
still
working
on
the
both
propagator
and
I
need
to
understoo.
I
still
don't
didn't
like
dive
deep
into
this
part.
Maybe
we
could
maybe
we
could
discuss
further
on
the
issue
I
opened
after
I
dive
deep
into
it.
G
E
So
for
the
id
generator,
I'm
not
sure
I
would
say,
probably
in
the
contributor
there's
no
place
for
that
right
now,
but
we
can
make
a
folder
for
id
generators.
G
E
I
don't
want
to
implement,
like
you
know,
some
vendor
specific
id
generation
logic
inside
the
core
repo.
I
don't
think
that's
that's
where
it
should
exist,
but
I
think
that
it's
probably
okay
for
contrib.
The
question
that
I
had
on
that
is
is
that
id
generation
method
publicly
documented.
E
Where
are
we?
The
id
generator
in
your
pr
has
generates
has
some
date
component,
and
things
like
that.
Is
that
documented
somewhere
on
the
aws
documentation.
G
Yes,
I
should
have
add,
add
link
in
the
annotation
of
my
code
and
maybe
yeah.
Let
me
let
me
find.
G
A
G
G
E
Yeah.
Okay,
if
that's
the
case,
I
think
the
truth
is
okay.
Okay
looks
like
mayor's,
not
here
but
bart.
Do
you
have
an
opinion
on
that
or
do
you
think
the
trip
is
okay.
B
E
Yeah,
I
think
that
that's
a
good
point,
so
yeah
document
it
in
the
code
exactly
what
you're
doing
and
then
maybe
also
add
a
link
back
to
this
yeah.
I
I
have.
E
C
E
Yeah-
and
this
looks
like
a
really
simple
implementation-
I
mean
this
is
all
tests
for
the
most
part
here,
but
the
actual
implementation
change
looks
pretty
simple
and
easy
to
understand.
So
I
don't
think
it
should
be
a
problem
I
would
say,
unfortunately,
it's
very
unlikely
that
it
will
be
ready
for
their
release,
because
it
has
no
reviews
and
I'm
hoping
to
release
like
today
or
tomorrow.
Okay
I'll
try
to
review
this
today.
E
E
In
addition,
I
added
these
three
pull
requests
here:
the
sdk
one
we
already
talked
about-
I'm
not
gonna,
go
in
depth
on
what
each
of
these
pr's
are,
but
these
are
all
I'd
like
to
get
them
reviewed
and
merged
as
quickly
as
possible.
I
understand
it's.
You
know
likely
that
they
may
not
be
ready
for
the
release.