►
From YouTube: 2019-10-16 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
C
C
C
E
E
D
C
C
C
So
the
first
item
on
the
notes
is
so
yesterday:
I
release
another
version
of
the
library
which
is
point
1,
dot
o.
So
that
is
because
there
was
some
issue
with
the
earlier
version
and
had
to
release
the
new
version
with
the
6
good
thing,
someone
from
I
think
Microsoft
they're
using
this
library
they're
building
their
own
SDKs
and
they
opened
the
issues
on
our
repo
regarding
the
uglier
version.
C
C
C
G
F
C
G
F
Just
remember
that
I
did
this
a
few
months
back
for
some
something
else.
I
can
take
this
again.
Let's
get
up
pages
that
yeah
I.
C
F
Is
something
we
have
to
then
that's
the
next
like
one
thing
is
generating
them.
The
other
thing
is
automating.
The
generation
of
it.
I
can
look
into
how
to
integrate
that
with
our
build
system.
What.
F
C
C
F
F
F
C
That's
a
good
point:
even
I
was
little
confusing
that
that
way.
So,
let's
say,
if
you
run
benchmarking
before
the
release,
then
we
might
skip
or
we
might
face
the
issue
during
the
release.
Actually,
then,
we
need
to
go
back
again
and
then
kind
of
fix
whatever
issue
or
show
whatever
stuff
we
added.
If
you
do
at
every
mulch,
probably
we
can
find
out
the
issue
at
that
time.
Emily.
G
I
mean
now
whatever
you
whenever
you
push
something
you
see
already
I
metrics
about
unit
tests
like
whether
in
time
going
up
or
down
so
maybe
we
might
have
exactly
the
same
formulas
if
that
is
possible,
so
that
could
be
really
nice
to
see.
Okay,
my
PR,
just
you
know,
broke
something
called
speed
up
things.
I.
F
Think
what
we
ended
up
last
time
was
just
the
a
little
bit
of
tech.
True
thing:
first,
without
storing
the
results
of
the
previous
or
the
current,
or
you
have
to
at
least
compare
it
with
the
last
release,
so
we
have
to
somehow
lock
the
last
release
like
performance
data
and
then
at
least
compare
it
manually
with
every
merchant.
The
second
thing
was
I
think
where
we
thought
about
that.
G
A
C
B
C
If
you
hundred
samples,
then
it
might
take
four
to
five
minutes
so
just
to
start
with,
if
I,
if
we
do
ten
samples
and
if
you
run
every
pull
request
just
to
see
how
things
are
running,
is
it
really
helpful
how
it's
really
solving
performance
issues
and
all
kind
of
stuff
and
then
eventually,
after
might
be
v3
or
v4
like
alpha
release,
we
can
kind
of
move
around
like
doing
the
release
or
doing
some
manual
stuff.
Anything
like
that.
C
C
C
F
Just
yeah
I
was
just
wondering
about
the
name
traces,
but
I
also
commented
on
the
people
on
the
PR,
our
the
basic
tracer
and
the
node
tracer
I'm,
basically
pretty
much
the
same
as
far
as
I
see
so
I
was
just
wondering
if
there
maybe
would
inheritance
would
be
better
to
avoid
redundancy.
That's
my
only
point
ahead
with
that.
Do.
B
F
C
B
I,
like
your
singleton
instance
stuff,
it
looks
really
good.
I
think
that
some
of
the
caveats
or
I
guess
some
of
the
like
the
weird
things
that
sort
of
came
up
was
like,
if
you're
doing
say
the
node,
tracer
or
I,
guess
just
like
sure
to
reiterate
what
IPR
does
right,
if,
like
we
have
a
tracer
factory
and
because
we're
currently
like
not
really
supporting
like
named
tracers
yeah
atieast
available
I
just
have
the
tracer
factories
for
trend
like
the
same
underlying
tracer
instance
for
everything,
but
so
I
wouldn't
be
interesting.
B
Questions
that
I've
sort
of
thought
of
that
I
don't
really
know
the
answer
to
is
in
the
event
that
get
tracer
starts
like
doing
get
or
creates,
and
we
try
to
create
a
new
tracer
for
a
Mladic.
We
create
a
new
trick.
Is
your
force
a
node
like?
Do
we
end
up
like
be
patching?
All
the
libraries
early
call,
the
plugin
libraries
that
we
have.
C
Before
we
talk
about
that,
the
first
thing
is
I
believe,
as
per
the
specs,
the
name
the
tracer
factory
should
be
in
singleton
instance.
All
your
tracer
should
get
attend
to
the
factory.
So
in
in
your
PR.
What
I
see
is
you
need
to
create
a
factory
every
single
time
when
you
want
to
create
nutrition.
B
C
So
that's
what
I
did
in
my
peer
I
have
one
tracer
factory
that
contains
the
map
of
your
name
and
version
plus
the
tracer.
When
you
put
some
name
to
your
tracer,
you
have
associated
tracer
instance
with
that.
Ladies
will
have
its
own
pressure.
Nobody
will
have
its
own
tracer
and
then
something
like
that.
Okay,.
B
Yeah,
it's
like
it
should
probably
close
into
an
issue,
because
I
was
looking
at
some
of
our
like
internal
white
stuff
code,
and
there
are
some
locations
where,
like
traditionally
with
the
open
tracing
model.
What
you
do
is
you
sort
of
create
a
single
tracer
and
unit
it
as
like,
kobol
tracer,
and
so,
like
all
of
your
packages,
sort
of
use
the
exact
same
tracer
at
runtime.
But
there
are
some
scenarios
and
our
code
base
is
something
yet
we
were
like.
C
I
think
that
that's
also
not
clear
so
if
I,
if
I,
want
to
control
it's
a
ready
stressor
and
with
that
few
attributes
or
few
options
right,
there's
no
way
to
configure
the
tracer
with
customized
attributes
yeah
or
you
even
let's
say
for
HTTP.
Let's
say:
I
have
two
HTTP
instance
running
one
I
want
to
use
beta
format
as
a
propagator.
Other
I
want
to
use,
let's
say,
trace
contacts.
C
B
Yeah
I
think
there's
like
an
interview
tips
like
other
changes
that
need
to
happen.
I.
Think
that,
like
our
plugin
object,
rather
than
having
like
it's
very
particular
like
all
of
our
plugins
objects,
are
they
inherit
from
the
same
plugin
class
and
that
one
has
like
a
sort
of
private
tracer
attached
to
it
that
you
can
access
and
I
think
we'd
have
to
move
away
like
all
that
would
have
to
change
as
well
and
go
to
the
like
critter
factory
get
tracer.
C
That's
true
and
another
confusion
for
me
was,
if
you
remember
last
time,
Ted
join
the
meeting
and
he
said
for
a
few
applications
or
users.
We
want
to
put
minimum
code
into
their
application
to
start
tracing
and
collecting
the
metrics
like
like
one
or
two
lines
of
code.
If
you
go
with
this
tracer
Factory
I
am
not
really
sure.
How
are
we
gonna
do
that
yeah.
B
I
mean
so
yesterday,
I
was
chatting
with
Bart
and
a
few
other
folks
that
were
working
on
the
Ruby
library
and
they
sort
of
brought
up
the
same
thing
where
like
and
the
examples
that
they're
writing.
What's
a
tracer
Factory,
there's
like
10
12
lines
of
code
but
they're
just
constantly
like
writing
and
rewriting
over.
B
It's
not
exactly
ideal
I
mean,
like
I,
think
one
of
the
things
I'll
start
thinking
about
it
was,
if,
like
the
requirement
for
the
tracer
factory,
is
being
also
like
explicitly
attach
a
like
a
name
to
your
tracer,
like
I,
still
don't
understand
why
it
necessarily
has
to
be
a
factory
as
opposed
to
it
being
a
method.
The
tracer
that,
like
like
tracer
dot
with
name
that
returns
like
a
tracer,
wrapper,
absorbance
mm-hmm,.
A
B
B
F
I'm
still
not
I'm,
not
sure.
If
this,
maybe
it's
a
java
ism,
what
I
can
do
is
trying
to
figure
out
where
how
how
this
Factory
idea
was
born,
because,
if
I,
if
you
remember
completely
correctly,
this
is
more
or
less
the
dynaTrace
topic.
F
B
I
remember
a
time
saying
that
the
intentional
spirit
of
it
right
it
was
like
what
serious
mutation
plugin
for
my
sequel
it'd,
be
cool
to
know
that
your
mutation
or
like
your
stands
are
coming
from
a
specific
instrumentation
library.
So
you
can
kind
of
suss
apart,
like
which
bands
are
coming
from
we're.
F
Completely
clear,
so
the
idea
behind
this
is
completely
clear,
because
we
know
it's
dynaTrace.
We
wanted
to
sometimes
just
switch
off
some
kind
of
instrumentation,
some
tracer,
because
we
know
there
is
a
bug
in
this.
Given
version
of
this,
this,
like
of
this
library,
that
makes
completely
sense,
but
how
did
the
actor
explicit
or
the
instrumentation
station
itself
is
done
if
it's
a
factory
or
not?
So
why
we
why?
This
was
specified
this
way,
I'm,
not
sure
about
that.
B
F
B
I
mean
for
what
it's
worth
I
did
go
down
the
route
of
attaching
like
a
function
to
the
tracer,
like
with
Nick
I,
never
posted
that
PR,
because
in
the
thread
with
doing
he
gave
a
little
bit
of
pushback
for
like
going
with
a
little
specification
if
you're
gonna
do
that,
but
I
can
sort
of
post
that.
So
we
all
can
see
what
that
sort
of
approach
looks
like.
It
looks
much
cleaner
but
again,
I.
Think
it's
like
a
question
like
how
closely
do
we
want
to
follow
the
specification,
because.
F
C
B
C
C
C
C
C
C
C
C
A
It
is
I,
think
v2
I,
believe
that's
what
we
said,
though
I
do
want
to
flag
this
as
a
new
feature.
This
and
separating
out
contacts
propagation
is
actually
what
I
caught
on
the
call
to
talk
about
they're
like
up
till
now.
The
spec
changes
have
all
been
related
to
merging,
open
tracing
and
open
census
together
and
we're
splitting
out
contacts
propagation
and
named
tracers
we're
now
adding
like
new
concepts.
I
think
these
are
the
only
new
concepts
we're
going
to
add,
but
it
means
when
it
comes
to
implementing
these
things.
A
I
fully
expect
there
to
be
like
issues
and
questions
that
come
out
of
like
trying
to
get
this
in
here
in
a
way
that
the
other
spec
changes
aren't,
aren't
going
to
bring
up
as
much
so
I.
Don't
know
that
I
would
want
to
block
a
point
to
release
if
there
is
like
some
real
blockage
in
nodejs
around
how
this
actually
was
going
to
get
implemented.
So
I
don't
know
if
that
makes
sense,
but
we've
added
this
to
the
spec
in
point
two.
A
C
A
Popped
in
for
half
of
that,
after
just
leaving
the
Ruby
sig,
where
they're
having
the
exact
same
conversation
so
I,
think
and
yeah.
This
just
feels
to
me
like
something:
that's
that's
experimental
now
and,
like
certainly,
you
know,
pen
tracing
we
had
to
like.
It
was
never
enough
to
just
write
something
in
this
spec.
A
We
always
when
we
try
to
implement
it
like
a
new
set
of
like
issues
would
show
up
and
we
would
have
to
like
work
through
those
before
like
the
spec
work
would
actually
be
complete,
and
so
I
kind
of
expect
named
tracers
to
be
in
the
same
boat.
Is
that
it's
probably
appropriate
to
release
like
a
prototype
version
of
this
and
be
like
we're
still
in
alpha
phase.
Here's
what
we've
got
so
far
named
tracers
are
experimental.
B
C
A
B
C
B
G
A
C
F
C
Okay,
so
the
current
deadline
for
the
veto
is
28th
of
this
month,
two
weeks
from
now
yeah-
that's
he
should.
He
should
do
that.
Okay
and
then
I'm,
confident
about
the
matrix,
SDK
I
think
it
will
be
there
Daniel,
you
said
Prometheus,
it
will
be
there
yeah,
okay,
the
last
one
is
there's
some
test
felling
in
between
I,
think
I'll,
I'll,
take
it
that
and
I,
don't
think.
That's
so
kind
of
blocker
for
anything.
C
C
A
Sweet
so,
besides
named
tracers,
the
two
remaining
things
that
have
to
get
worked
out
in
the
spec
are
separating
out
context
propagation.
If
we're
actually
going
to
pull
that
off
and
global
initialization
I.
Think
the
global
initialization
stuff
isn't
too
big
a
deal,
but
like
name
traces
context,
propagation
being
pulled
out
is
like
a
pretty
big
change
and
I
have
a
high-level
RFC
kind
of
describing
what
that
would
look
like,
but
there's
two
sort
of
sticking
points
where
I
think
it
actually
gets
tricky.
A
One
is
around
the
new
name,
tracer
stuff,
because
that
means
you
no
longer
have
it
becomes
harder
to
if
you're
gonna
compose
injecting
a
bunch
of
different
kinds
of
contexts.
But
now
you
have
like
what
kind
of
injection
you
would
want
to
do
on
a
particular
endpoint
is
dependent
upon
which
name
tracer
you
have,
and
the
name
tracer
is
kind
of
like
a
handle
you're
holding
on
to
that
makes
that
a
little
bit
trickier
I'm
sure
we
can
sort
it
out.
A
But
it
seems
like
this
concept
of
what
component
you're
in
relates
to
sort
of
your
context,
not
just
the
tracer
or
the
metrics.
So
that's
a
sticking
point.
The
other
sticking
point
is
context.
Switching
right
now
context.
Switching
if,
for
example,
you're
moving
your
work
from
one
thread
to
another
I,
don't
know
that
that
matters
for
jeaious.
A
How
you
would
do
that
can't
just
be
span
specific.
Essentially,
this
might
be
a
non-issue
for
JavaScript,
but
those
are
the
two
places
where
I
don't
have
a
straight
answer
right
now
for
this
context,
propagation
proposal,
so
I
kind
of
wanted
to
reuse
this
in
all
the
SIG's,
because
it
would
be
great
to
get
more
eyes
on
this
change
and
I
suspect
we'll
need
to
actually
be
kind
of
spiking
this
stuff
in
actual
code
in
order
to
sort
out
the
answers.
C
A
Sort
of
what
I
anticipate
right,
if
you're
gonna
say
like
ok
so
for
this
particular
endpoint
I,
want
to
disable
tracing
and
disable
the
stable
context
propagation.
So
I
don't
want
to
inject
anything
into
this
endpoint,
but
you
can
see
the
same
thing
being
true
for
baggage
right.
You
want
to
say
hey
for
this
library,
client
library
over
here,
don't
propagate
baggage,
because
that's
talking
to
some
external
service,
so
you
can
see
how
this
like
name
tracer
in
a
metrics
concept,
might
also
apply
to
baggage.
A
Well,
my
tracer,
hey
you
inject
your
thing,
hey
correlation
context,
inject
that
thing
baggage
context
inject
that
thing
and
the
the
fact
that
what
context
what
tracing,
what
the
tracer
would
want
to
inject
is
now
dependent
on
having
a
handle
to
a
specific
tracer
kind
of
makes
that
more
complicated.
Sorry,
there's
a
rambling
explanation,
but
that's
that's
the
issue
I'm
currently
trying
to
chew
over
chew
on.
A
C
A
It'll
be
a
big
change
if
it
turns
out
like
this
is
just
too
monumental
I
don't
want
to
delay
open
telemetry
and
we
may
just
have
to
give
up
on
separating
out
context
propagation.
That
would
be
sad
if
that
happens,
but
I
think,
if
we're
going
to
like
pull
this
off,
we'll
need
to
have
a
lot
of
like
eyes
and
attention
paid
to
this
over
the
next
month.
C
C
C
G
Because
the
idea
was
first
to
be
able,
for
example,
to
use
the
zip
in
in
the
web,
and
the
only
issue
I
see
is
transport
layer
which
acts
similarly
actually
requests.
So
if
we
could
replace
that
and
to
do
the
same,
asked
post
with
with
other
starts
that
we
shall
be
not
and
wet
and
we
could
be
able
to
use
it
in
the
way
and.
C
G
F
G
Added
the
document
load
so
basically
create
a
web
twice
and
it
start
out
to
instrument
become
document
with
C
automatics
and
then
I
basically
needed
some
way
of
exporting
them.
So
I
create
a
controller
exported,
but
it
turned
out.
There
is
already
one
it
was
measured
with
this
one,
but
still
you
can
only
see
those
fans
in
a
console
but
how
they
really
look
on
the
graphs
from
the
web.
You
know
yet
is.
F
This
not
normally
handled
a
so
I'm
just
wondering
how
this
is
done
somewhere
else.
Do
we
know
these?
Are
spirits
take
I'm,
just
wondering
if
the
exporter
should
sit
in
the
web?
The
approaches
I
know
are
more
like
having
some
JavaScript
Ajax
beacon
that
is
sent
back
to
somewhere.
So
I
was
always
thinking
that
the
web
solution
would
somehow
real
I
need
the
collector
to
send
the
stuff
there
and
it
gets
exported
then,
from
the
collector
I'm
just
curious
about
that.
C
F
F
A
C
G
C
C
G
F
C
G
G
At
least
this
is
my
understanding.
So
in
that
is
you
don't
have
to
modify
this?
It
connects
with
the
right
I
mean,
while
the
Zippy
important
is
using
the
HTTP
from
sorry
Susan
request
from
not
trace
all
for
Sandeep
right.
So
we
need
to
replace
something
with
an
XML
HP
because
of
the
work.
If
you
want
to
use
it,
but
then,
if
you
are
saying
that
for
that
we
have
the
collector
under
the
agent
which
would
be
basic
to
converting
the
spans
into
some
format
packet
and
then
sending
them
I
know.
F
G
C
G
G
G
C
C
C
G
B
G
C
F
Think
there
are
reasons,
because
also
you
might
not
want
to
expose
your
eager
endpoints
to
the
web.
What
you
would
need
to
do.
Basically,
when
you
go
that
route,
so
export
is
like,
like
a
DM,
set
way
that
you
can
you
can
in
theory,
you
can
put
this
exported
income
into
some
PMC.
It
is
collected
into
some
DMC,
sent
the
data
off
to
it
and
be
sure
that
it
won't
yeah.
It
won't
break
anything
and
you
could
still.
F
G
B
C
C
C
C
G
G
B
G
G
G
That's
why
I
mean
my
first
idea
was:
okay,
let's
change
a
transporter
photo
zipping
because
we'll
be
able
to
use
it
directly
in
the
web,
but
now
if
we
use
the
basic
export
inverse
or
a
basic
tricep
for
the
web,
which
also
expects
for
you
to
twist
exporter,
you
might
be
confused
with
exporter
ability
to
use
and
why
it's
called
export.
That
is
in
fact,
for
the
web.
You
should
use
some
agent
which
will
collect
the
information
and
send
to
the
collector.
F
To
that,
I
was
just
thinking
about
one
more
thing
that
might
might
seem
like
make
it
more
clear,
but
we
need
in
in
open
telemetry
anyways
is,
is
also
a
collector
exporter
right
right.
So
yes,.
G
F
C
It's
kind
of
urgency
for
us
because
it's
required
to
the
yeah,
but
what
I
understood
or
what
I
know
is
even
for
the
node,
the
main
I
mean
what
we
advocate
is
to
use
the
collector
instead
of
plain
export
right
directly
and
you
can
still
use
the
Zipkin.
But
the
ideal
way
we
can
say
is
use
the
OSI
I
mean
agent,
then
collector,
and
then
back
in,
because
with
that
you
get
a
lot
of
flexibility
on
the
fly
or
at
runtime.
You
can
configure.
F
C
G
F
C
F
G
C
A
F
Yes,
that's
right.
The
question
is
at
the
same
time,
if
this
is
something
we
can
as
we
need
this
kind
of
exporter
anyways
some
like
this
format,
the
collector
speaks.
If
we
cannot
use
create
a
collector
exporter
and
reuse
that
somehow
on
the
wet
are
not
sure
in
just
use.
Xhr
Dennis
transport,
but
the
4x4,
the
format
like
the
but
it
creates
the
data
structure,
would
be
the
same
right.
F
No
because
the
collector
has
its
own
format,
so
you
cannot
send
SIPC
into
the
collector.
Unless
someone
has
the
idea
to
create
an
endpoint
force,
it
can
I
have
no
idea,
but
from
my
understanding
the
collector
has
this
one
endpoint.
It
varied
expects
data
in
this
specific
format:
yeah
I'm,
not
mistaken.
That's.
G
C
Okay
and
I
hope
meantime
I'll,
ask
Dave
to
join
next
meeting
so
he'll
give
you
more
background
about
why
we
use
this
kind
of
architecture
and
all
what
I
know
is
there
are
some
security
concerns
if
it
directly
exporters
the
same
thing,
the
animation
but
I'm,
not
I,
don't
have
like
complete
context
to
it,
but
something
on
that
line.
I
know,
that's
why
we
use
this
agent,
collector
and
all
kind
of
stuff.