►
From YouTube: 2021-07-29 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).
B
A
B
Yeah,
it's
weird
because
I
think
rich
can
back
me
up.
I
think
it's
something
like
97
supposed
to
get
to
today
like
it's
supposed
to
get
hot,
but
it
feels
weird
damn
yeah,
I
think
it's.
The
humidity
is
probably
what's
happening.
B
Yeah
but
it's
definitely
not
115,
so.
B
D
And
the
thermostat
is
way
down
another
part
of
the
house,
so
you
know
we
get
up
to
about
80
85
and
then
things
usually
kick
in.
I
know
yeah.
I
try
to
try
to
acclimate
myself
to
it,
so
it
doesn't
bother
me.
D
B
B
B
B
So
it
looks
like
we
might
actually
have
a
reasonable
quorum
might
actually
be
the
total
of
what
we're
gonna
get
today.
So
why
don't
we
jump
in
here?
Actually,
josh
isn't
here.
That
would
be
really
nice
to
have.
B
Okay,
well,
let's
start
I
might
readjust
the
agenda
and
talk
about
the
metric
stuff
later
on
if
he
joins
later
on,
but
yeah
jump
in.
Please
add
your
name
to
the
attendees
list.
If
you
haven't
already,
if
you
have
anything
specific,
you
want
to
talk
about
pr's
issues
or
ideas,
add
them
to
the
agenda
and
we'll
jump
into
them
start
off.
Let's
jump
on
the
project
boards
that
we
have
going
for
the
stable
100
release.
This
is
probably
going
to
be
for
an
rc3.
I
don't
know.
B
I
keep
saying
these
things,
but
eventually
it
gets
to
the
stable
rc
release,
but
doing
pretty
good,
definitely
seeing
some
progress
in
the
past
week,
some
steady
march
forward,
which
is
good
our
issue
to
do,
did
go
up,
but
maybe
we
can
talk
about
the
added
issue
and
see
if
it
is
entirely
needed.
I'd
like
to
get
actually
that
this
probably
should
be
on
the
agenda.
B
B
I
think
that
this
is
something
seven
days
ago,
so
maybe
I
haven't
talked
about
it
in
this
meeting
yet,
but
if
not,
the
idea
is
that
the
hotel
test
package
there
was
an
original
issue
here,
where
boggson
pointed
out
that
the
api,
probably
shouldn't
depend
on
the
sl
test
package
and
looking
further
into
the
hotel
test
package.
There's
a
lot
of,
I
think,
half
ideas
in
there
and
one
of
the
half
ideas
is
that
this
idea
that
we
need
a
second
implementation
outside
the
sdk.
B
We
talked
a
little
bit
about
this
in
last
week's
sig
meeting,
where
there's
just
like
this
underlying
problem,
if
you're
not
using
the
default
sdk
to
test
where
you're
in
a
rock
and
a
hard
place,
but
I
think
that
what
we
have
is
there's
a
proof
of
concept
that
I've
put
out.
B
If
you
haven't
seen
it,
I
posted
it
in
the
slack
channel
last
week
where
we
could
use
the
default
sdk
and
we
can
use
that
in
a
separate
module.
So
we
don't
actually
impose
a
dependency
on
the
sdk,
but
we
are
able
to
provide
the
users
with
the
confidence
that,
like
we're,
testing
and
that
what
they
you
know,
99
of
the
time,
are
going
to
be
used
for
their
sdk
it'll
work
and
that
we
can
provide
integration
tests.
B
So
if
you
haven't
seen
this
proposal
yet
I
think
if
this
is
one
that
could
use
some
eyes
if
you're,
if
you're
interested
in
the
topic,
there's
other
pr's
coming
down
the
pipeline.
So
if
you
have
a
lot
on
your
plate
and
want
to
wait
till
it
comes
to
the
forefront,
that
can
also
happen
too.
So
yeah
progress
is
being
made
on
that.
I
think
right
now
in
the
standard
library
there
I'm
sorry
in
the
main
repo.
We
have
a
span
recorder
which
was
added
just
this
morning.
B
I
think
the
pr
was
out
last
week
as
well,
and
that
is
something
that
kind
of
mirrors
the
span
recorder
that
was
in
the
hotel
test.
This
definitely
got
some
different
calling
conventions,
but
it's
it's
a
similar
concept.
You
can
take
that
spanner
corner.
Why
don't?
We
take
a
look
at
it?
In
case
people
haven't
seen
it
and
you
can
register
it
as
a
spam,
processor
and
and
then
that
spam
processor
can,
you
know,
just
be
used
in
testing.
This
is
obviously
not
intended
for
use
in
production.
B
That's
why
it's
in
the
trace
test
package,
but
the
idea
is
it's
used
in
a
few
other
places
and
you
can
kind
of
see
the
the
flow
of
spans
as
they
go
through
very
similar
to
what
we
used
to
be
and
or
currently
exists
in
the
hotel
test
package,
but
it
can
be
used
as
a
reef
as
a
replacement
and
the
only
place
we
actually
use.
The
span
recorder
in
the
main
repo
is
in
the
open
census
bridge.
B
So
there
is
a
proof
of
concept
for
a
refactor
for
the
open
census
bridge
and
it
does
involve,
amongst
other
things,
use
of
the
span
recorder
from
the
internal
trace
test
package
and
uses
the
default
sdk
to
validate
all
of
the
things.
It's
actually
testing,
it's
a
big
refactor.
It
includes
breaking
this
out
into
its
own
test
package,
and
so
it's
I
think
like
this
is,
if
you're
waiting
for
the
real
proof
of
concept.
This
is
kind
of
what
I
was
talking
about
coming
down
the
pipeline.
B
It's
still
coming
down
the
pipeline,
though,
because
I
didn't
want
to
inflict
on
the
community
used
to
be
a
thousand
400
lines
with
you
know,
300
lines
taken
out,
so
I'm
trying
to
break
this
apart
into
some
more
piecemeal
digestible
prs
right
now,
and
it's
blocked
on
this
idea
that
we
actually
need
an
internal
package
for
a
lot
of
this
type
of
implementation.
B
If
we're
going
to
share
these
conversions
and
types
across
module
and
package
boundaries,
so
that's
up,
I
think
anthony
is
the
only
one
who
has
seen,
or
at
least
has
reviewed
the
internal
conversion
or
internal
package.
If
you
have
time
a
review
on
this
will
progress
this
issue,
and
this
issue
is
definitely
a
part
of
the
the
main
progress
to
our
stable
release.
So
it
could
definitely
be
some
eyes.
So
that's
a
very
long
winded
say
this
is
in
progress.
B
B
That
said,
I
think
we
can
pause
there
because
I
spoke
for
probably
seven
minutes.
If
anybody
has
any
questions
and
then
we
can
jump
in
and
talk
a
little
bit
about
this
one.
E
So
the
lambda
instrumentation
pr
that
garrett
has
up
in
the
control
repo
also
uses
that
same
pattern
to
avoid
the
use
of
hotel
test.
So
that
could
be
another
good
thing
to
look
at
if
people
want
to
see
how
it
can
work.
B
Awesome
yeah
that
is
super
exciting
to
hear
I'm
guessing
yeah.
I
definitely
need
to
review
this.
Then
we.
F
Cool
we
switched
to
doing
that
because
we
were,
I
had
switched
over
to
use
the
hotel
test
framework
and
then
there
were
some
issues
of
it
not
working
the
same
way.
So
I
went
to
anthony.
I
was
like
hey:
do
you
know
why
this
doesn't
work
and
he's
like?
It's
probably
the
same
thing
tyler's
been
talking
about
it's
like
okay,
so
we
went
ahead
and
did
it
just
like
you
said,
and
it
works
great.
B
Okay,
cool,
that's
really
good
feedback.
I'm
glad
to
hear
that.
B
Okay,
cool:
let's
keep
this
going
the
next
issue,
I
don't
know
if
there's
been
too
much
movement
on
this,
there's
an
open
pr,
it's
pretty
slow
going.
I
think
this
might
be
one
of
their
first
prs
to
the
repository.
I
think
I
saw
some
movement
this
morning,
but
I
might
have
been
mistaken.
Oh,
I
think
it
might
have
been
just
a
comment.
So
I
think
the
original
author
is
not
active.
B
We
may
need
to
pick
this
up
if
this
becomes
a
blocker,
but
we
still
have
a
lot
to
go.
I
think
before
this
becomes
a
blocker
but
yeah,
I
guess
that's
the
update
on
this
one
cool.
I
think
the
only
other
thing
is
just
new
things
that
are
added
this
we
talked
about.
I
think
this
is
the
end
of
the
things
we
talked
about
last
week.
B
This
is
a
new
bug
that
I
was
discovering
bogdan
pointed
out
a
few
weeks
ago
to
me
that
the
internal
representation
for
the
global
tracer,
the
global
meter
and
the
global
propagators
can
all
be
reset
as
many
times
as
you
want,
which
I
thought
was
wrong.
I
thought
that
we
didn't
do
that,
but
it
definitely
turns
out
in
the
code.
That's
the
case
and
a
lot
of
testing
applications
set
the
global
tracer
meter
and
propagators
multiple
times.
B
So,
if
we
didn't
do
this,
it
will
likely
break
all
of
those
tests
because
it
will
only
allow
it
to
set
once
if
we
change
it.
However,
the
error
handler
is
not
the
case.
This
actually
can
only
get
set
once
there
is
no
storage
outside
of
the
actual
initial
delegation,
and
this
issue
is
specifically
saying
that
this
inconsistency
needs
to
get
resolved
because
using
the
global,
I
think
any
global
functions.
We
probably
want
to
be
consistent
on
how
we're
doing
that,
and
we
don't
want
to
remind
ourselves
like
oh
in
this
one.
B
You
can
do
this
and
this
one.
You
can't,
I
think,
after
seeing
what
bogdan
did
and
after
seeing
the
proper
use
cases,
I
would
probably
say
I
recommend
to
just
allow
this
to
be
reset
as
many
times
as
you
want.
Obviously,
you
can't
reset
back
to
the
initial
delegator,
which
is
true
for
all
of
these,
but
I
think
being
able
to
set
this
as
many
times
as
you
want
seems
fine.
Initially
that
wasn't
done.
I
never
really
understood
it.
I
think
that
was
one
of
the
original
authors,
understanding
that
like.
B
Why
would
you
ever
want
to
do
that?
Maybe
there's
going
to
be
some
errant,
like
instrumentation,
that
is
doing
this
maliciously,
I'm
of
the
opinion
that
that's
up
to
them
and
if
you
want
to
prevent
that,
you
should
definitely
not
be
using
a
global
value
of
any
type,
but
I
open
the
issue
just
to
kind
of
get.
I
think
consensus
on
what
people's
thoughts
are
and
then
implement
a
fix.
B
Cool,
so
if
you
have
any
strong
opinions
or
if
you
have
any
weak
opinions,
please
add
them
to
the
issue.
I
think
that
building
some
consensus
before
before
we
actually
put
a
solution
out
is
gonna,
be
helpful
for
preventing
churn
so
yeah
I'd
like
to
I'd
like
to
progress
that
cool
and
otherwise
I
think,
if
that's
it,
for
the
project
board,
unless
anybody
else
wanted
to
talk
about
something
on
here.
E
B
I
think
on
this
one
specifically
there's
an
action
item
where
we
need
to
have
a
benchmark
that
is
more
of
a
real
world
situation,
to
show
that
the
allocation
does
or
doesn't
actually
impact
the
end
user,
essentially
like
after
the
initialization.
Does
the
you
know
is
the
compiler
actually
optimizing
this
away?
I
guess
is
the
end
question
this
one,
I
think
actually
has
some
action
items
on
it
that
are
probably
not
even
going
to
include
a
pr,
but
just
somebody
digging
into
it
was
my
understanding
of
it.
B
I
I'm
happy
to
be
corrected
this
one,
I
think
is
probably
done.
I
would
want,
I
think,
bogdan
to
maybe
take
another.
I
don't
have
some
really
strong
opinions
on
that,
but
I
think
that
we've
kind
of
like
unified
on
the
fact
that
we're
not
gonna,
align
and
couple
the
projects
and
that
we
want
to
have
the
type
conversions
be
explicit
based
on
the
exported
types,
not
on
the
underlying
integer
types.
B
So
maybe
just
reviewing
that
we're
correctly
doing
that,
as
I
think
was
pointed
out
in
this
bug,
and
then
closing
this
is
what
I
would
anticipate.
I
think
bogdan
wanted.
Some
more
community
involvement
and
community
feedback
is
what
he
told
me.
I
think
in
person
just
to
not
close
this
right
away
just
to
see
if
the
community
had
a
different
opinion
and
they
wanted
a
couple.
I
guess.
E
Okay,
aws
expects
that
we'll
have
some
interns
who
are
finishing
up
their
projects
with
some
time
left
in
their
internships,
so
we
hope
to
be
able
to
direct
them
at
some
of
these
issues
over
the
next
couple
weeks.
B
Okay,
yeah.
I
think
this
is
a
really
good
one,
although
I
get
really
excited
about
nerdy
things,
so
maybe
other
people
don't
care
but
yeah
like.
I
think
this
is
like
a
fun
one
to
dig
into
like
what
the
compiler
is
actually
doing,
but
I
can
see
why
people
may
not
be
into
that
so
yeah.
I
think
these
are
great
issues
anthony
if
you
wanted
to
assign
somebody.
B
Awesome
well,
let's
see
if
josh
joined,
I
see
josh
on
the
attendees
list,
perfect.
Well,
there's
josh
yeah!
I
see
a
wave,
so
I
wanted
to
jump
into
this.
Do
we
have
aaron
on
the
call
as
well?
B
Okay,
aaron
definitely
wanted
to
talk
a
little
bit
more
about
this
sdk
implementation,
the
sdk
api.
We
didn't,
I
think,
fully
get
through
all
of
this
stuff
last
time
and
I
put
these
at
the
top
of
the
agenda
just
so
we
could
touch
on
it.
I
would
probably.
G
Suggest
something
asked
for
it
to
be
at
the
top.
I
would
be
happy
to
talk
about
it
in
the
group
either
way,
but
I'll.
Let
you
make
that
call
tyler
yeah
well,
which
would
how
would
you
like
the
ordering
on
these
joshua
I'd.
G
All
the
quick
pitch
just
to
remember,
keep
it
fresh
at
the
very
least.
This
is
the
idea
that
you
know
we
have
choices,
certain
freedoms
and
implementing
the
sdk.
Whatever
that
specification
is
going
to
say
it's
getting
closer
to
a
real
spec
of
the
metrics
sdk
spec
right
now,
but
we
already
have
parts
of
a
resource
spec-
and
you
know
some
sort
of
global
stuff
that
we've
specced
for
hotel,
that
it's
done
and
for
in
metrics
in
particular,
we
have
this
sort
of
rich
variety
of
instrument.
Type.
G
The
interface
to
those
instruments
is
both
number
type
specific,
but
also
instrument
specific,
so
we've
added
type
structure
to
help
the
user
keep
clear
what
they're
doing
with
those
instruments,
and
it
means
that
there's
just
a
pretty
wide
surface
area.
The
problem
we
have
today
there's
an
existing
metric
api
prototype
and
it
has
a
tremendous
number
of
classes,
all
jumbled
into
one
package.
G
Now
I
have
prototyped
some
improvements
to
that
situation,
and
I've
also
looked
at
simplifying
the
existing
api.
The
way
it
stands
in
both
cases,
I
came
to
the
conclusion
that
there
were
essentially
a
fixed
number
of
classes.
They're
listed
on
in
the
screen
here
that
are
essentially
a
bridge
between
a
lower
level
implementation
which
takes
in
measurements
that
are
generic
and
instruments
that
are
generic,
and
these
are
the
bridge
between
the
rich
surface
area
of
a
of
the
real
api
and
the
low
level
implementation
of
that
api.
G
So
I
I've
again
said
I've
prototyped
two
ways
of
doing
this.
One
is,
I
can
pull
these
things
out
of
the
existing
metrics
api
just
to
make
it
look
simpler,
because
no
user
cares
about
these
types.
G
G
That
can
be
any
of
the
instrument
types
and
instead
go
with
this
like
fairly
wide
interface
type,
which
would
be
the
meter
or
the
meter
provider.
The
meter
has
like
six
constructors
for
six
different
instruments
and
they
all
return
six
different
interfaces
and
then
you've
got
six
different
instruments
from
which
you
have
an
add
method.
G
If
it's
a
of
a
counter
or
you
have
a
record
method,
if
it's
a
histogram
or
like
you
have
a
and
if
they're
asynchronous,
you
have
a
different
pattern,
but
the
idea
would
be
that
you
could
just
turn
that
whole
surface
area
of
the
metrics
api
into
a
just,
a
bunch
of
interfaces
and
then
to
implement
the
enter
the
api
to
do
to
become
an
sdk.
You
have
to
provide
the
implementation
of
a
bunch
of
interfaces,
and
that
would
be
the
reality.
G
The
thing
is
we're
going
to
have
to
do
it
at
least
twice
in
our
own
code
base
and
and
maybe
three
times,
and
I'm
not
sure,
but
it's
like.
If
you
look
at
the
way
global
is
implemented,
global
would
have
to
change
and
and
because
you
could
say
well,
the
registry
package
doesn't
matter,
it's
just
an
implementation
detail
for
us
like
this.
G
Let
us
have
the
same
code
for
the
test
package
as
for
the
real
sdk
for
for
naming
stuff,
but
that
could
just
be
an
internal
to
the
sdk,
but
when
it
comes
to
global
it
can't
be
internal,
but
the
idea
of
hotel,
I
believe,
is
that
we
can.
You
can
provide
your
own
sdk
at
runtime,
just
swap
it
in
it's
vendor
neutrality.
G
That
way,
and
so,
if
the
sdk
is
provided
by
anybody
in
the
world,
that
means
it
has
to
be
the
full
on
api,
whatever
that
is,
and
that
means
that
global
will
have
to
implement
the
same
exact,
rich,
every
every
exact
interface
that
the
sdk
did.
So
we
would
have
this
just
kind
of
prolifer
proliferation
of
type
satisfying
interfaces,
and
my
opinion
is
that
the
sort
of
code
works
out
smaller
and
neater
and
a
little
bit
more
manageable.
If
you
have
a
lower
level
interface
with
two
methods.
G
Really
it's
it's
new
synchronous
instrument,
a
new
new
asynchronous
instrument
and
then
most
of
the
interaction
with
the
sdk
is
done
in
general
terms,
and
I
think
it
makes
things
a
little
nicer,
but
it's
definitely
an
option
and
it's
an
opinion
that
I
have,
and
that
was
what
we
were
going
to
discuss
for
this
issue
called
move
metrics,
sdk
implementation
types
into
sdk
api
sub
package.
G
G
We
just
need
to
do
some
renamings,
but
if
we're
going
to
change
the
sdk
to
get
closer
to
spec,
it
really
needs
some
work
done
and,
and
then
this
work
has
to
just
happen
and
it's
it's
kind
of
moving
very
slowly
so
because,
because
I
think,
there's
a
lot
of
confusion
over
all
the
different
things
that
are
about
to
happen,
we
got
to
change
the
sdk
a
bit.
It
would
be
nice
to
simplify
it,
and
this
is
one
of
the.
G
These
are
two
sort
of
two
two
issues
about
simplifying
the
existing
sdk
having
to
do
with.
If
you
look
at
the
otlp
exporter,
how
the
fact
that
we
have
records
that
carry
instrumentation
library,
name,
inversion
and
resource
forces
us
to
do
a
bunch
of
joining
downstream
and
all
that
information
according
to
the
specs,
we
have
should
be
kept
separate
all
through
the
export
pipeline.
As
far
as
I
can
tell
so,
these
are
nice
simplifications.
G
They
streamline
everything,
they
take
away
code
and
memory
and
cpu,
but
it's
like
a
bunch
of
changes,
and
so
I've
been
kind
of
trying
to
figure
out
the
right
order
to
do
them.
We
have
one
outstanding
today.
That's
this
one
here
and
I
think
what
I
want
to
do
is
project
some
confidence
here,
we're
going
to
get
a
good
sdk
and
we
have
to
make
two
or
three
changes,
and
you
won't
see
the
light
until
the
end
of
the
two
or
three
changes
anyway.
I'll
stop
talking
now.
B
E
Was
needed
go
ahead?
I
think
my
question
regarding
this
issue
here
is:
would
implementing
this
sdk
api
and
making
the
the
metrics
api
structs
that
you
utilize
it
would
that
in
any
way
limit
the
choices
that
alternate
sdk
implementers
have
or
are
we
funneling
them
down?
One
particular
implementation
path.
G
I
mean
in
a
sense
yes,
because
you
have
forced
well,
I
mean
you
forced
the
decision
to
use
this
generic
low-level
api
on
all
sdks.
That
is
absolutely
true
and
the
alternative
being
again
a
bunch
of
interfaces.
G
The
way
the
way
I
and
but
I
there's
a
question
about
performance,
mostly
anthony
and
then
sort
of
the
way
that
this
has
been
done.
There's
a
there's
going
to
be
one
interface
method,
call
per
event
kind
of
no
matter
what
you
do,
whether
it's
an
aggregator
call
or
a
dedicated
instrument
call.
The
decision
that
you
asked
about
is
that
we've
fractured
our
sdk
into
a
kind
of
like
thing.
G
So
the
decision
that
we're
forcing
then
is
that
you
will
get
your
inner
inputs
through
this
generic
measurement.
Struct
you're
going
to
have
an
interface
method
call
one
way
or
the
other
is
I
mean
that's
the
nature
of
open
telemetry
and
I
think
we've
got
it
well
down
to
I'd,
have
to
look
at
it's
two
interface
method
calls
right
now,
one
to
get
into
the
sdk
and
one
to
get
into
the
aggregator.
G
The
there
may
be
an
alternative
where
there's
only
one
interface
method
called,
but
that
could
be,
I
don't
think
we're
preventing
the
any
arbitrary
sdk
from
having
that
we
we're
only
for
the
only
api
only
forces
one
of
those
it's
the
sdk's
organization,
of
course,
is
the
second
votes.
E
Okay,
is
there?
Is
there
room
for
kind
of
a
middle
ground
somewhere
where
we
would
define
the
api
in
terms
of
interfaces,
but
that
provide
a
set
of
structs
that
implement
those
interfaces
and,
in
turn,
take
this
lower
level
interface?
That
you're
talking
about?
Could
that
simplify
the
the
multiplication
of
implementations
we'd
have
to
deal
with?
I
guess
so.
Yeah.
E
G
We
would
introduce
new
interfaces
for
the
constructor
methods.
The
the
event
when
you
actually
call
a
metric
interface
is
still
going
to
be
one
interface
dispatch.
So
actually,
yes,
anthony.
That
is
a
possibility.
Then
then
we're
providing
pure
flat
flattened
is
the
word
I
want
to
say
it's
like
we've.
We've
created
a
proliferation
of
types
so
that
every
particular
entry
point
has
an
interface
rather
than
having
this
general
low-level
thing.
G
But
then
we
would
provide
an
sdk
api
helper
package,
which
is
the
thing
that
implements
the
wide
interface
from
this
narrower
narrower,
narrower
interface.
Yeah,
that's
a
that's
an
organization
that
we
can
definitely
have.
Let's
see,
would
I
still.
G
I
would
still
advocate
that,
like
the
way
the
code
is
now
we
have
to
start
making
incremental
changes,
and
I
I
want
to
convince
you
all
that
we
should
create
this
separate
sdk
api
directory
so
that
we
can
start
to
have
an
independent
api
get
built,
and
I
think
what
you're
asking
for
and
tyler
is
welcome.
You're
welcome
to
have
I'm
here
to
serve
really.
Is
this
wide
sort
of
set
of
interfaces
that
corresponds
with
whatever
interface
wrapper
helper
methods
that
we
create,
so
that
you
can
just
create
this
low
level?
G
B
I'm
thinking
more
about
this,
I'm
not!
I
don't
know
if
it's
worth
it.
I
I
like
this
sdk
api
package
more
and
more,
but
I've
got
some
questions
first
off.
I
I
think
that
there
was
a
stupid
mistake.
I
was
making
my
head
that
this
sdk
api
is
in
the
api
package.
It's
not
in
the
sdk
package.
So
yes,
it's.
B
Yeah,
I
know,
and
that
makes
sense
for
some
reason
in
my
head.
I
just
thought
it
was
the
other
way,
but
it's
not
the
case.
B
Interfaces
though
right
yeah,
entirely
and
technically,
this
is
kind
of
already
how
it
is
implemented,
and
this
is
how
it
works.
I
am
interested
based
on
what
anthony
just
said,
like
the
extensibility
of
other
sdk
authors,
if
they
wanted
to
do
something
different
so
like
like,
is
there
a
possibility
to
do
like
pass-through
interfaces
or
some
other
pass-through
sdks
like
I
think
john
watson
had
talked
about
with
this?
B
Like
you
know,
interface
definition
and
like
I
really
don't
want
to
hit
the
case,
where
kind
of
like
what
anthony's
saying
we
have
another,
you
know:
sdk
developer
come
to
us
a
year
or
two
from
now,
and
we
say
like
they
go
like
well,
we
want
to
implement
our
own
sdk,
but
we
aren't
able
to
because
you
truly
don't
implement
the
api,
like
you,
don't
have
an
interface
for
for
the
api,
and
so
we
have
to
implement.
You
know
this
narrower
version
of
what
the
api
is
asking
for.
B
Like
these
implementations,
I
don't
know
if
that's
ever
going
to
be
the
case,
but
I
that
that
would
be
a
tough
conversation
to
have.
But
I
also
think
that
it's
interesting
because
in
this
past
week,
working
with
open
census
and
I'm
guessing
there's
probably
a
few
other
places
in
open
telemetry
that
do
this
making
sure
I
got
the
right.
B
I
was
noticing
that
open
census
already
does
this
for
the
tracing
side
of
things
where
they
have
like
this
spin
interface
that
they,
you
know,
wrap
in
their
own,
like
struct
as
an
explicit
type
and
I'm
guessing
yana
was
one
of
the
big
proponents
to
making
this
happen,
and
this
is
a
very
similar
I
think,
proposal.
Obviously
this
is
kind
of
like
a
not
as
narrow
paired
down
version
of
what
we're
trying
to
do
with
this.
B
Like
you
know,
async
implement
or
sync
implements,
but
it's
a
very
similar
concept
where,
like
the
api
itself,
you
you
are
referring
to
the
span
and
the
span
has
its
own,
like
methodology
like
how
you'd
call
it-
and
I
think
that's
that's-
I
think
it's
it's
definitely
relevant,
and
I
think
that
this
is.
You
know
a
proof
that
we
could
probably
go
this
way,
and
unfortunately,
this
also
opened
up.
B
The
question
to
me
like
when
I
was
thinking
about
this,
I
think
the
main
reason
I
was
kind
of
like
unsure
about
this
is
because
it's
asymmetric,
like
the
metric
side
of
the
house,
is
doing
something
different
than
the
tracing
side
of
the
house
is
doing,
and
I
think
if
it's,
that
can
definitely
be
fine,
but
if
there
are
benefits
that
were
are
driving
us
to
want
to
do
this
in
the
metric
side
of
the
signals
like.
B
Are
there
things
that
we're
missing
in
the
tracing,
or
is
it
just
like
too
vanilla
to
even
want
to
do
that?
I
definitely
know
that.
Go
programmers
in
general,
like
working
with
concrete
types
like
having
structs
there
so
like
there
is
a
benefit
to
having
that
which
is
I'm
guessing.
B
What
drove
open
census
to
doing
something
that
looks
like
this,
but
yeah,
I
I
don't
know,
I
think
it
just
kind
of
opened
up
that
can
of
worms
a
little
bit
saying
like
is
our
tracing
api,
a
little
restrictive,
because
we
have
interfaces
and
we're
not
going
in
this
more
like
span
or
sdk
api
method.
There.
G
Fair
questions.
I
was
wondering
because
jana
had
given
us
feedback
in
this
room
a
year
ago
or
so
right,
and
I
don't
remember,
I
couldn't
find
the
notes
from
that,
but
it
was
very
helpful
and
there
was
a
point
where
she
defended
the
use
of
struct
types,
and
I
felt
like
I
I
wish
I
could
go,
find
yana's
rant
about
struct
types
for
his
inner
face
types
and
I
couldn't,
but
I
wonder
if
anyone
here
could
or
once
we
could
invite
her
to
to
also
look
at
this.
It's
just
a
thought.
G
I
know
she
said
something
about
it.
I
just
couldn't
find
it.
G
To
this
document,
when
I
proposed
there's
a
draft
api
that
depends
on
all
the
sdk
api
types
from
the
first
original
metrics
package,
but
it's
like
stripped
down
to
just
a
few
structs
but
kept
the
interface
underneath
it
yeah.
Her
first
point
is
get
the
documentation
to
look
right,
and
that
was
what
I
was
after
and
that
I
don't
remember
the
number,
but
it's
still
a
draft
pr.
G
G
H
H
Yeah,
and
usually
the
idea
is
that
interfaces
belong
with
consumers
so
that,
when
you're
implementing
something,
usually
you
do
your
best
to
ignore
the
whole
interface
concept
at
all
and
write
in
terms
of
structs
and
then,
when
callers
need
to
use
your
types.
H
If
it
helps
them,
they
can
define
interfaces
or
subsets
of
what
your
structs
exposes
methods
and
do
things
like
you
know,
build
testing,
fakes
of
them
or
insulate
themselves
or
wrap
them
or
whatever
they
want
to
do,
but
that
as
an
implementer
of
a
library,
if
you
start
out
thinking
about
interfaces,
you're,
probably
going
about
it
the
wrong
way,
in
other
words,
importing
techniques
from
from
other
languages
where
that
kind
of
thinking
is
essential,
but
that
in
go
it
can
actually
wind
up
being
detrimental
to
some
of
the
qualities
that
the
library
could
offer
for
its
users.
G
H
G
H
B
E
Yeah
and
that's
the
sort
of
thing
that
I
think
is
relevant
to
us
right,
we're
we've
got
this
this
interface,
where
we
expect
to
be
able
to
say
you
should
expect
these
things
in
many
places
you
should
be
able
to
pass
them
around.
You
should
be
able
to
use
them
in
this
way,
but
we
don't
know
what
the
actual
implementation
is
going
to
look
like.
C
E
It
may
change
right
so
the
implementation
of
an
error.
Maybe
it's
something
that
the
store
some
data
and
formats
it.
Maybe
it's
just
a
string.
There
are,
you
know,
probably
ten
thousand
different
implementations
of
the
error
interface
at
this
point,
but
nobody's
defining
their
own
error
interface
they're,
depending
on
that
interface
and
using
it
and
receiving
whatever
implementation
comes
along
by
whatever
they
called.
B
Yeah-
and
I
I
think
it's
interesting
to
kind
of
think
about
it
in
that
conceptual
light,
like
semantic
layer,
also
in
just
the
idea
that
this
interface
is
like
a
contract,
but
the
problem
is,
I
think,
is
that
we
have
a
little
bit
of
a
duality
here
like
anthony
pointed
out,
like
we
are
kind
of
saying
like
you
should
be
able
to
like
take
this
call
these
methods,
and
it
should
run,
but
we're
also
saying
like
we
expect
this
contract
to
change
well.
At
least
bogdan
is
very
adamant.
B
This
contract
is
going
to
change
over
time,
and
that
is
kind
of
like
goes
interface
type
is
like
that's,
not
that's,
not
acceptable,
that's
a
different
type
at
that
point,
so
yeah,
I
think
kind
of
what
steve
was
also
saying
like
you
in
the
go-isms,
you
kind
of
leave
this
parlance
of
other
languages
in
some
ways
and
that,
like
maybe
we
need
to
think
about
that.
B
I
yeah.
I
do
think
that,
like
having
a
specific
type
is,
is
very
useful
for
a
lot
of
people
and
having
a
concrete
type.
A
lot
of
people
prefer
it,
but
I
would
I
want
to
explore.
This
is
what
I'm
thinking
I
do
not
want
to
make
a
change
based
on
subjective
feelings
that
people
like
structures
better
than
they
like
interfaces.
B
That's
not
good
enough
for
me,
but
if
there's
like
concrete
things
that
we
could
actually
provide
to
our
users
by
doing
this,
you
know
sdk
api
and
the
trace,
as
well
as
the
metrics
side
of
the
house.
You
know
let
alone
the
implementation
of
an
sdk
being
very
optimized
easy
and
efficient,
as
josh
is
kind
of
pointing
out.
I
would
definitely
think
we
should
evaluate
this.
B
You
know,
I
think
we
could
support
what
we
have
going
forward,
but
if
this
this
takes
away
a
whole
host
of
problems,
namely
that
we
can
extend
these
things
in
the
future
in
a
way
that
is
easier
to
explain
our
versioning
incompatibility
strategy,
I
think
we
need
to
have
that
discussion
now,
rather
than
after
we've
locked
ourselves.
B
In
is
there
anybody
who's
just
like
this
is
not
something
we
should
be
having
a
discussion.
We
need
to
be
racing
towards
a
stable
police,
because
that's
also.
E
Yeah,
maybe
we
put
the
brakes
on
there
a
bit,
because
I
I
think
we've
gone
a
long
way
down
that
road.
We've
we've
got
our
versioning
policy
set
up
such
that.
We
expect
that
that
sdk
implementers
know
this
is
not
your
traditional
interface.
This
is
not
safe
for
you
to
assume
that
it's
never
going
to
change
and
if
it
changes
you're
going
to
have
to
keep
up
with
that.
We
keep
up
with
that
by
having
rsdk
in
the
same
repo
and
having
ci
that
ensures
that
happens,
but
it's
it's
different
from
the
way
go.
E
G
Explanation
for
why
this
is
different
as
well:
it's
not
not
an
ordinary
consumer
pattern,
so
otel
is
a
as
a
consumer
of
these
diagnostic
events
and
it's
very
much
not
supposed
to
produce
anything
actionable
or
usable
to
the
user.
You'd
never
get
a
result
back
from
an
hotel
api
because
it's
not
supposed
to
introduce
no
error,
an
error
for
you.
It
should
have
no
impact
on
the
running
code,
so
you're
never
supposed
to
get
back
of
value
from
open
telemetry.
G
H
Josh
you've
been
steadfast
about
this.
I
remember
hearing
this
from
you
when
I
first
got
involved
with
this
project
and
I
keep
it
in
mind
because
there
have
been
some
people
who
have
asked
over
time
things
like.
Can
I
read
the
span
name
from
a
span
or
can
I
they
want
to
be
able
to
query
back
things
that
were
supplied
earlier
higher
in
the
call
stack
and
in
general,
we've
said
no.
I
think.
I
think,
because
of
the
reasons
that
you
give,
I've
noticed
a
couple
things
slip
recently.
C
H
Like
that
perspective,
that
you
have
that
you
know,
there's
no
observable
effect
in
a
sense,
and
you
don't
read
it,
you
tell
it.
G
Right
and
then
I
like
to
extend
that
to
you
know
if
there's
an
error
like
just
just
write
it
out,
it's
we're
producing
telemetry,
it's
sort
of
like
a
meta
description
of
what
happened
wrong,
for
example.
Don't
hand
it
back
to
the
caller.
It's
it's
going
to
interfere
with
their
programming,
just
a
philosophy.
Thank
you
for
letting
me
rant.
E
E
B
Yeah,
I
guess
it's
just
the
span
right,
like
that's
the
question,
because
I
feel
like
there's
going
to
be
additions
to
the
span,
and
I
don't
think
that,
like
having
wrapping
that
in
a
struct,
wouldn't
necessarily
change
our
versioning
policy
too
much,
because
the
sdk
api
is
going
to
have
that
same
guarantee
any
sdk
implementer
that
would
implement
the
sdk
api.
I
would
have
to
understand,
like
these
interfaces
are
not
traditionally
going
to
be
doing
that.
I
guess
it's
just
like.
B
Is
there
a
value
in
wrapping
or
interfaces
in
a
struct
for
the
end
user?
B
And
I
don't
know,
I
don't
think
that,
like
it's
gonna
be
a
comparable
struct,
it's
just
gonna,
be
a
bunch
of
you
know
likely
we
wouldn't
want
to
be
a
comparable
structure
like
it
would
be
helpful
to
use
that
in
testing.
I
don't
see
why
you
would
want
to
get
something
back
from
the
structs
like
we
don't
have
any
state
in
this
struct.
B
So
I
don't
like
based
on
josh's
statement
like
this,
is
like
a
one-way
direction,
and
that's
not
the
direction
that
this
you
know,
information
flows
so
yeah,
like
the
only
other
option.
I
think
that,
like
the
bias
would
be
useful
is
if
we
wanted
to
wrap
things
as
just
memory
optimization,
but
if
it's
backed
by
an
interface,
I
only
see
that
as
an
added
layer
which
can
only
be
you
know,
zero
or
more
bytes,
that
we'd
be
adding
rather
than
saving.
B
Yeah,
I
think
so
I
think
I'm
going
to
try
to
go
find
that
document
by
yana
the
medium
article
I
know
which
one
you're
talking
about
josh,
I'm
going
to
try
to
find
most
got
a
lot
of
great
ones
if
people
are
putting.
B
Yeah
I'll
try
to
do
that.
I
also
realize
that
we're
way
through
the
meeting
we
haven't
talked
a
lot
about
things.
So
maybe
we
can
kind
of
progress,
this
I'll
jump
back
into
sharing
here
these
two
prs.
The
one
thing
I
didn't
want
to
say
about
this
was
I
wanted
to
make
sure
we
have
a
clear
direction
going
forward
and
I
think
we've
come
to
a
little
bit
of
a
consensus
but
yeah.
Hopefully
we
can
get
some
movement
on
this.
I
think
I'm
going
to
be
a
little
bit
faster
and
looser.
B
Once
I
have
a
clear
understanding
of
where
we're
going,
which
sounds
like
we
do
so.
I'd
like
to
just
move
past
those
to
talk
with
eddie
and
garrett,
totally.
G
B
G
I'll
update
my
resource
pr
with
a
fix
for
the
thing
anthony
pointed
out.
B
Okay,
cool.
That
sounds
good
if
people
have
time
after
the
meeting
taking
a
quick
look
at
these
would
be
really
helpful
in
progressing
the
metrics
side
of
the
house
and
not
keeping
josh
and
quagmire
cool
eddie.
If
you're
on
the
call,
I
think
I
still
saw
you
yeah
yeah.
Okay,
we
want
to
jump
into
this.
I
Sure
yeah
this
one
should
be
pretty
quick,
so
no
worries.
Basically,
the
summary
is
basically
there's
like
a
version.
Go
file
currently
sitting
in
the
repo
for
open,
telemetry
go
and
it
basically
just
contains
one
function
version
that's
exported
and
it
just
gives
like
the
hard-coded
version
string
and
basically
the
question
is:
do
we
want
to
have
this
for
all
of
the
modules
or
just
keep
it
at
just
for
like
just
the
route
which
is
like
go.open.com
hotel
and
basically
the
I
keep
saying
basically
but
yeah
the
gist?
I
Is
we
want
to
know
for
the
releaser
application?
When
we
release
new,
like
module
versions,
will
we
want
to
like
search
the
entire
repo
for
different
version.go
files,
or
is
it
just
gonna
be
sitting
in
one
place
or
if
anyone
has
any
strong
or
weak
opinions
on
this
at
all.
B
Yeah,
so
I
take
a
look
at
this.
I
think
that
you
to
motivate
changing.
We
would
have
to
find
use
cases.
It
doesn't
seem
too
much
of
a.
I.
A
A
The
root
version
go
is
even
important
from
the
specification
point,
because
the
species,
the
semantic
convention
says
that
you
should
have
an
attribute
that
tells
what
is
the
sdk
version,
so
I
see
a
reason
to
have
it
on
the
top
like
in
the
top
module,
but
I
don't
I
have
I
have
before
this
meeting.
I
was
trying
to
look
at
the
specification
under
implementations
and
I
do
not
see
any
other
use
case
than
that
right
now.
E
Yeah,
well
even
for
that
use
case.
This
isn't
quite
right,
because
this
is
the
top-level
api
package
which
theoretically
could
be
versioned
separately
from
the
sdk.
We
don't
do
that
now,
but
we,
we
probably
ought
to
actually
have
a
version
in
the
sdk
package,
so.
E
Yeah,
that's
that's.
That's
also
part
of
what
prompted
this
discussion
with
eddie
and
I
the
other
day
was
that
mistakes
were
made.
E
Moving
on
the
thing
that
is
slightly
odd.
Is
that
there's
only
one
version,
even
though
we
have
multiple
versions
being
released,
so
the
metrics
modules
are
not
1.0.0
rc,
something
they're,
currently
0.22
and
there's
no
way
for
the
metrics
model
or
a
consumer,
the
metrics
module
to
say:
what's
the
version
of
the
metrics
api
or
sdk,
that's
currently
being
used.
E
B
B
No,
I
can't
really
think
of
a
reason.
I
definitely
know
what
you're
talking
about
robert
with,
like
the
sdk
needs
to
report
as
a
semantic
invention
attribute
the
sdk
version
that
it's
using,
which
seems
like
this
version.go
file,
should
just
get
moved
to
the
sdk
package.
B
E
A
I
remember
some
when
I
was
rewriting
this
this
kafka,
sarah,
my
shopify
in
instrumentation.
A
A
B
Yes,
I
think
it's
really
important
that
our
instrumentation
has
the
right
version,
but
I
hear
what
you're
saying,
like
maybe
the
sdk
having
a
version.
E
If
these
are
really
does,
this
does
need
to
be
exported
because
it's
used
by
at
least
the
sem
version
function,
I
think,
is-
is
used
by
all
of
the
instrumentation
when
creating
their
tracer
providers
or
creating
their
tracers.
So
that
needs
to
be
exported,
but
the
other
ones
it
doesn't
hurt.
I
don't
think
to
export
them,
but
I
don't
think
they,
strictly
speaking,
need
to
be
to
function.
B
Yeah,
I
agree
so
I
definitely
I
would
try
to
minimize
the
export
api
as
much
as
possible
is
the
other
side
of
that
I
probably
would
not
want
to
like
have
this
exported
if
we're
not
going
to
actually
have
use
cases
for
it
until
there
are
use
cases,
so
I
I'm
definitely
in
favor
of
taking
this
and
moving
it
so
that
the
version
that
goes
just
in
the
sdk.
B
I
think
the
problem
then
becomes
that,
like
once
it's
in
the
sdk,
there's
like
anthony,
is
kind
of
pointing
out,
there's
also
like
different
modules
here.
So
this
is
a
different
version
than
this.
If
I'm
not
mistaken,
yeah,
I
think
yeah.
This
has
its
own
goal,
mod,
so
yeah.
I
think
that
that's
also
kind
of
a
problem,
so
I
don't
know.
I
Sdk
version.gov,
but
I
think
it's
like
gone
now
or
I
don't
know
it
might
be
sitting
in
some
other
file.
A
And
maybe
other
question:
is
it
not
like
that
that,
for
example,
when
we
are,
for
example,
emitting
traces,
we
should
apply,
then
the
sdk
of
the
traces
apa
as
the
of
the
traces
module?
If
you
will
emit,
for
example,
some
attribute
to
the
metric,
then
we
should
add
the
version
of
the
matrix,
sdk,
etc.
A
E
Yeah
so
perhaps
at
sdk
trace
and
sdk
metric,
we
could
have
versions
and
then,
if
we
added
in
sdk
logs
like
we
have
have
one
per
signal,
I
think
that
seems
a
reasonable
granularity.
B
I
guess
I
can't
find
it
yeah.
I
think,
if
that's
all
good,
can
we
so?
Is
it
possible
for
anthony
or
robert
one
of
you
to
comment
that
decision
into
this
issue?
B
Sure
I'll
do
that?
Okay,
cool!
I
want
to
keep
this
going.
We
have
garrett,
still
left
nine
minutes
or
eight
minutes
in
15
seconds
so
eddie.
I
think
that
sounds
good.
We're
gonna
get
some
thomas
in
there
garrett.
If
you
want
to
go
ahead
and
jump
on,
we
can
talk
a
little
bit
about
yeah.
F
Yeah
mine
will
be
pretty
quick,
so
anthony's
been
helping
me
out
a
whole
bunch
recently
with
a
ton
of
pr
comments
and
stuff
like
that,
and
so
what
we've
ended
up
with
is
the
lambda
instrumentation
doesn't
rely
on
the
sdk
at
all,
so
you
have
to
you,
provide
it
your
own
traits
provider,
everything
like
that.
That
is
needed.
So
that's
really
good!
F
Then
what
we're
left
with
is
we
internally
want
to
have
those
configurations
preset
for
x-ray
somewhere
that
our
users
can
grab
them,
and
so
we
were
looking
at
where
we
would
put
those
this
yeah.
This
is
the
file.
That's
pretty
much
what
what
we
want
to
provide
to
users.
It's
not
that
important.
F
It
just
provides
various
options,
but
we
were
looking
at
where
we
can
put
that
and
all
the
other
languages
just
directly
use
the
they
use
all
this
stuff
just
directly
in
their
instrumentation,
whereas
we've
been
trying
to
move
it
out,
so
we
don't
rely
on
the
sdk,
and
so
we
were
wondering
if
we
could
follow
a
similar
pattern
to
the
tests
which
we've
done
where
it's
like
a
sub
sub
module
in
in
our
lambda
instrumentation
stuff.
F
So
it
won't
be
included
if
you
include
the
just
the
instrumentation,
but
it'll
be
nearby
easy
to
find
stuff.
Like
that,
I
don't
know
if
that
makes
a
lot
of
sense.
I
just
kind
of
threw
some
information
out
but
feel
free
to
ask
any
questions
about
what
I'm
saying.
F
So
that's
specific
to
using
x-ray
mm-hmm
as
your.
B
Ever
is
there
a
time
where
you're
gonna
be
on
aws,
lambda
and
you're,
not
gonna,
be
using
x-ray.
F
Yes,
so
if
you
are,
I
think
there
are
probably
people
in
on
this
call
that
are
doing
that
yeah.
So
if
you're
like
invoking
lambda
of
the
api
gateway
or
something
like
that,
you
can
pass
in
your
own,
your
own
trace
id
and
stuff,
and
so
you
would
want
to
keep
using
that
rather
than
x-rays,
information.
B
Okay,
yeah,
I
don't
have
a
good
enough
understanding
of
like
the
scope
of
how
vendor
specific
this
is.
I
definitely
am
I'm
getting
the
smell
of
that
and
I'm
worried
that
I
don't
want
to,
like
you
know,
have
show
preference
here
in
the
repo
I'm
guessing
anthony
kind
of.
Has
that
understanding
as
well?
So
I
don't
think
if
that's
happening
and
that's
kind
of
like
the
thing
I'm
getting
back,
but
I
haven't
looked
deep
enough
in.
That
is
the
only
comment
I
have.
E
What
this
does
is
provides
conveniences
for
setting
up
an
sdk
that
can
be
provided
to
that
lambda
instrumentation
via
its
options,
interface
that
utilizes
the
aws
recommended
defaults
for
I
want
to
use
lambda
with
x-ray,
so
whether
that's
aws
specific,
if
it's
lambda
specific,
I'm
not
entirely
sure,
I
think
we
would
be
fine
hosting
this
in
in
our
adot
repos.
If
the
consensus
is
that
it
doesn't
belong
here-
and
I
don't
want
to
put
my
thumb
too
heavily
on
the
scale
as
to
where
I
think
it
should
go
or
not,.
B
Yeah,
I
I
don't
work
at
a
cloud
provider.
I'd
love
to
have
somebody
from
google
say
like
this
is
too
much
or
too
little.
I
should
also
probably
look
a
little
bit
more
at
this
before
I
make
a
statement
on
it
because
I'm
pretty
ignorant
at
this
point,
I
guess,
is
all
I
can
say.
B
I
don't
see
anybody
on
the
call
from
google,
but
that's
the
only
ask
I
would
have
is
if
we
could
get
sign
off
from
another
cloud
provider,
but
I
I
don't
like,
like
you
saying
it
is
somewhat
specific
and
we
already
are
doing
kind
of
like
isolated
cloud
provider,
sections
of
the
contrib
repo.
So
I'm
not
I'm
not
directly
opposed
either.
Is
what
I'm
also
saying.
F
Yeah,
the
other
instrumentations
have
them
hard-coded
as
defaults.
We
want
to
not
do
that,
but
still
have
them
available.
So
we
think
it's
a
good
compromise
between
the
two
because,
like
some
of
the
other,
partly
a
mistake
on
our
end
but
net
and
python,
for
example,
don't
even
let
you
change
which,
like
propagator
and
stuff
you
have
so
we
were
misunderstanding:
how
how
it
all
how
lambda
worked
so
those
instrumentations
do
lock
you
in
and
stuff
like
that.
B
Okay,
I
think
I'm
it's
starting
to
the
click
a
little
bit
and
I
think,
based
on
what
you
just
said,
is
it
actually
is
providing
more
configurability
but
also
providing
some
same
defaults
to
a
vendor
specific.
You
know
propagator,
but
it's
not
locking
you
into
it.
That
seems.
B
Like
statements
that
I
like
to
hear-
and
I'm
sure
our
word
will
know
what
I'd
like
to
say,
I
was
ignorant
so
that
sounds
like
a
positive
direction.
Yeah
I
I
would
probably
I
would
just
probably
get
a
pr
up
once
I'm
guessing.
This
depends
on
the
lambda
instrumentation
stuff,
but
once
that
gets
done,
hopefully
we
can
get
some
more
collective
review
of
that,
I
think
would
be
helpful,
but
I
think
this
seems
like
a
approach
that
I
think
is
viable
for
review.
Specifically.
F
E
Maybe
we
can
crowdsource
that
naming
then
in
the
last
two
minutes
you
can
bring
up
that
pr.
We
can
find
the
name
that
stretches
about
half
the
screen
wide
you'll.
C
F
C
That
one,
that
one
so
event
to.
E
Text
map
carrier
converter-
basically,
what
it
is
is
lambda,
doesn't
really
receive
headers
the
the
way
a
normal
http
request
would
right:
it
receives
an
event
and
there
may
be
http
headers
buried
in
there.
We
need
something
that
can
take
that
event
and
give
you
a
text
map
carrier
that
we
can
use
into
a
propagator
for
other
things
like
for
x-ray
propagator.
It
actually
comes
out
of
the
environment
rather
than
out
of
the
event,
so
yeah
there's
this
method,
and
it's
got
this
unwieldy
name
or
this
type.
H
It's
a
good
question:
how
is
it
used?
Do
you
even
need
a
name
for
it.
E
E
So
yeah
there's
there's
an
option
that
that's
similarly
named,
which
this
type
could
be
not
exported
and
just
the
option.
But
then
the
option
would
need
a
name
as
well.
F
B
Like
something
better,
but
I
mean
the
first
thing
that
comes
to
mind-
is
having
a
suffix
of
funk.
I
think
that
also
like,
if
you're
gonna
go
in
that
direction,
whatever
the
production
like
whatever
that
produces
folks,
so
something
like
a
text
map
carrier
funk
it's
already
scoped
in
the
hotel,
lambda
instrumentation.
It's
scoped
to
know
that,
like
maybe
this
is
you
know,
you
know
that
you're
going
to
be
taking
an
event,
it
doesn't
look
like
this
is
a
type.
B
So
that's
a
problem,
so
maybe
you
do
need
to
have
something
defining
it.
I
think
you
could
try
to
do
tmc
to
shorten
that
you
could
leave
it.
As
is
honestly
it's
I
don't
know.
It
doesn't
seem
too
offensive
to
me
if,
like
you're
digging
into
it-
but
maybe
that's
just
me-.
E
Yeah
I
if,
if
there
are
really
no
better
names,
then
it
is
what
it
is,
but
it's
just
the
sort
of
thing
that
stuck
out
to
me
is
wow.
That's
that's
a
mouthful,
but
I
think
we've
run
up
against
time.
Maybe
as
people
review
this
pr,
if
you
think
about
this
and
something
else
pops
into
your
head,
you
can
comment
with
a
suggestion.
B
Yeah,
I
think
if
that
sounds
good,
okay,
cool
yeah
as
we're
over
time.
I
think
we'll
send
it
here
thanks
everyone
for
joining,
we'll
see
you
all
next
week
or
virtually
and
yeah
thanks
for
joining
good
thanks.