►
From YouTube: 2022-08-04 meeting
Description
Instrumentation: Messaging
A
Of
course,
my
headphones
turn
off
when
I
join
the
zoom.
B
Oh
yeah,
I
feel
like
zoom's
a
good,
forcing
function.
It
tests,
everything.
B
Yeah,
we
were
in
the
hundreds
this
past
week,
so
it's
getting
back
down
into
the
reasonable
temperatures
which
is
like
90,
but
it's
so
reasonable.
B
Yeah,
definitely
it
kind
of
stinks
with
the
pool
temperature
starts
to
get
like
you
know,
high
80s
and
you're
like
this
isn't
even
refreshing,
but.
B
At
when
I
was
going
to
grad
school,
like
one
of
the
places,
was
arizona
or
oregon
and
it
was
pretty
well
framed.
It's
like
well,
you
get,
you
know,
the
summers
are
gonna
be
awful
or
the
winter's
gonna
be
awful,
depending
on
which
one
you
you
don't
want
to
do
so.
C
B
Awesome
yeah,
I
think
we
can
jump
in
then
welcome
everyone.
If
you
haven't
already.
Please
add
yourself
to
the
attendees
list
and
if
you
have
any
agenda
items
you'd
like
to
talk
about,
please
add
them
and
we'll
jump
in
and
get
started.
First
up
we're
gonna
go
over
the
metrics
sdk
alpha
release,
progress,
which
is
quite
good.
I
finally
hit
that
80.
So
I
think
that
we're
we're
definitely
chugging
along
people
have
started
asking
for
dates
on
this
one
and
I've.
I
think.
B
Last
week
I
told
him
a
month
and
a
half
or
something
like
that-
maybe
two
months
away.
I
think
that
at
this
current
rate,
it's
realizable
for
the
alpha
release.
Obviously
anyone
who
really
wants
to
use
some
productions
gonna
have
to
wait
a
little
longer,
but
I
think
for
testing
purposes
specifically
and
and
seeing
how
this
is
all
gonna
work.
This
should
be
a
good
target
date.
B
Quick
here
just
want
to
make
sure
that
we're
still
all
current.
I
reviewed
this
this
morning,
so
the
active
work
in
progress
right
now
aaron's
got
a
pr
for
a
filter,
aggregator
and
a
pipeline
registry
to
manage
creating
aggregators.
I
also
have
a
pr
to
add
back
standard
metrics
priority
wise.
I
would
say
this
is
like,
if
you
have
time
to
review
something,
this
would
be
the
one
to
review.
It's.
I
think
the
headline
blocking
for
a
lot
of
the
instrument
work
aaron.
If
there's
something
you
wanted
to
add
to
this.
A
I'm
sorry
that
this
is
where
all
of
the
logic
ends
up
lying,
making
it
kind
of
an
ugly
ball
of
code.
But
that's
when
we
implement
something,
that's
complicated.
It's
it's
a
little
complicated.
So.
B
Yeah,
that's
a
that's
a
good
point,
maybe
to
color
this
for
people
who
are
looking
to
review
it.
I
I
guess
I
haven't
approved
yet
I'm
99
there.
I
added
some
small
nits,
but
the
I
thought
a
lot
about
this
because,
as
aaron
said
like
it
is
kind
of
a
ball
of
code,
and
so
I
was
wondering
if
it
can
be
refactored,
I
would
suggest
you
also
think
about
how
you
would
refactor
this.
B
I
spent
a
lot
of
time
and
I
didn't
really
come
up
with
a
good
solution,
and
so
I
think
it
this
is.
This
is
at
least
at
this
point
in
time,
with
our
current
interface
structure,
a
good
way
to
approach
this.
So
I
I
think
it's
it's
yeah
it's
unfortunate
and
I
think
that
we
could
probably
do
better
in
the
future.
B
But
currently
I
don't
think
that
that's
the
case,
and
I
think
that,
as
aaron
kind
of
pointed
out,
there's
a
imposed
complexity
here,
where
we
have
to
manage
the
creation
of
instruments
in
the
context
in
light
of
views,
readers
and
some
default
configurations.
So
I
think
it's
it's
worth
diving
in
and
understanding
it
just
also
take
with
it
just
understand
like
it's
recognized
as
complex
code
and
yeah
I
mean.
Obviously,
suggestions
are
welcome,
but
yeah
keep
that
in
mind
yeah
and
then
the
filter.
B
A
So
I
I
wanted
to
just
talk
briefly
that
this
is
one
of
two
ways
of
solving
this
problem.
This
is
the
more
straightforward
way.
The
less
straightforward
way
would
be
imposing
this
kind
of
logic
to
be
done
at
a
different
time
by
the
the
aggregators,
so
because
that's
all
internal
in
the
internal
package
that
can
be
that
we
can
switch
to
that
after
the
fact
it
would
be
a.
A
It
would
be
a
pretty
hard
pretty
large
task
to
do
so,
but
it
could
be
done.
B
Yeah,
I
agree
yeah,
here's
the
issue
tracking
network
as
well.
If
you
are
interested
in
that
discussion
or
have
ideas
about
it
or
another
place,
this
could
be
done.
This
is
where
those
kinds
of
comments
would
be
well
welcomed.
B
It
does
look
like
it
actually
has
the
right
approvals
at
this
point,
I'm
to
hold
off
on
merging
this
or
I
guess
I've
asked
we
hold
off
on
merging
this
for
just
a
few
hours.
If
you
do
want
to
take
a
look,
please
jump
in
there
but
yeah.
Oh,
I
guess
and
there's
a
small
bit
but
yeah.
Otherwise.
I
think
this
is
getting
ready
to
merge.
B
So
if
you
want
to
take
a
look,
prioritize,
it
cool
and
then
the
last
one
is
the
standard.metrics
one
thing
to
note
here:
is
this
wow?
That's
a
lot
of
commits.
B
It
adds
back
the
standard,
metrics
exporter
which
we
have
removed
in
the
process
of
development,
one
of
the
things
that
it
does
do
is
it
it
refactors
a
little
bit
of
the
option
in
the
previous
incantations
it
assumed
the
standard
metric
was
going
to
be
configured
with
a
writer.
It's
going
to
use
a
json
printer
and
we've
talked
in
these
meetings
a
lot
in
the
past
about
the
limitations
that
that
poses
in
many
respects.
Just
on
like
how
you
want
to
actually
stream
it.
B
It
also
it
kind
of
leads
people
to
believe
that
this
is
some
sort
of
stable
format,
because
I
mean
it
hasn't
changed,
even
though
it
doesn't
actually
have
any
guarantees
that
it
won't
change.
B
So
what
this
is
doing
is
it's
replacing
all
of
those
options
with
essentially
like
a
user-defined
encoder
that
encoder
fits
nicely
with
the
json
encoder
turns
out,
and
so
we
still
are
supporting
json
encoding
with
the
default.
What
we
used
to
call
pretty
printing
using
a
tab
indentation,
but
it
allows
for
the
extension
of
this
to
use
really
anything
you
want
and
to
send
this
to
anywhere.
B
You
want
and-
and
I
think
it's
a
useful
change-
I
think
that
honestly,
we
should
probably
try
to
backboard
something
this
to
the
tracing
one,
providing
some
sort
of
similar
functionality,
but
yeah.
Just
a
heads
up,
it's
worth
checking
out.
Also.
I
really
tried
to
make
it
clear
in
the
docs
saying
this
is
not
for
production
use.
It's
for
debugging!
There's
no
guarantees
around
this.
B
I
guarantee
we'll
still
have
an
issue
come
in
saying
like
why
doesn't
this
support
intercompatibility,
but
nonetheless
we'll
try
our
best
yeah,
so
we're
taking
a
look
like.
I
said,
though.
It's
not,
I
think
the
top
priority
of
pr's
that
he
had
only
one
to
choose.
I'd
still
go
to
that
30
44.
B
other
than
that,
though
our
to-do
issues
looked
pretty
upstate
for
those
looking
to
pick
up
some
small
issues.
I
was
realizing
these
documentation.
Issues
are
sitting
here
and
I
think
they're
ready
to
go.
I
don't
see
why
they
wouldn't
be.
Maybe
the
sdk
metrics
package
you
might
want
to
hold
off
just
because
we're
still
working
on
some
of
the
instrument
internals.
But
I
I
don't
see
really
why
that
would
block
that.
B
Yeah
I
agree
and
then
that
just
bring
up
a
good
question
and
then
all
the
other
ones
I
think
are
up
for
for
somebody
to
pick
up.
I
still
think
the
example
code
needs.
We
need
obviously
a
way
to
run
the
sdk,
so
this
is
still
blocked.
So
I
think
this
project
board
is
pretty
accurate.
Anybody
have
any
comments
on
this
one.
A
B
C
B
Good
to
know
those
should
be
updated.
Yeah
that
looks
right.
B
I
haven't
I've
got
some
other
things
I
think
I'm
working
on,
but
I
would
probably
pick
up
I'll
pick
up
one
of
these
as
well,
hopefully
this
week,
but
yeah
we'll
see
one
of
the
things
I
just
kind
of
realized.
We
were
just
talking
about.
The
stability
of
the
interfaces
is
there's
an
issue
I
created
for
the
next
milestone
for
the
beta
release.
C
B
I
think
this
is
it
the
optimization
for
the
cumulative
histogram
yeah.
So
currently,
the
implementation
is
a
little
rough
around
the
edges,
because
I
guess
maybe
we'll
just
talk
through
this
just
a
second,
because
I
think
it
is
kind
of
important,
maybe
there's
to
call
out,
even
if
we
don't
change
it.
I
think
people
might
want
to
think
about
it.
B
When
we're
running
the
delta
histogram,
because
slices
of
reference
objects,
we
need
to
make
copies
of
them,
otherwise,
the
aggregator
itself,
when
it
returns,
this
data
could
have
the
underlying
data
changed
on
its
own,
on
its
behalf,
so
the
bounds,
but
also
in
the
cumulative
accounts
as
well.
We
need
to
make
copies
of
these,
so
this
requires.
B
You
know,
slice
allocations,
for
you
know,
however,
many
attribute
sets
you're
aggregating
over,
and
so
I
listed
it
as
something
like
this
is
maybe
not
like
the
most
optimal,
but
I
think
for
the
alpha
release.
It
could
make
sense
just
to
to
get
this
through,
because
again,
we
kind
of
talked
about
this
optimization's
not
really
ideal.
B
For
this
stage,
I
did
put
some
possible
solutions
around
this.
One
of
them
was
kind
of
writing
a
wrapper
around
the
histogram
data
point.
Making
it
read
only
this
can
be
added
in
the
beta
phase.
Unifying
the
counts
and
bounds
into
some
sort
of
like
bucket
type
would
unify
this
histogram
data
points.
B
Essentially
I
guess
it
might
change
the
data
point
a
little
bit,
which
I
guess
we
could
still
change
in
the
beta
phase,
so
it
really
wouldn't
be
like
the
end
of
the
world.
The
exporters
would
have
to
get
updated.
B
This
sync
pool,
though,
idea
was
kind
of
an
interesting
one
as
well,
so
it
would
allocate,
and
then
you
need
to
return
these
allocations,
but
the
thing
that
you're
passing
is
gonna
go
beyond
the
exporter
boundary,
and
this
is
the
one
where
I
was
kind
of
wondering
how
we
would
do
something
like
this,
and
if
we
wanted
to
think
about
it
it
might
not
it
might.
It
would
require
some
sort
of
bigger
changes,
but
essentially
like
as
you
pass
off
the
data.
B
Maybe
the
exporter
would
have
to
hand
back
the
data
saying
I'm
done
with
this
at
some
point.
There's
also
this
possibility
to
use
a
set
finalizer.
So
when
the
gc
actually
realizes
that
it's
going
to
go
pick
it
up
it'll
make
some
sort
of
function
call.
You
can
use
these
sort
of
things
to
essentially
work
around
putting
memory
back
into
a
sync
pool.
So
there's
some
ideas
here.
I
just
kind
of
want
to
bring
it
up,
because
this
one
is
the
one
where
I
was
thinking.
B
B
Okay,
all
right,
that's,
I
think,
probably
it
for
the
metrics
sdk
next
up
on
the
agenda.
I
added
this
new
auto
instrumentation
sig,
because
I
imagine
everyone
on
this
call
is
gonna.
Be
someone
interested
in
that
josh
has
created
this
new
opensource
instrumentation
repo,
essentially
with
a
kickoff
issue.
This
is
encapsulating
two
of
the
proposals
for
auto
instrumentation
that
we
talked
about
last
meeting
as
well
as
previous
to
that
both
of
them
can
be
read
and
found
linked
in
this
issue.
B
I
propose
that
we
started
this
with
a
kickoff
meeting
and
in
here
there's
a
doodle
poll.
If
you
would
like
to
attend
that
meeting,
please
respond
to
the
doodle
poll
with
your
availability
and
if
you
aren't
available
please
I
mean
also
respond.
Keep
in
mind.
This
is
going
to
be
recorded.
So
if
you
don't
need
necessarily
to
participate,
then
maybe
just
also
recording
is
something
that
could
work.
B
The
main
thing
that
I
think
we
want
to
talk
about
is
like
chart
level
issues
for
this
project,
but
also
we
need
some
maintainer
and
approver
teams.
So
all
of
the
go
approvers
and
I
think
the
triagers
are
welcome
to
come.
I'm
not
exactly
sure
how
josh
set
up
these
teams.
I
don't
think
I
have
access
to
this
anymore,
but
currently
I
think
we
have
aaron
myself
anthony
and
then
I
thought
everyone
was
on
here.
Yeah.
C
I
just
created
these
teams
and
I
think
I
I
don't
understand
github
permissions,
so
I
have
some
powers
as
a
technical
committee.
Member
that
let
me
do
that,
I'm
happy
to
help
adjust
things.
I
was
just
trying
to
set
the
initial
conditions
and
help
a
charter
get
established
here.
I'm
not
really
here
to
be
like
opinionated
as
much
as
sometimes
I
am
so
I'm
I'm
just
trying
to
listen
and
and
help
us
form
a
new
group
here.
B
Yeah
yeah-
sorry,
I
didn't
mean
to
imply
otherwise.
I
guess
I
was
just
going
into
the
weeds
too
much.
I
guess
what
I'm
trying
to
get
at
is.
C
I
didn't
meet
him.
I
didn't
feel
you
said
anything
wrong.
I
just
I
don't.
I
actually
don't
know
what
we're
doing
here.
Other
than
that
there
were
two
donation
proposals.
They
looked
good
technically
technically
acceptable
and-
and
I
think
we
need
a
community
around
it.
So
so
it's
time
to
start
talking
about
it.
The
one
thing
I'll
say
in
that
the
the
the
prachemic
jalooski
contributor
can't
make
any
of
the
doodle
polls,
because
he's
requested
the
following
week.
C
Basically-
and
I
wonder
if,
if
the
priorities
here
are
perhaps
not
that
urgent,
so
that
we
could
could
defer
discussing
that,
but
I
then
I
also
know
that
there's
a
second
contingent
here,
probably
represented
by
jamie
danielson
and
team
at
honeycomb,
who
really
wanna
much
more
urgently
talk
about
launchers,
and-
and
so
I
don't
wanna
hold
that
back,
and
I
know
that
that's
a
debatable
topic.
C
I
I've
had
some
off
off
some
private
discussions
about
that
with
them,
and
so
I'd
like
to
discuss
that
here,
whether
my
hypothesis,
that
auto
instrumentation
the
scope
of
auto
instrumentation,
can
expand
to
whatever
it
is.
This
thing
we've
been
calling
a
launcher
which
is
like
an
easy
way
to
set
up
a
global,
sdk
and
configure
it,
and
I
I
may
be
wrong,
and
so
that's
that's
all.
I
had
to
say.
B
Yeah,
okay,
so
there's
a
few
things
in
there.
I
would
say
if
you're
listed
on
here,
please
try
to
respond
to
google
poll
because
you
may
be
considered
for
one
of
the
roles.
I
think
that
was
kind
of
where
I
was
getting
at
and
you
will
be
asked
essentially
if
you
want
to
participate,
I
think
also
yeah
there's
a
lot
of
different
interests
here.
This
is
a
little
odd
because
I
thought
that
week.
Starting
of
I
think
this
date
is
the
15th
of
august.
B
The
15th
of
august,
I
think,
was
the.
I
was
a
little
confused
by
that
it
there's
definitely
dates
after
the
15th
of
august
that
are
available.
So
I
I
don't
know
he's.
B
All
right
cool
yeah-
I
was
a
little
confused
by
that,
okay,
so
that
that
should
work
and
then
yeah.
I
think
that
I
do
want
to
talk
a
little
bit
about
that
in
this
meeting
here
as
to
like
how
we
want
to
structure
that,
because
I
think
josh
what
you're
actually
hitting
at
is,
I
think,
a
big
longer
term
vision
for
this
project,
not
necessarily
like
the
initial
project
of
accepting
these
two
proposals
or
ratifying
them
in
some
way.
B
I
think
that
there's
a
bigger
vision
of
how
do
you
have
some
sort
of
effective,
auto
instrumentation
was
traditionally
called
the
agent
that
sits
there
for
go,
and
I
think
that
that's
a
valid
thing
to
be
discussing.
I
I
was
anticipating
having
that
discussion
in
this
meeting
or
I'm
sorry
in
the
kickoff
meeting.
You
said
this
meeting.
Did
you
mean
the
current
meeting
we're
in
or
the
kickoff
meeting
as
well.
E
When
he
and
I
chatted
about
it
earlier
initially
he
had
mentioned-
maybe
we
talk
about
it
in
the
kickoff
meeting
and
say
yes
or
no
one
of
my
concerns
about
that
was
that
if
the
kickoff
meeting
for
that
doesn't
happen
for
a
couple
of
weeks,
I'd
rather
talk
more
about
the
launcher
here
and
and
talk
about
where
it
may
live
and
kind
of
make
decisions
on
it
just
to
keep
that
moving,
as
opposed
to
waiting
for
the
meeting.
B
I
I
agree
completely
with
that.
I
don't
know
if
anybody
disagrees,
but
I
I
definitely
don't
see
why
we
couldn't
even
release
it
in
the
contrib
repo,
just
not
as
a
stable
release
and
then
migrate
it
that
that
all
seems
like
totally
feasible.
So
you
know
if,
if
the
kickoff
of
the
automation
group
ends
up
lasting
for
a
year,
I
think
we
could
still
provide
a
solution
for
the
launcher
sooner
than
that.
B
B
Okay,
awesome
cool
all
right,
so
that's
the
honorable
mutation
I
wanted
to
bring
up
next
up.
I
wanted
to
touch
base
on
deprecation
of
packages
which
is
an
oldie
but
a
goodie,
so
yeah.
Actually
this
isn't.
I
don't
think
this
is
even
our
oldest
issue.
B
There
have,
for
those
not
aware
have
been
issues
where
we
have
created
and
released
packages
that
no
longer
exist,
we've
moved
them
or
they're,
entirely
deprecated
and
abandoned
or
deleted
in
the
repository,
and
this
can
lead
to
a
lot
of
confusion
in
in
many
different
ways.
So
one
of
the
proposals
is
first
off.
Aaron
did
a
great
job
identifying
all
of
the
existing
packages
that
meet
this
criteria.
B
I
guess
I
say
packages,
but
I
really
need
modules
here
and
from
that
we're
looking
for
some
sort
of
action
to
take
to
signal
to
users
that
they
shouldn't
use
these
modules
again
they're
dedicated
and
then
ideally
remove
them
from
from
acceptable
choices.
B
I
guess
is
the
way
to
say
that-
and
this
is
a
little
bit
old
and
I
think
a
few
people
have
looked
at
this
at
this
point,
and
aaron
has
done
a
good
job
at
outlining
some
of
the
steps
to
try
to
finally
approach
this,
and
I
think
this
is
a
reasonable
approach
I
do
wanted
to
touch
base.
I
haven't
read
this
comment,
which
was
28
minutes
ago,
so
aaron
I
apologize.
I
definitely
had
some
feedback
on
here,
but
I
think
that,
like
overall,
this
is
the
right
direction.
A
The
only
reason
why
I
put
the
v020
is
because
we
have
a
test
case
in
the
issue
that
I
linked
here.
I
think
it's
like
30
40,
something.
C
A
And
I
was
going
to
deprecate
all
of
them
at
once,
just
because
that
keeps
it
a
single
commit
for
all
of
that
similar
to
other
things.
It's
not
not,
I
guess
technically
necessary,
but
keeps
things
a
little
bit
cleaner.
C
B
So
I'm
not
opposed
to
that.
I
was
thinking
doing
a
single
one,
just
to
make
sure
we
had
the
workflow
down.
I
do
want.
B
I
I
incorporated
this
repo
that
I
was
doing
some
testing
on
like
deprecation
and
even
retractions
are
not
permanent.
You
can
do
another
release
and
you
can
fix
them
or
remove
them
so,
like
I
think
it's
not
as
as
like
impactful
as
it
used
to
be
when
the
package
mirrors
were
like.
There
was
no
way
to
approach
this.
So
if
you
think,
if
that's
that's
the
best
case,
I'm
not
I'm
not
gonna
hold
it
up,
I'm
doing
six
at
a
time.
That
sounds
sounds
reasonable
to
me.
D
Yeah,
I
think
this
is
probably
the
path
to
take.
I
I'm
not
sure
deprecation
is
going
to
fix
it,
but
if
it
at
least
warns
users,
it's
a
step
in
the
right
direction.
D
I
think,
though,
looking
at
the
the
issue
that
was
recently
raised
about
the
otlp
exporter,
we
may
have
a
slightly
different
issue
there,
because
we
do
have
code
in
that
package
or
in
packages
underneath
that
that
don't
have
a
module
there,
so
they're
effectively
part
of
the
hotel
module,
and
I
don't
know
if
that's
what
we
intend.
A
B
That
is
yeah
I'd
be
very
ignorant
to
talk
about
it.
At
this
point,
I
I
definitely
wish
steve
was
on
the
call
to
talk
a
little
bit
more
about
gazelle
because
he
was
our
resident
expert
but
yeah
that
does
sound
kind
of
confusing,
especially
if
like
we
removed
it
and
there's
a
dependency
issue
there
right,
because
if
we
do
deprecate
these
things
and
somehow
this
tooling
can
pick
up
the
fact
that
it
shouldn't
be
using
those
other
ones.
B
In
theory,
shouldn't
also
be
using
this
v20
of
this
internal
package
of
hotel
that
has
created,
but
I
I
agree.
This
may
not
resolve
this
issue.
I
feel
also
as
though
this
has
been
raised
before
and
steve
pointed
out
ways
to
fix
this,
but
I
don't
so.
A
A
Otlp
internal,
that
that
is
there,
but
that
has
almost
zero
dependencies
on
on
anything.
It
has
very
small
number
of
dependencies.
All
that
means
is
the
exporters
the
otlp
exporters
are
going
to
depend
on
the
base
otlp
module
because
that's
what
they
get
rolled
up
into.
A
F
A
D
I
yeah,
I,
I
think
I
kind
of
agree,
but
I
also
think
that
if
we
do
publish
a
go
mod
at
exporter's
otlp
it
might
you
know
at
1.9
or
1.10
whatever
the
the
next
version
is.
It
might
help
with
the
resolver
saying.
Oh
I'm
going
to
pick
up
exporter's
otlp
0.20,
because
that's
the
most
recent
version
of
that
module.
A
Yeah
that
that
could
also
be
the
case.
B
Yeah,
I
I
think
going
forward
with
this
publication.
Our
publishing
deprecation
notices
is
a
good
place
to
start
at
the
very
least,
it's
doing
cleanup
that
we've
needed
to
do
in
the
long
run,
it'll
help
with
documentation
and
it'll
help
with
just
informing
users
when
they
try
to
use
the
wrong
one
before
they
open
an
issue,
and
then,
if
it
doesn't
resolve
the
issue,
I
think
that
I
could
probably
go
from
there
and
dig
in
a
little
deeper
if
that
makes
sense.
B
Awesome
next
the
agenda
yeah.
I
wanted
to
call
out
this
issue
here.
I
don't
want
to
spend
too
much
time
on
it,
because
you
want
to
jump
into
jamie's
point.
There
was
this
interesting.
Pr,
maybe
interesting
is
frustrating
is
maybe
the
better
word.
It's
pointing
out
that
our
header
carrier
uses
the
go
standard
way
to
interact
with
headers
using
the
git
and
set
method,
but
it
uses
a
canonical
header
format
for
this,
meaning
that
the
w3c
trace
context
or
baggage
header.
It
becomes
capitalized
in
the.
B
I
guess
it
uses
like
a
title
case
and
that
is
not
recommended
by
the
w3c
specifically
saying
that
you
should
only
be
sending
out.
You
know
lowercase
header
values.
B
The
problem
is
is
that
this
change
tried
to
make
a
a
quick
change
to
only
use
to
skip
that
normalization
and
then
talk
directly
to
the
map,
which
is
what
the
headers
package
recommends.
However,
in
the
process,
I
was
kind
of
realizing
that
by
doing
that,
we
also
won't
support
non
lower
case
headers
for
the
w3c
trace
contacts,
which
is
a
requirement
like
sending
out
lower
cases,
a
recommendation
but
being
compatible
with
any.
B
You
know
header
value
that
is
not
lowercase
is
a
requirement,
so
I
don't
think
this
can
go
forward
as
it
is,
and
so
we
said
that
way
and
there's
been
some
investigation
into
how
to
resolve
that.
But
I
there's
an
issue
now
where
I
don't
know
exactly
how
to
resolve
that.
B
B
Okay
cool-
maybe
that's
a
little
bit
of
a
tangent
jamie
I'll
hand
it
over
to
you
for
this
design,
doc
update.
E
Yeah,
so
just
wanted
to
mention.
Thank
you
for
everyone
who
provided
feedback.
I
know
there's
quite
a
few
from
anthony
and
tyler
on
there.
I
think
that
I
went
through
and
addressed
all
of
the
things
that
had
been
brought
up
and
I
wanted
to
see
if
there
was
if
there
was
more
clarification
needed
on
some
of
the
points,
if
any
of
it
made
sense
to
talk
through.
E
I
know
anthony
wasn't
here
last
week,
so
I
wanted
to
see
if
the
questions
that
he
had
were
addressed
here
or
if
there's
more,
that
we
want
to
talk
about
or
kind
of,
if
there's
anything
that's
been
left
out
on
here.
B
Personally,
I
haven't
had
the
time
to
look
through
this
again,
although
I
am
looking
and
I'm
seeing
you
know,
I
appreciate
all
the
thought
that
you've
been
into
addressing
each
other's
issues.
I
will
try
to
prioritize
getting
back
to
this
stuff.
All
I
can
say
anthony,
I
think,
you've
gone
through
it
again,
though
right.
D
I
haven't
gone
through
it
again
since,
since
I
left
the
feedback,
although
I
have
looked
at
jamie's
feedback,
but
I
don't
think
there
have
been
significant
changes
since
then
to
the
document
itself.
I
I
will
just
note
I'm
kind
of
wary
of
building
something.
That's
only
going
to
interoperate
with
a
single
exporter
or
exporter
type.
D
I
know
otlp
is
kind
of
supposed
to
be
the
lingua
franca,
but
I
I
think
it
puts
it
puts
handcuffs
on
vendors
who
might
want
to
build
their
own
launcher.
You
know
using
this
framework
that
don't
use
otlp
and
that's
a
significant
decision
that
we
have
to
make.
Do
we
really
want
to
go
down
that
path,
or
do
we
want
to
make
it
flexible.
E
Right-
and
I
guess
so,
one
of
the
things
on
there
that
you
would
mention
the
possibility
of
like
right
now,
there's
the
auto
prop
registry
that
helps
for
registering
propagators
to
be
used,
and
I
know
we
had
mentioned
in
there
for
understanding
the
purpose
of
that
correctly.
E
It
sounds
like
the
right
move
to
have
in
the
launcher,
and
I
noted
here
that
you
know
if
there's
an
auto
exporter
package
or
something
like
that
later,
like
does
it
make
sense
to
start
having
the
otlp
exporters
and
look
at
adding
other
exporters
with
an
auto
exporter
package.
As
like
a
follow-up
item
and
having
sort
of
iterate
on
it
from
there.
B
Yeah,
I
think,
that's
a
I
would
agree
with
that
approach.
I
also,
I
think
it's
maybe
not
as
hard
to
man
there's
a
lot
of
comments
to
approach
here.
So
one
of
the
things
also,
I
want
to
remember-
and
I'm
not
100
in
this
exact
moment,
but
I'm
pretty
sure
all
of
the
exporters
themselves
support
their
environment
variables.
It's
not
the
sdk
passing
this
right
yeah.
B
So
I
think
this
also
might
work
well,
if
you
know
instead
of
having
some
sort
of
option
here,
for
you
know
with
the
tracex
square's
endpoint,
you
essentially
are
saying,
like
maybe
an
option
for
with
trace
exporter,
and
you
can
pass
in
something
that
implements
the
traced
exporter
here
in
code.
I
think
there's
also,
if
I'm
not
mistaken
in
the
other,
I'm
sorry
in
the
open
source,
respect
a
header
that
is
until
export
or
something
like
that.
B
It
essentially
says
you
can
choose
your
exporter,
and
that
would
be
something
that
this
auto
export
package
would
support.
Essentially,
like
you
know,
whenever
that's
set,
then
it
would
handle
it,
and
I
think
that's
probably
the
way
I
would
structure
it
and
and
to
leave
out
any
of
these
to
configuration
options
to
the
exporter
itself.
B
So
I
think,
if
that's
that's,
you
know,
if
you
chose
you
know
you
can,
we
could
say
the
default,
for
we
had
an
option
here
with
with
trace
exporter
and
then
with
hotel
exporter
selection
would
just
default
to
otlp.
I
think,
if
that's
fair,
as
any
anthony
pointed
out,
would
be
lingua
franca,
but
it
also
would
support
you
know
if
you
passed
in
an
environment
variable
of
jaeger
or
something
like
that,
it
would
support
that
as
well.
Let
me
double
check.
I'm
like
99
sure
that
there's
a.
B
B
B
I
think
that
trying
to
say
like
so
we
would
support
this
environment
variable
and
then
you
know
you
have
an
equivalent
option
here
and
then,
since
each
exporter
itself
already
handles
these
environment
variables,
and
then
it's
also
extensible
right,
like
if
you
built
your
own
exporter
for
a
proprietary
like
source,
you
could
also,
then
you
know
extend
that
with
your
own
environment
variables
and
we
wouldn't
have
to
have
them
listed
here.
If
that
makes
sense,
jamie.
E
B
I
think
you
can
get
away
with
just
removing
the
endpoint
and
this
insecure
option
entirely,
and
you
would
have
a
with
traces
exporter
option
and
that
exporter
option
just
it
accepts
an
already
configured
exporter,
an
already
instantiated
exporter,
therefore
like
the
endpoint
can
be
set
in
the
exporter
and
the
insecure
value
or
or
any
other
like
configuration
of
the
exporter,
it
is
handled
prior
to
hand
handling
handing
it
off
in
code,
but
it
also
so
that
allows
the
extensibility
right,
like
you
know
like
we
are
not
going
to
be
able
to
think
of
every
single
configuration
option
possible
for
an
exporter,
especially
if
it's
a
proprietary
source.
B
Maybe
they
want
to
handle
things
differently
or
separate
duties
differently,
but
it
does
allow
them
to
to
package
whatever
exporter
functionality
they
want,
and
then
you
could
send
it
off
this
way,
especially
then,
if
you
can
also
register
that
exporter
with
this
new
auto
exporter
package
that
we
should
probably
add,
I
think
that
would
that
would
allow
this
this,
the
greatest
extensibility.
F
B
B
C
D
Right
and
then
those
those
options
that
are
removed
can
be
kind
of
replaced
with
a
couple
more
options
to
configure
the
batch
band
processor,
which
I
think
was
the
the
other
thing
that
I
called
out,
and
there
are
very
few
options
there.
I
don't
think
we
need
to
provide
an
option
to
choose
between
batch
or
simple
spam.
Processor
like
we
should
always
just
use
the
batch
band.
Processor,
yeah.
D
Providing
options
for
batch
size
timeout
may
be
an
option
to
set
blocking.
You
know
if
you
turn
on
blocking
mode,
it's
effectively
the
simple
span
processor,
so
that
I
think
those
three
options
give
all
the
flexibility
you
need
there.
F
E
E
Definitely
we
would
want
to
avoid
having
you
know,
duplicating
all
the
effort
of
something
that
exists,
and
I
think
you
know
looking
at
what
we
can
reuse.
That's
been
built
like
reviewing
the
code
right
now
we're
looking
at,
for
example,
let's
reuse
the
resource
detector
that
exists.
If
we're
going
to
be
doing
things
like
that,
I
think
really.
E
The
goal
is
very
much
of
trying
to
simplify
the
configuration
and
that's
it,
whereas
when
it
comes
to
say
adding
manual,
instrumentation
or
things
like
that,
that's
all
fully
in
the
sdk
and
not
touching
anything
like
that
and
then,
as
far
as
like
the
vendor-specific
packages
that
would
be
compatible
with
it.
The
idea
is
something
like,
instead
of
so
again
from
a
honeycomb
perspective,
instead
of
a
customer
having
to
set
their
header,
you
know
for
their
honeycomb
api
key.
E
If
they
use
the
honeycomb
package,
they
have
a
slightly
different
way
of
setting
it,
so
they
don't
have
to
worry
about
typing
in
the
endpoint
we've
added
it
for
them
or
they
don't
have
to
worry
about
adding
x,
honeycomb
team.
That's
part
of
that,
so
I
think
the
the
other
vendor
specific
packages
would
allow
for
just
a
little
bit
more
simplification
for
those
vendor-specific
things,
and
I
think
we'd
want
to
have
the
ability
to
add
multiple
vendors
potentially
right.
E
E
But
I
do
think
it's
important
to
keep
in
mind
that
if
we
have
too
much
that
we're
still
requiring
users
to
do
as
far
as
adding
in
extra
imports
or
configuration,
it
also
starts
taking
away
from
the
point
of
the
launcher
and
at
that
point
it's
better
off
if
they
just
use
the
sdk
without
the
launcher.
So
we
want
to
make
sure
to
also
keep
that
as
simple
as
possible,
be
able
to
like
hit
the
eject
button
and
say
no.
You
know
what
never
mind.
E
B
I
think
I
agree,
I
think
david
brings
up
a
really
good
point,
though,
and
maybe
something
I
didn't
think
about
is
we
should
we
have
what
it
is
and
I
think
it
we
also
need
to
include
what
it
isn't,
because
we
inevitably
will
start
this,
and
then
you
will
get
an
issue
saying
like.
Can
we
add
an
option
here?
You
know
the
default.
Sda
can
do
this.
Why
can't
this
do
this,
and
I
think
that
we
need
to
have
a
good.
B
You
know
at
least
document
to
point
to
that
says.
This
is
what
it
is.
This
is
what
it
isn't.
You
know
if
you
want
to
configure
this
more
fine
grain,
you
need
to
go
somewhere
else.
I
do
think
you
hit
that
hit
it
on
the
head,
like
you
want
to
have
this
where
out
of
the
box,
this
is
going
to
work
with
80
of
the
use
cases,
but
it
also
needs
to
be
extensible
to
work
with.
B
I
think
other
vendors,
I
think,
is
another
thing
that
also
we
want
to
hit
as
like
one
of
the
things
that
it
is,
and
I
think
that
what
you
want
to
say
also
is
that
what
it
isn't
is
the
sdk
like
that,
like
yeah,
if
somebody
came
back
and
said
like,
why
can't
I
configure
the
simple
span
processor
to
be
used
with
the
launcher,
I
think
we
need
to
have
some
way
to
like
say
in
a
categorically
like
this:
that's
not
what
this
is.
B
That's
not
what
this
intended
was
intent
was
and
like
here's,
here's
a
good
place
to
reference.
We've
all
come
to
that
conclusion.
We
all
agree
on
it
and
just
to
communicate
that
I
think,
is
really
important
going
forward,
because
without
communicating
it
it's
hard
for
new
users
to
understand
it.
I
think
it's
a
good
point.
F
Would
it
be
helpful
for
for
us,
in
this
proposal,
to
like
effectively
propose
an
opinion
about
like
the
like
these,
like
two
things,
I'm
using
the
number
two
but
like
these?
Two
things
should
be
extensible
and
nothing
else
should
be
extensible
for,
like
these
reasons,
and
then
we
kind
of
decide
as
a
group
like
okay,
how
much
of
this
should
be
extensible
versus
how
much
of
this
is
like?
Okay,
if
you
want
this
amount
of
extensibility,
don't
use
the
launcher,
go
use
the
base
sdk,
because
you
can
plug
in
anything.
F
You
want
orthogonally
to
your
choosing.
That
feels
like
it's
kind
of
missing
here,
and
I
think
that
that
hits
the
point.
The
the
the
meta
point
here
and
certainly
will
be
a
point
of
confusion.
If
it's
not
called
out
when,
when
people
want
that
sort
of
stuff
in
the
future.
B
I
think
that
yeah,
I
definitely
think
so,
because
I
think
there
are
people
on
the
call
that
are
thinking
of
things
that
maybe
are
included,
but
that
aren't
you
know
you
said
two
things
and
I
immediately
go
to
like
well:
okay,
like
what
about
id
generation,
what
about
like
sampling
rates
and
all
these
like
these
complex
samplers?
Is
that,
like
a
handle
like
once,
we
go
to
metrics?
B
D
So
one
way
that
it
might
be
interesting
to
look
at
this
as
well
is:
what
would
we
do
if
we
could
have
a
second
bite
at
the
apple
of
configuring,
the
sdk
like
could?
Could
we
use
this
as
an
opportunity
to
say?
Is
there
a
way
to
get
all
of
this
configuration
flexibility,
but
more
simplicity
for
simple
things.
E
Yeah-
and
I
guess
I
think
that
might
have
been
yeah-
I
think
david
had
made
that
point
on
the
one
google
doc
as
well
is.
Would
this
be
solved
with
better
defaults
out
of
the
box,
or
things
like
that,
and
I
think
that's
a
valid
question
and
and
perhaps
worth
considering
more.
It
probably
goes
sort
of
both
ways
between
being
opinionated
and
being
as
flexible
and
neutral
as
possible
and
they're
just
sort
of
two
different
approaches,
and
neither
is
really
right
or
wrong.
E
C
C
Well,
I
was
going
to
say
that
I
feel
like
in
the
short
term
the
the
debate
we're
having
is
sensible
and
and
there's
a
like
anthony's
question
like
is
the
second
bite
of
the
apple,
is
really
appropriate,
but
in
the
longer
term,
we're
also
looking
at
like
configuration
mechanisms
and
I
feel
like
what
we're
actually
doing
here
is
just
bypassing
the
configuration,
the
long-term
solution.
We
want
to
get
to
a
short-term
thing
where,
like
you,
don't
actually
provide
much
configuration
because
you're
defaulting
everything,
but
getting
that
long
term
requires.
C
Oh,
my
god,
a
whole
spec
on
that,
like
configuration,
is
hard
like
dynamically
loading
stuff,
so
you
don't
have
to
have
dependencies
another
problem
like
there's
just
a
ton
of
stuff.
In
the
way.
That's
all
I'm
saying-
and
I
think
this
is
like
pragmatically
speaking,
yes
to
anthony's
question.
Maybe
this
does
belong
in
the
in
the
main
repo
as
a
placeholder
for
eventual
configuration,
support.
B
Yeah,
that's
a
good
point.
I
keep
coming
back
to
thinking
about
like
a
configuration
document
similar
to
like
what
the
collector
has
in
that
respect,
because
then
you
start
providing
essentially
like
a
default.
Configuration
is
just
a
configuration
file,
that's
included
in
the
repo
and
that
extension
from
that
can
be
really
easily
configured
it
also.
Is
you
know
something
that
you
can?
You
can
always
say
like
we
can
keep
on
extending
this
instead
of
you
know,
like
you
know,
you're
saying
calling
the
record
and
going
back
to
the
sdk.
B
That's
that's
where
all
the
configuration
is
going
to
be
defined,
and
I
really
think
that's
important
because,
like
you
can
do
exactly
that,
like
you
can
pass
one
that
configures
a
sampler,
a
propagator,
an
exporter
of
different
types,
you
can,
you
can
essentially
have
the
structure
of
what
an
exporter
would
look
like.
So
even
a
third
party
could
provide
their
own
configuration
of
an
exporter
via
the
cml
file
and
it
should
be
able
to
parse
it
if
you've
registered
it
correctly.
B
So
I
mean
I
really
do
see
like
something
similar
to
like
the
kubernetes
world,
with
the
extensibility
of
having
a
configuration
file
like
generate
this.
I
feel
unprepared
to
really
talk
about
the
extension
of
that
and
like
how
that
could,
I
think,
work
because
I
haven't
thought
through
at
all.
In
fact
I'm
having
discussions
right
now
on
a
lot
of
this
stuff,
but
I
think
that's
a
good
point
anthony,
like
you
know
these
configuration
options
like
it
may
just
be
makes
sense.
I
don't
know.
D
Kind
of
yeah-
and
I
want
to
be
clear
here-
I
I
don't
want
to
make
the
perfect
the
enemy
of
the
good.
I
think
that
what's
proposed
here
is
a
good
thing
and
a
good
way
to
go.
I
would
just
say
if
there's
a
way
to
to
think
about
building
it
in
a
way
that
that
gets
us
closer
to
that
without
forcing
us
to
make
that
hard
cut
off
between
you've
got
the
easy
way
or
the
the
good
way
the
complete
way
can
we
blur
those
boundaries
more.
That's
worth
spending
a
little
time.
F
Is
it
should
should?
Would
it
maybe
be
appropriate
to
like
say
that,
like
a
a
long-term
goal
of
the
launcher?
Is
that
the
launcher
obviates
itself
by
having
good
ideas
pushed
back
into
the
corresponding.
D
B
Yeah,
I
agree,
I
think
I
think
the
important
thing
that
you
said
is
like
don't
let
the
perfect
be
the
you
know
the
enemy
of
the
good
enough,
and
I
think
that's
that's
critical
here
and
I
think
that
what
I'm
describing
is
something
that
is
a
bigger
iteration
on
that,
and
so
I
I
agree.
I
don't
want
that
to
hold
up
this
initial
design,
especially
if
it's
not
planned
to
be
released
as
a
stable
design.
You
know
in
the
near
term.
I
can
see
us
iterating
on
that.
I
I.
B
B
I
also
see,
then,
that
the
line
changing
from
configurability
to
import
size
and
binary
size
like
you
would
only
want
to
use
the
default
sdk
if
you
wanted
to
have
find
control
over
like
what's
imported
versus
the
launcher,
importing
everything
and
then
maybe
that
changes
in
the
future
when
go,
has
a
great
way
to
dynamically
load.
Libraries
which
I'm
not
going
to
hold
my
breath
for
but
yeah.
B
Josh
is
laughing
okay,
so
I
I
think
we
have
some
good
discussion
on
this.
We're
about
ten
minutes
left
jamie
and
phil.
Do
you
have
a
good
idea
of
what
next
steps
are
or
are
you
lost?
I
want
to
make
sure
that
we
have
good
direction
here.
E
I
think,
as
far
as
I'm
looking
at
it
as
we
want
to
go
in
and
be
very
explicit,
we
have
the
first
line
of
what
it
is.
We
want
to
add
in
there
what
it
isn't
be
clear
about
what
we
don't
want
included
in
here
and
also
in
there
be
clear
about
these
are
the
things
we
intend
to
be
extensible,
and
these
are
the
things
that
are
not
intended
to
be
extensible
just
to
be
as
explicit
as
possible
and
then
follow
up
on
on
feedback
from
there
is
there
others
that
I
missed
on
that.
E
B
Think,
if
that's
spot
on,
I
will
also
try
to
go
back
and
review
this
again.
So,
yes,
I
think
that
looks
good
josh.
You
posted
a
comment.
C
I
was
the
the
reason
I
was
chuckling
at
your
statement
earlier,
like
not
only
your
breath
for
go
team.
To
do
anything
is
that
I
investigated
this
back
when
issues
were
numbered
in
the
two
digits
and
came
away.
Thinking.
Go
would
never
do
that
and
they
seem
to
not
even
support
their
own
plug-in
module
and
probably
think
it
was
a
mistake.
B
Yeah
but
I
agree,
but
I
think
that's
that's
the
joke
yeah.
I
do
remember
this
issue.
Okay,
yeah,
like
I
said
not
holding
my
breath
over
that
one,
so
maybe
also
that's
just
going
to
always
be
the
case.
There'll
be
a
launcher
that
sits
inside
okay,
cool
we've
gone
through
everything
on
the
agenda.
Eight
minutes
left.
I
want
to
pause
here,
see
if
there's
any
good
use
case
stories
of
open
symmetry.
C
Oh
yeah,
I
have
an
update,
oh
cool,
which
is
that
there
is
now
tracing
in
the
cubelet.
So
that's
exciting.
B
That's
yeah,
that's
really
exciting.
I
love
how
subtle
that
comment
was
that's
huge.
B
Man,
that's,
do
you
know
what
version
of
hotel
go
they're
using?
I
think
it's.
F
B
Nonetheless,
that's
super
exciting
thanks
for
all
the
hard
work
on
that
one
david.
That's
that's
really
exciting.
I
definitely
think
you
guys
can
help
with
adoption,
let
alone
the
world
and
helping
to
have
observability
into
the
systems
that
are
operating
their
code,
so
yeah.
B
Yeah
yeah,
I
definitely
would
love
to
see
that
vr
well,
cool
as
david
looks
for
that
is
anybody
else.
Have
guessed
good
use
case
stories.
F
F
What's
the
status
of
this
thing,
we're
like
well,
what
are
they
actually
asking
about
and
in
some
totally
unscientific
polls
we
found
that
the
majority
of
people
are
asking
actually
about
language
sdk
status
for
like
a
given
thing,
rather
than
like
spec
status,
protocol
status
or
collector
status,
and
it
turns
out
the
open,
telemetry
website
talks
about
those
things
that
people
are
not
as
interested
about
and
when
you
wanna
like
dig
into
the
status
of
a
thing
for
a
given
language.
F
B
Yeah,
that's
really
great
feedback,
I'm
guessing
phil.
Are
you
working
with
the
docs
website
on
this
one.
F
Yeah
yeah,
and-
and
so
it
it's
kind
of
two
pieces
to
it.
It's
like
ensuring
that,
first
of
all,
everything
that's
there
is
like.
We
want
that
to
be
like
a
canonical
status
page
that
people
can
look
at
for
like
a
given
language
that
it's
actually
accurate
and
like
formatted
kind
of
similarly
to
all
of
the
languages,
all
that
stuff
and
then
figuring
out,
like
a
good
way
to
link
to
that
from
the
actual
status
page,
which
currently
doesn't.
B
C
B
B
Okay,
anybody.
B
B
Awesome,
I
think
we
can
edit
here
then
thanks.
Everyone
for
joining
really
appreciate
your
time
and
all
the
hard
work
definitely
looking
forward
to
moving
forward
a
lot
of
these
issues.
So
it's
really
exciting
yeah.
Thanks
again,
we'll
see
you
all
next
week
same
place
same
time
or
virtually
bye.
Everyone.