►
From YouTube: 2022-03-09 meeting
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
Go
ahead
and
add
yourself
to
the
attendees
list,
and
if
there
are
any
agenda
items
you
want
to
talk
about
today
feel
free
to
add
them.
Can
everybody
see
my
screen
and
hear
me?
Yes,
yeah.
Okay,
great
first
thing
I
wanted
to
talk
about
today
was
the
otlp
exporters.
A
I
know
that
a
few
weeks
ago
we
made
a
push
to
try
to
release
these
as
stable,
but
as
a
part
of
that
effort,
we
found
a
couple
of
issues
with
them
that
are
not
necessarily
problems,
but
some
refactorings
we
wanted
to
do.
We
wanted
to
hold
back
the
json
exporter
and
because
of
that,
we
have
to
refactor
them
so
that
they
don't
all
depend
on
each
other.
A
So
there
is
a
pr
open
to
create
a
package
to
do
the
transformations.
A
A
They
will
depend
on
the
package
using
a
feature
of
npm
called
bundled
dependencies.
A
I
don't
know
if
anyone
else
has
used
the
bundled
dependencies
feature
here
before,
but
the
transformation
package
will
not
be
released
on
npm
and
will
actually
be
bundled
directly
into
the
tarball
of
the
exporters
once
we're
sure
that
that's
working
we'll
be
able
to
move
those
trace.
Exporters
back
to
stable,
at
least
the
the
protobuf
and
the
grpc
ones.
The
json
one
will
still
have
to
stay
experimental
for
now.
A
The
stability
guarantee,
so
if
we
release
the
the
transformation
package
to
npm,
then
any
sort
of
renames
of
the
fields,
which
was
what
initially
brought
this
tissue
to
our
attention,
will
have
to
be
handled
in
that
package.
If
it's
private,
then
we
have
the
opportunity
to
make
those
renames
more
easily,
because
they're
breaking.
B
A
Which
depends
on
the
json
protocol
being
declared
stable
in
the
proto
repository,
because
that's
what
will
make
the
field
names
stable?
Also.
A
It
is,
unfortunately,
delaying
the
stability
of
the
exporters,
but
they
are
still
usable
in
the
meantime.
So
it's
not
like
it's
not
like
they're
unusable,
but
it
is
delaying
the
1.0
of
those
which
is
unfortunate.
A
Legendicus
opened
a
new
pr
here
to
enable
down
level
iteration
for
es5
targets.
It's
a
pretty
simple
change.
A
He
just
adds
the
the
down
level
iteration
on
the
es5
ts
config,
and
then
he
also
runs
the
compilations,
because
apparently
the
non-default
targets
were
not
being
compiled
in
ci.
So
that's
why
we
were
previously
not
seeing
warnings
about
that
in
our
ci.
So
please
take
a
look
at
that.
A
The
fs
instrumentation
is
not
included
in
the
release
pr,
and
this
is
because
it's
missing
from
the
the
release
automation
configuration.
So
if
you
create
a
new
package,
definitely
make
sure
to
add
it
to
the
config
json.
It
is
not
required
to
add
it
to
the
manifest
anymore.
Now
that
we're
on
release,
please
version
three,
but
it
is
required
to
add
it
to
the
configuration.
A
So
please
do
that,
if
you
add
packages
in
the
future.
A
I
don't
think
I
want
to
go
through
them
each
individually,
but
I
just
wanted
to
list
them,
because
these
are
high
priority
right
now,
because
we're
trying
to
make
a
push
to
get
the
metrics
sdk
released
in
a
at
least
in
a
beta
state
pretty
soon
and
I
believe,
we're
almost
there.
So
this
prometheus
one
is
particularly
important,
but
these
are
all
really
required
in
order
to
release
the
sdk.
So
please
take
a
look
at
them.
A
Okay,
beyond
that,
I
was
instrumenting
an
application
this
week,
and
one
thing
that
was
bothering
me
as
our
http
clients
fan
names
are
not
very
useful.
I'm
sure
that
others
have
probably
seen
this.
You
just
get
a
really
long
list
of
spans
that
all
have
the
same
name
like
http
get
or
http
post
in
the
specification.
A
Unless
there's
a
way
to
get
like
the
low
cardinality
route-
and
I
was
just
wondering
if
anybody
had
any
ideas
on
what
we
could
do
to
improve
the
situation
here,
we
could
try
to
change
the
spec
to
use
the
full
path.
But
the
problem
is:
if
any
parameters
are
included
in
the
path,
then
it
could
become
very
high
cardinality.
A
Any
third-party
http
client
modules
that
have
the
concept
of
routes
could
improve
this
situation,
but
I'm
not
actually
aware
of
very
many
in
javascript
that
do
so.
I
noticed
in
go,
for
example,
when
they
make
a
large
number
of
requests.
A
They
do
it
using
like
the
route
syntax,
that's
similar
to
like
a
server-side
span
where
the
parameter
is
just
pulled
out
as
a
variable-
and
I
don't
know
if
anybody
has
any
ideas
on
how
to
solve
this.
But
I
I
kind
of
just
wanted
to
open
that
question
to
the
floor.
Is
this
a
problem
that
others
have
run
into
or
see
as
an
issue?
Or
is
this
just
something
that
I
need
to
solve
by
creating
custom
spam
names.
C
Plus
one
on
this
being
a
problem
that
people
run
into
regularly,
it's
like,
if
you're,
using
a
framework
like
express
or
happy
that
span
name,
the
span
gets
renamed
to
something
reasonable,
but
if
you're
using
just
http,
then
you
end
up
with
the
not
so
useful
http
get
or
post
or
put
named
spans
or
no,
I
think
finding
structure
in
an
unstructured
string
is
a
little
bit
hard
of
a
problem
in
general.
But
I'm
curious.
If
anybody
else
has
ideas
here,.
A
Yeah
I
mean
I
know
that
this
is
a
problem.
That's
been
solved
on
some
tracing
back
ends
in
the
past,
where
I
have
a
large
number
of
paths
and
with
a
sufficiently
large
number,
you
can
kind
of
you
know
divine
the
the
route
name
from
it,
but
in
open
telemetry
the
specification
sort
of
explicitly
discourages
that,
like
you
said
on
the
server
side,
if
you're
using
a
framework
that
has
route
support,
they
get
better
names,
but
that
doesn't
help
clients
fans
that
just
get
the
http
git
name.
A
I
don't
really
have
a
good
solution
here.
I
guess
one
that
I
would
maybe
propose
is
a
spec
change
that
would
use
the
full
route
as
the
name
instead
of
just
using
the
verb
that
would
potentially
include
you
know
like
an
id
or
something
like
that
as
a
part
of
the
route
name.
A
D
I
know
at
least
maybe
it's
different,
this
side
of,
like
you
know
viewing
the
trace
versus
you
know,
searching
traces,
but
when
we
do
like
a
we
just
search
the
attributes
for,
like
you,
know,
paths
if
we're
trying
to
match
a
certain
path
like
on
a
span
search
and
that
helps
prevent
like
high
cardinality
span
names,
but
to
trade
off.
I
guess
in
usability
there
I
mean,
if
a
framework
can
capture
the
route.
D
A
A
For
the
most
part,
it's
very
common
to
just
you
know,
use
the
string
as
the
path
directly
and
use
like
a
template
string.
So.
A
D
Gotcha,
what
about
like,
could
something
like
a
service
name
or
like
a
host
name
at
least
be
more
valuable
in
there
like
an
http
get
to
you
know,
api.whatever.com,
like
something
at
least
indicates
where
that's
going
to
in
the
span
name.
A
Yeah
I
mean
a
host
is
probably
better
than
what
we
have
again
I
I
know
the
spec
is
trying
to
keep
the
cardinality
low,
but
I
guess
hostname
is
unlikely
to
be
all
that
high,
because
there's
typically
not
variables
within
a
host
name
with
some
exceptions.
Sometimes
you
have
like
a
subdomain
that
has
an
id
or
something
like
that.
A
I
mean
you,
you
work
with
the
client
instrumentation
sig
right.
Do
I
remember
that
from
last
week
or
no
okay?
Not
yet
at
least
this
might
be
something
that
I
try
to
bring
up
there
in
order
to
get
a
spec
change.
I
think
I
think,
without
a
spec
change,
we're
kind
of
stuck
with
what
we
have,
but
I
really
was
just
interested
to
see.
A
Is
this
a
problem
that
others
are
seeing
and
it
sounds
like
yes
and
I
went
to
look
at
like
other
languages
to
see
how
they've
solved
it
and
at
least
in
go
and
java,
which
are
the
two
that
I
looked
at
the
client
libraries
seem
to
have
some
route
support,
so
it's
easy
for
them
to
just
use
the
route,
but
that's
not
the
case
for
us.
A
I
don't
matt.
You
have
worked
with
ruby
in
the
past.
Do
you
have
any
idea
how
ruby
solved
that
or
if
we
resolved
it.
A
Yeah,
I
think
any
of
the
dynamic
languages
will
be
kind
of
stuck
this
way
compiled
languages
like
java
and
go
have
more
more
client
libraries
that
have
the
concept
of
routes,
because
it's
a
useful
like
memory
optimization
for
them,
but
for
dynamic
languages.
I
think
that's
probably
pretty
uncommon.
A
Okay,
well,
I
guess
for
now
we
can't
really
probably
solve
this,
but
I
will
take
it
to
the
instrumentation
seg
and
try
to
make
a
spec
change
on
this
if
possible.
So
I
guess
be
aware
of
that
and
if
you,
if
you
feel
like
plus
wanting
a
specification
issue,
I
will
bring
it
up
next
week,
probably.
E
Yes,
hi,
so
that's
just
a
question.
E
A
No,
I
think
it's
probably
just
not
implemented
yet
okay.
If
there
is
already
a
like
a
process
detection
resource
detector,
then
it
should
just
be
added
there.
Probably
okay
yeah.
I
I
think
it's
just
an
oversight.
A
A
And
andy
this
sounds
like
this
looks
like
follow-up
from
last
week.
Right.
D
Yeah,
nothing
too
crazy
was
maybe
more
to
it
than
I
thought
you
know,
but
basically
this
moves
the
express
package
examples
into
the
actual
express
instrumentation
package.
Just
as
like
a
first
example
of
this,
the
idea
is
that
we
move
all
of
them
and
I
think
the
biggest
other
change
with
it
is
that
it
changes
the
example
from
javascript
to
typescript,
primarily
for
the
reason
of
being
able
to
actually
validate
that
code
that
it
builds,
and
the
example
in
theory
is
still
valid.
D
I'm
not
sure
if
there
was
some
thoughts
as
to
like
the
examples
being
in
javascript
like
vanilla,
javascript
on
purpose,
or
is
that
just
like
happenstance,
like
I
didn't
know
if
that
was
meant
to
be
like
friendly
to
new
users
type
of
deal,
so
I
had
to
go
through
and
type
this
stuff.
I
think
I
did
that
stuff
correctly
could
definitely
use
some
eyes.
It
still
runs
and
works
locally,
and
you
know
it
passes
the
the
kind
of
check
but
yeah.
D
Just
you
know
I
mean
don't
have
to
dive
into
it
now,
necessarily
but
looking
for
feedback
as
to
if
the
approach
still
makes
sense.
If
there's
anything
else,
we
need
to
change
there.
A
Yeah,
so
I
guess
I
can
answer
your
question
about
the
javascript
versus
typescript.
It's
something
we've
talked
about
in
the
past
type,
checking
the
examples
which
would
help
us.
If
you
make
a
change
in
the
package,
then
it
breaks
the
example.
Then
you
know
the
example
needs
to
be
updated
and
it
helps
us
keep
the
packages
up
to
date.
Nobody's
just
had
the
time
to
do
it,
so
nobody
has
taken
the
time
to
do
it.
A
I
suppose
I
should
say
sure
so
that's
something
we
we've
discussed
in
the
past,
and
everybody
has
generally
been
pretty
positive
about
that
they
were
javascript
originally
because
most
of
our
early
examples
were
written
by
a
maintainer
who
is
no
longer
with
the
project
who
believed
that
that
javascript
was
friendlier
to
your
average
javascript
developer
and
that
you
know
we
are
open.
Telemetry
javascript
and
your
average
browser
developer
is
familiar
with
javascript,
but
maybe
not
typescript
and
just
keeping
it
in
a
format
that
is
familiar
to
as
many
people
as
possible.
A
A
So
once
they're
moved
into
the
package
directories
and
we
can,
you
know
easily
link
them
in
and
and
compile
them
directly
against
the
working
version.
The
value
of
typescript
is
a
lot
higher,
so
I
think
that
that
justifies
the
rewrite
there
or
not
even.
D
D
Yeah,
I
did
also
add
ts
node
there
too,
so,
like
the
examples
run
without
an
actual
like
build
step
and
same
thing,
even
in
like
the
test,
it
doesn't
actually
emit
any
build
files
just
to
keep
it
like
as
simple
and
clean
as
possible.
D
A
Well,
I
appreciate
that
and
I
the
idea
is
good.
I
like
the
idea
I
haven't
had
time
to
look
at
the
pr
yet,
but
I
promise
I
will
this
afternoon
cool.
F
A
Okay,
20
minutes
into
an
hour
meeting.
Anyone
have
anything
else
that
they
would
like
to
bring
up.
F
Yep
go
ahead,
so
I
just
dropped
into
the
chat:
a
an
otep
from
the
client
instrumentation
team.
Anyone
interested
in
browser
and
client
metrics
should
probably
go
and
review
that.
F
Yeah
now
now
they've
moved
to
8
am
pst.
I
joined
that
this
morning
and
that
was
on
their
list.
So
it's
definitely
worth
it.
E
Yeah,
just
just
look
at
a
little
more
detail
to
it.
The
client
side
sig
is
working
on
a
proposal
for
capturing
for
data
model
for
client-side
applications,
which
includes
browser,
but
also
mobile
and
other
client-side
devices
or
instrumentations.
E
This
this
dock
is
a
draft
of
the
otep,
so
it's
it's.
The
plan
is
to
actually
open
an
otap
with
this
information,
but
if
you
want
to
have
a
preview
and
comment
in
this
dock,
please
feel
feel
free,
so
feel
free
to
do
so.
Okay-
and
it
looks
like
this-
covers.
A
A
So
next
week
I
will
be
in
europe.
I
am
still
planning
on
attending
this
meeting,
but
it
will
be.
A
My
availability
will
be
more
european
time
so
more
mourning
and
for
those
of
you
who
are
in
the
pacific
time
zone,
which
I
think
is
most
of
you,
I
will
probably
be
a
little
bit
harder
to
get
a
hold
of
next
week.
Unfortunately,
so
sorry
for
that
andy
wants
to
know.
Where
is
the
best
place
to
catch
up
on
the
state
of
client
work
browser
telemetry
stuff?
A
That
is
probably
I
mean
I
can
tell
you
that
the
state
of
it
is
that
it's
mostly
not
there.
Yet.
There
is
like
a
couple
of
browser
instrumentation
packages,
but
the
most
interesting
work
is
probably
happening
in
the
client,
instrumentation
sig.
So
martin
probably
knows
more
about
that
than
I
do.
E
Yeah
and
it
declined
the
client
side
sega's
meeting
on
wednesdays
8
a.m.
Pacific
soon.