►
From YouTube: 2021-04-06 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
B
The
office
is
open,
it
is
it's
it's
about
room
for
2,
000
people
and
there's
probably
five
people
here.
So
it's
a
little
weird
but
yeah.
My
wife.
C
B
Oh
yeah,
I
just
I
come
in
when
my
wife
has
conference,
calls
and
stuff
makes
it
easier.
A
Gotcha,
I
didn't
know
that
new
york
had
lifted
restrictions
for
going
to
the
office.
B
I
don't
know
if
there
really
ever
was
yeah.
I
don't
know
the
the
it's.
This
whole
funky
policy
with
got
this
really
cool,
app
called
envoy,
and
we
gotta
like
fill
out
a
form,
every
permission
slips
and
all
sorts
of
things.
B
So
it's
good.
I
don't,
I
think
they've
maybe
had
to
shut
down
a
few
times
over
the.
However
many,
but
it's
it's
always
been
some
skeleton
crew
anyway,
how's
everyone
else
doing.
D
E
E
F
Yeah,
no,
that
that's
an
awesome
area.
I
lived
there
for
many
years.
I
lived
in.
I
lived
in
lakeview
lakeville
lake
lakeview,
wrigleyville
bridgeport
was
there
for
10
years
and
probably
moved.
D
D
C
And
I
forgot
that
hello,
yes,
I
I
am
here
from
new
relic.
I
actually
started
last
monday,
so
so
this
was
on
my
calendar,
so
I'm
here.
F
Awesome
welcome
happy
to
have
you
if
you
have
any
questions,
feel
free
to
ask
us.
Okay,
thank
you
cool.
I
won't.
I
will
go
ahead
and
get
a
screen
shared.
F
All
right,
so
we
have
our
agenda
doc.
If
anybody
has
burning
questions
anything,
they
would
like
to
get
to
feel
free
to
fill
this
out.
In
absence
of
anything
immediately
burning,
we
can
go
through
the
spec
sig,
which
is
actually
really
quick
and
then
kind
of
move
on
to
move
on
to
things
related
to
our
repo.
F
F
F
F
Well
now
the
stock
is
looking
different
than
I
did
this
morning,
so
I
think
there
we
go
it's
because
it
is
another
agenda.
Is
the
agenda
for
the
data
model?
Sig?
I
don't
know.
Are
they
sharing
this
document,
I'm
not
really
sure
whatever
happened.
This
was
the
meeting
that
I
was
at
and
this
was
the
agenda
which
was
short,
so
we
will.
F
We
will
go
through
that.
Not
this
other
miscellaneous
future
meeting
that
I
have
no
clue
what
it
is.
So
I
think
everyone's
really
working
hard
at
their
rc's
and
there
hasn't
been
a
whole
ton
of
new
stuff
they've,
just
been
kind
of
completing
the
stuff.
That's
been
out
there,
although
there
are
a
few
pr's
that
have
showed
shown
up,
one
is
relevant
to
us
and
was
opened
by
a
contributor
to
this
project.
Johnny
johnny
shields
open
to
this
semantic
conventions.
Pr
for
background
jobs.
F
I
saw
that
a
few
yeah
a
few
people
were
mentioned
here.
I
don't
know
if
francis
or
anybody.
F
Or
mention
by
name
or
know
about
this
or
care
about
this,
but
it
it's
here
yeah
I've
provided
feedback
on
this
excellent
cool.
So
if,
if
you
care
about
the
background
job
semantic
conventions
and
haven't
seen
this
take
a
look.
F
G
I
don't
know
what
dragonfly
is.
Dragonfly
is
another
bsd
based
operating
system,
so
they
just
wanted
to
rename
the
dragonfly
bst
to
just
dragonfly
got
it.
F
All
right,
so
the
other
thing
is
there
is
there's
just
a
discussion
around
the
inconsistency
of
configuring,
a
secure,
otop
connection
between
languages.
F
The
spec
is
pretty
clear
about
this
and
it
says
you
should
use
a
schemed
endpoint
and
the
scheme
of
the
endpoint
will
determine
the
whether
or
not
the
connection
is
secure.
F
Apparently
not
all
languages
are
abiding
by
this
and
I
think
that's
the
core
issue.
There
was
a
little
bit
of
discussion
about,
like
should
be
grpc
or
grpcs
format.
I'll
admit
that
I
was
the
one
or
I
was
involved
in
the
pr
that
changed
this
to
be
schemed
and
grpc.
Proponents
said
http
is
fine
and
is
commonly
used.
So
go
with
that
when
I
did
some
look
or
I
did
some
looking
into
like
the
grpc
landscape
and
what
is
actually
there
for
schemes.
I've
turned
up
some
document
and
it
was
not.
F
It
was
definitely
not
grpc
or
grpcs
colon
slash
slash,
it
was.
It
was
something
else.
F
And
it
was
also
not
standard
between
all
the
languages,
so
I
think,
given
all
of
the
possible
options
and
the
fact
that
spec
is
technically
frozen,
that
http
and
https
are
aren't
good
enough.
D
I
mean,
I
think,
that
commenter
you
just
had
up
there,
alan
provided
mostly
what
I
would
say,
which
is
grpc
is
often,
I
would
say,
even
frequently
done
over
http
2.,
so
http
feels
fine
to
me.
Of
course
you
can't
do
it
other
ways
like
says,
but
I
think
http
is
fairly
common.
D
I
think
to
me
the
inconsistency
between
languages
is
something
that
I
have
run
into
and
that
I
find
incredibly
annoying.
So
that
is
a
very
valid
thing
to
work
on,
but
also
that's
not
a
spec
problem.
So
that's
I
mean
I
think,
we're
doing.
F
Cool
thumbs
up
that
was
generally
the
the
feedback
and
discussions
that
we
had
on
the
pr's
that
kind
of
set
out
this
standard,
but
yeah.
I
totally
agree
that
it's
frustrating
and
confusing
when
languages
are
doing
things
slightly.
Different
javascript
is
one
of
the
the
the
culprits
here,
which
I
also
am
somewhat
involved
in
so
shame
on
me,
but
I
don't
know
everything
that's
happening
everywhere,
so
we
will
at
least
get
things
fixed
anyhow,
so
that
was
it
really.
That
was
the
spec
sig.
F
There
is
not
an
immediate.
Is
this
what
it
is
yeah
this?
This
is
the
project
for
anybody
interested,
and
I
I
think
I
did
see
that
there
is
some
interest
in
in
metrics,
perhaps
coming
coming
from
github
interest
in
metrics
and
logs
a
little
bit
more
on
the
logging
side.
But
this
is
the
board
of
stuff
that
was
that
is
in
progress.
There
is
there
are
kind
of
like
two
projects
going
on
side
by
side
right
now.
F
One
is
kind
of
like
the
data
model
group
and
one
is
the
api
group.
The
data
model
is
kind
of.
If
anything,
that's
the
one
that
they're
trying
to
get
wrapped
up
sooner,
because
it
has
a
potential
to
be
a
bit
of
a
blocker
on
the
api.
But
there
is
some
stuff
that
they're
able
to
do
in
tandem
and
the
things
that.
F
Yeah,
the
things
that
stuck
out
to
me
is
that
the
they
mentioned
again
that
labels
and
metrics
are
going
to
be
renamed
attributes
and
they
will
be
compatible
so
like.
If
you
have
attributes
that
you're
sticking
on
a
span,
you
can
use
that
exact
same
collection
of
attributes
and
put
it
on
a
metric,
which
is
not
the
state
of
the
world
today,
and
the
other
thing
that
was
interesting
is
that
they
were
talking
about.
F
They
have
been
refactoring
kind
of
the
protos
and
we're
doing
some
proof
testing
there
and
some
of
the
stuff
that
they
did
might
not
be
okay,
but
they
will
figure
that
out
so.
F
So
tldr
there's
the
metrics
project
going
on.
There
is
this
board
for
all
of
the
things
that
are
being
worked
on.
D
Do
you,
I
haven't,
looked
actually
at
their
boards
recently,
so
I
apologize
for
not
doing
my
homework,
but
do
you
know
just
generally
like
how
close
are
they
to
stabilize
things?
I
know
that
they're
starting
to
be
support
in
some
of
the
sdks,
so
just
curious.
If
you
knew
before
I
started
trying
to
dive
into
all
the
documents.
F
So
yeah
to
try
to
summarize
this
without
going
on
too
much
of
a
tangent,
I
think,
like.
F
The
metrics
project
has
been
going
on
for
a
while,
and
I
think
the
original
plan
was
to
release
open
telemetry
like
1.0
with
metrics
and
trace
tracing.
F
As
the
timeline
has
kind
of
played
out,
it
became
clear
that
we
might
be
doing
ourselves
a
favor
to
try
to
like
release
on
like
a
per
signal
basis,
so
there
was
kind
of
like
this
drive
to
be
like
okay,
let's
focus
on
tracing,
let's
get
tracing
out
the
door
and
then
we'll
kind
of
do
my
tricks.
But
during
that
time
different
sigs
have
implemented
different
versions
of
the
metric
spec.
F
F
Driver,
I
guess,
of
of
the
metrics
project,
so
of
any
of
them.
That
would
have
been
like
the
most
current,
but
I
think
the
rest
of
the
languages
were
in
varying
degrees
or
yeah
in
varying
varying
states,
from
being
like
a
fairly
old
version
of
the
spec
that
was
usable
to
one
of
the
more
recent
ones.
So.
G
Yeah
there
is
a
requirement
that
the
metrics
api
be
developed
in
a
separate
package
from
some
separate
gem,
in
our
case
from
the
1.0
of
open
telemetry,
and
it's
considered
an
unstable
signal
at
the
moment.
So
yeah
anything
you
implement.
There
is
not
going
to
be
part
of
the
1.0
release
and
is
necessarily
assumed
that,
like
it's
going
to
be
changing
a
bit.
F
Yeah,
so
I
know
there
were
some
dates
thrown
out.
I
don't
know,
maybe
a
month
or
two
ago,
for
this
data
model
sig
and
the
api.
F
F
I
thought
that
the
data
model
work
was
supposed
to
wind
down
at
the
end
of
march,
maybe
so,
and
that
I
felt
like
there
was
some
kind
of
milestone
in
the
api
that
was
like
early
summer.
That
was
like.
We
should
have
like
the
core
concepts
locked
in,
but
wiggle
room
until
fall.
F
G
The
spectator
model
currently
says
it's
targeting
30th
of
april.
D
Okay,
that
makes
sense,
so
I
guess
a
related
question
is
well
while
obviously,
some
aspects
of
it
are
still
in
flight
and
they're,
not
completely
shored
up.
Do
we
feel,
like
the
general
aspects
of
like
what
a
meter
is
and
what
the
counters
are
like.
Some
of
the
core
concepts
are
stable
enough.
Well,
the
reason
I
ask
is
you
mentioned:
github
has
interest
in
both
metrics
and
logs.
D
I
apologize
if
it
just
got
really
windy,
but
you
know
we're
gonna
have
to
do
some
work
internally
to
try
and
unify
some
of
this
stuff
even
before
the
stuff
starts
solidifying.
So
I'm
honestly
just
curious
if
you
think
some
of
the
core
components
are
close
enough
to
stable,
that
we
can
look
at
them,
not
a
bad
idea
to
start
tracking
them
at
least.
G
I
think
the
the
marketing
claim
right
now
was
that
language
sigs
should
get
involved
in
metrics
if
you
want
to
help
define
the
spec,
but
not
if
you're,
just
looking
to
implement
the
spec
once
it's
done
and
looking
at
some
of
the
dates
they're
actually
a
little
further
out
than
was
originally
discussed.
G
So
the
feature
freeze
for
the
metrics
api
is
30th
of
september
and
the
stable
release
is
30th
of
november.
So
still
a.
D
G
For
logs,
my
understanding
is
that
they're
not
defining
kind
of
user-facing
apis
for
logging
right
now,
they're
focusing
more
on
the
log
collection,
format
and
kind
of
the
infrastructure
pieces
and
how
that
might
plug
into
an
existing
logging.
Api.
D
Yeah
that
that
whole
specification
suddenly
moved
a
little
bit
and
I
wasn't
expecting
them
to
be
like
oh
look,
there's
a
draft
that
was
that
was
really
exciting
to
see
we.
We
had
started
working
on
implementing
the
at
least
the
log
format
internally
to
follow
the
open
telemetry
specifications,
so
we
might
be
able
to
start
doing
a
little
bit
of
that
work
in
the
open,
contributing
something
generally
that
could
be
used
for
ruby.
D
F
I
think
this
is
all
good
stuff
to
talk
about.
I
guess
in
the
meantime,
while
they're
making
progress
on
metrics,
I
think
there
are
like
these
improvement
areas
for
tracing,
or
at
least
that
are
adjacent
to
tracing
such
as
I
think,
instrumentation
is
the
just
a
big
one
and
convenience
apis.
F
There's
some
diagnostic
stuff.
I
feel
like
there's
a
fourth
one,
that
I'm
forgetting,
but
it's
probably
there
simplifying
the
installation
experience
there
we
go
so
so
we
probably
have
a
decent
amount
of
work
cut
out
there.
I
think
when
we
do
start
getting
around
to
metrics
or
when
stuff
is
kind
of
looking
like
it's
calmed
down
over
there
a
little
bit.
F
I
do
think
like.
I
do
think.
F
The
concept
of
meter
meter
provider
is
probably
pretty
pretty
it's
going
to
probably
survive
this
revision,
and
then
I
think,
like
your
metric
instruments,
you're
probably
going
to
have
synchronous
instruments
and
asynchronous
instruments,
and
if
it
were
me
trying
to
get
something
off
the
ground,
I
would
try
to
kind
of
like
build,
build
a
pipeline
from
like
collection
to
export
for,
like
a
synchronous
instrument
first
and
then
add
a
an
asynchronous
instrument
and
then
table
it
until
things
had
like
just
kind
of
solidified
and
come
back
to
it
and
kind
of
see
what
has
changed
and
if
not
a
whole
lot
has
changed,
then
you
can
kind
of
go
through
it
and
I
feel
like
once
once
you
get
those
things
figured
out.
F
I
guess
from
from
complexion
to
export,
then
it
shouldn't
be
all
that
bad
to
add
more
in.
But
that's
like
my
back
of
the
napkin
way
that
that
I
would
probably
approach
that
when
the
time
comes-
and
the
time
is
probably
not
now
right.
F
F
Yeah
should
we
move
on
to
our
repo.
I
know
I
was
taking
a
look
yesterday.
Well,
a
quick
look
yesterday
and
our
milestone
has
been
completed.
Yay
yeah.
G
I
don't
know
if
that
means
that
we're
ready
for
anything,
but
we're
we're
just
about
ready.
I
think
I
had
asked
in
slack
for
people
who
open
issues
basically
take
a
look
through
it.
If
there's
any
last
minute
things
that
you
think
need
to
be
tackled
before
we
do
an
rc,
then
certainly
open
issues
for
those
or
open
prs.
If
you've
got
solution
solution,
it
would
be
useful
if
people
can
read
the
implementation
both
from
a
consistency
perspective.
G
So
just
is
it
internally
consistent
and
then
look
at
it
with
the
spec.
Alongside
to
see
you
know,
are
we
actually
implementing
the
spec
correctly
and
open
issues
for
anything
that
you
see?
So
it's
really
a
good
time
right
now
to
call
out
problems
so
that
we
can
address
them
before
the
rc.
But
failing
that
I
think,
maybe
later
this
week
we
can
consider
cutting
a
release
candidate,
I'm
open
to
suggestions
about
what
that
actually
looks
like
from
a
versioning
perspective.
D
G
Yeah
so
generally
things
like
examples
and
documentation
can
wait
till
after
the
rc
they
can
be.
You
know,
kind
of
fit
and
finish
polishing
that
we
can
do
before
ga
for
the
rc
I'm
looking
for
is
the
api
generally
internally
consistent
is
the
api
consistent
with
the
spec.
That's
always
useful
there.
I
think,
there's
one
more
thing
that
robert
is
working
on
possibly
two
things.
I
can't
remember
offhand.
G
You
so
the
two
things
that
I
remember,
or
at
least
one
of
them,
is
extracting
instrumentation
base
from
the
api
gem
and
sticking
it
somewhere
else.
So
he
has
robert
has
a
work
in
progress.
Pr
for
that.
The
other
one
was
the
issue
about
dealing.
G
It
was
the
issue
we
discussed
last
week
so
dealing
with
getting
a
tracer,
an
api
tracer
in
your
hand,
before
the
sdk
is
actually
being
installed
and
initialized
and
then
being
unable
to
create
sdk
spam,
subsequently
so
effectively,
upgrading
an
api
tracer
to
an
sdk
tracing.
E
E
So
if
anyone
wants
to
take
a
look
at
that
the
code
is
there
so
like
those
last
two
things
I
need
to
finish
before,
I
take
out
a
draft,
but
if
anybody
wants
to
review
right
now,
I
think
the
like
substantial
changes
are
in
and
then
yeah
the
other
part
of
allowing
api
tracer
to
upgrade
when
the
sdk
is
installed.
I
francis
I
talked
about
a
few
different
approaches.
I
don't
think
we
really
settled
on
one
yet
I
don't
know
like
should
that
be
in
before
the
rc.
G
Yeah,
it's
a
good
question.
I
we
definitely
want
it
before
ga.
We
want
to
encourage
people
who
are
using
this
in
first
party
instrumentation
to
be
able
to
just
like
ask
for
a
tracer
at
any
point
in
the
initialization
of
their
gym
and
have
that
work
once
everything
is
up
and
running.
G
E
Yeah,
okay,
yeah,
so
the
the
base
is
almost
out.
I
do
need
to
spend
some
time
on
the
other
part
there,
but
the
approach
I've
taken
with
instrumentation
base
is
just
extracted
into
its
own
gem,
so
it's
just
instrumentation
optometry
instrumentation
phase
and
that
becomes
a
dependency
of
our
auto
instrumented
gems,
as
well
as
the
sdk,
so
that
it
has
access
to
the
registry.
F
Yeah,
I
can
take
a
look
over
this
as
well.
D
Were
there
any
issues
or
docs
about
the
different
approaches
for
upgrading
a
tracer
after
sdk
initialization?
I
don't
want
to
derail
the
meeting
with
rehashing
a
discussion,
but
I
was
curious,
so
I
could
read
about
it
anywhere.
G
We
haven't,
we
haven't
written
anything
down
yet
it's
basically.
If
you
look
at
the
meeting
notes
from
last
week's
meeting,
that's
about
the
extent
of
it
right
now.
I
know
robert
and
I
have
discussed
some
complications
in
that
subsequently,
but
I
don't
think
we
wrote
anything
down.
F
There
yeah,
I
can
at
least
mention
that
the
javascript
implementation
has
like
a
proxy
tracer,
and
that
is
one
approach
that
I
have
seen
in.
F
I
think
javascript
and
go
have
a
pretty
compatible
approach
there.
So
when
we
were
talking
about
it,
last
though
it
did
sound
like
francis
and
robert
might
have
some
something
else
in
mind,
at
least
a
variation
of
it,
although
I'm
not
totally
sure
yeah.
G
I
think
we're
more
concerned
with
what
are
the
actual
constraints
on
the
problem.
I
think
we
can
make
the
assumption
that
you
know
you
may
have
the
api
tracer
provider
plugged
in
for
a
while
as
a
global
tracer
provider
and
then
subsequently
the
sdk
tracer
provider
is
plugged
in,
but
you're,
probably
not
going
to
replace
the
global
tracer
provider
subsequently,
so
that
that's
likely
an
assumption
we
can
make.
There
is
additional
complexity
around
what,
if
you
create
a
tracer
provider
that
is
not
the
global
tracer
provider,
you
ask
it
for
a
tracer.
G
Should
its
tracer
instances
also
be
upgraded
when
you
plug
in
the
global
tracer
provider
or
plug
in
the
sdk
tracer
provider.
So
that
was
the
other
complexity
that
you
might
need
to
deal
with,
because
there
is
this
stuff
in
the
spec
around
having
or
being
able
to
support
multiple
tracer
providers.
G
You
know-
maybe
it's
enough
just
to
know
whether
a
tracer
provider
or
have
a
tracer
provider
be
aware
of
whether
it's
the
global
tracer
provider,
when
it
is
asked
for
a
tracer
so
that
it
returns
something
that
is
upgradable
at
that
point,
and
if
it
is
not
the
global
tracer
provider,
then
it
can
return,
something
that
is
not
upgradable.
F
Yeah,
I'm
not
sure
what
the
official
guidance
is
there,
but
I
would
say
if
it
works
for
the
global
tracer
provider,
it's
probably
sufficient.
I
feel
like
as
soon
as
you
as
soon
as
you
are
managing
your
own
tracer
provider.
It
seems
reasonable
that
that
the
ball
is
in
your
court.
I
guess
when
it
comes
to
making
sure
that
you
are
getting
an
operational
transmission
when
you
need
it
and
yeah.
G
Yeah,
so
perhaps
the
solution
is
that,
in
addition
to
the
kind
of
no-op
tracer
provider
that
we
get
by
default,
you,
the
api
also
has
a
global
tracer
provider.
That
is
the
default
one
and
ends
up
creating
these.
You
know
proxy
traces
or
whatever
you
want
to
call
them.
G
The
trick
is
that
we
need
to.
If
we
end
up
delegating
spam
creation
to
the
tracer
provider,
then
we
need
to
track
the
instrumentation
library,
that's
kind
of
required
by
the
spec,
but
that's
in
the
sdk
spec
and
then
the
other
thing
is
that
we
need
to
document
this
new
part
of
the
api
like
span
creation
happening
on
the
tracer
provider
needs
to
be
documented
because
anybody
who
creates
their
own
sdk
so
their
own
tracer
provider.
G
F
Yeah,
I
think
if,
if
we
start
running
into
some
questions
on
this,
then
I
would
say
that
we
can
consult
some
of
the
other
implementations
go
javascript,
and
actually
I
want
to
say
java
also
has
that
that
I'm
aware
of
so
we
kind
of
have
at
least
three
different
implementations
that
that
we
could
take
a
look
at
and
if
we're,
if
we
need
to
kind
of
like
once,
we
have
ours
in
our
in
review
phase.
F
If
you
wanted
to
like,
have
one
person
pick
pick
one
language
and
compare
we
could
we
can
do
that
too?.
G
Yeah,
I
may
be
unnecessarily
worried
about
efficiency
concerns
here,
because
you're
going
to
have
an
extra
level
of
indirection
and
possibly
some
dynamic
checks
about
you
know,
has
a
global
tracer
provider
changed.
So
that
was
one
of
the
things
I
was
worried
about
as
an
old
small
talker.
I
would
be
really
happy
if
ruby
provided
become,
but
that
is
sadly
missing.
F
G
Yeah
become
allows
you
to
effectively
atomically
swap
two
objects,
so
all
references
to
one
object
become
references
to
the
second
object.
F
F
I'm
like
this
really
sucks
when
you
have
to
return
like
a
proxy
tracer
because,
like
while
it
is
just
like
delegating
to
to
a
tracer
implementation,
either
the
no
op
or
the
operational
one
like
it
was
unfortunate
to
have
to
do
that
and
if
I
remember
like,
as
long
like
in
the
real
world,
you
probably
have
a
a
small
subset
of
your
tracers
that
actually
end
up
that
you
have
to
return
a
proxy
for
as
soon
as
the
global
or
as
soon
as
an
operational
tracer
provider
is
installed.
F
So
I
took
some
comfort
in
that
and
just
told
myself,
if
you
were
experiencing
some
problems
because
you
were
getting
a
tracer
too
early,
you
could
probably
work
around
that.
But
I
don't
know
whether
whether
or
not
that's.
F
G
So
I've
just
added
robert's
pr
to
the
milestone.
We
should
create
an
issue
for
the
upgradable
tracer
thing
and
add
that
to
the
milestone
as
well.
F
Yeah
that
sounds
good
and
we
can
kind
of
just
like
track
track.
What
we
want
to
do
there
and
any
open
questions
that
we
have
and
then
we
can
go
splunking
other
implementations
to
try
to
answer
some
of
the
open
questions.
If
that
is
helpful,.
F
Like
I
fear,
this
thing
is
probably
riddled
with
typos,
but
I
didn't
find
any
in
my
last
glance
over
it
so
yeah.
This
is
one
thing,
that's
kind
of
been
on
my
mind.
A
little
bit
is
we
have
this
tracer
in
span
and
actually
tracer
with
span
probably
also
deserves
a
mention
here,
but
these
are
kind
of
these
are
two
api
methods
that
we've
added
to
open,
telemetry,
ruby.
We
actually
use
them
a
lot
and
they're
not
spec'd
and.
F
Just
for
a
little
bit
of
backstory,
like
back
in
the
beginning,
when
we
added
these
api
methods,
context
was
there
was
fan
context
and
you
would
store
that
separately
in
in
some
opaque
fashion,
and
then
there
was
kind
of
baggage
context
as
well,
and
you
kind
of
manage
that
separately
so
like
if
you
were,
if
you're
receiving
http
requests.
What
that
ended
up.
F
Looking
like
in
practice
was
you
actually
had
to
extract
context
like
twice
you
had
to
like
extract,
you
had
to
use
a
propagator
for
for
your
span,
context
extract
that
out,
and
then
you
would
also
use
a
another
propagator
for
baggage,
extract
that
and
make
sure
that
you
did
everything
properly
at
the
inject
and
extract
points,
and
that
was
kind
of
seen
to
be
non-ideal.
F
So
there
was
kind
of
this.
It
was
kind
of
one
of
these
things
that
we
decided
to
squeeze
in.
That
was
going
to
be
simple,
but
it
really
changed
everything
for
the
better.
I
think
and
was
a
good
idea,
but
it's
one
of
the
reasons
why
we're
1.0
is
probably
today
is
that
we
kind
of
did
this
whole
big
thing
where
we
like
unified
context
as
like
this
top
level
concept
and
right
now
you
know
it's.
F
This
is
where
the
current
span
or
span
contacts
is
stored,
as
well
as
baggage
contacts,
it's
kind
of
like
an
open
door
for
more
stuff
to
end
up
there,
but
basically,
whatever
state
you
have
in
one
application
that
you
need
to
get
over
into
the
other
application.
F
Potentially
this
is
this,
is
the
avenue
to
do
it
and
any
any
sort
of
custom,
injector
or
extractor
would
be
a
way
to
get
stuff
across
the
wire.
So
that
was
just
kind
of
background
here,
because
now
we
have
like
these.
F
We
have
these
methods
that
are
kind
of
like
tracing
specific,
but
they
take
like
some
context,
arguments
and
I
think
that's
where
stuff
starts
to
get
like
fuzzy
like
it
was
when
inspan
used
to
have
a
parent
option,
it
was
like
a
parent
span
or
a
parent
span
context,
and
it
wasn't
ambiguous
what
you
were
interested
in
now.
F
F
You
just
pass
in
an
argument
like
a
name
you
and
you
use
the
implicit
context
and
I've
kind
of
said,
the
implicit
context.
This
is
the
current
context.
There
is
a
span
in
there.
It's
name
is
span
a
and
there's
some
baggage
k1
with
a
value
of
fu.
F
F
When
you
use
an
explicit
context,
so
I'm
talking
about
like
this
kind
of
usage
here,
where
you
pass
in
with
parent.
In
this
case
we
kind
of
have
this
same
implicit
context.
This
is
the
current
context,
context.current,
if
you
are
calling
this
in
code,
but
you
have
a
handle
on
this
other
context
called
ctx
and
they
both
have
a
different
current
span
and
they
have
different
baggage.
F
So
the
way
things
are
currently
set
up,
we
will
basically
create
a
new
context
that
is
derived
off
of
the
current
context
of
this
one,
but
replace
the
current
span
with
the
span
from
ctx.
So
you
end
up
with
this
kind
of
like
combination
of
the
explicit
context
and
the
implicit
context
which
I
feel
like
this
is
a
little
bit
surprising.
It
has
surprised
me
more
than
once,
and
I
think
it
has
surprised
I've
linked.
F
You
know
a
couple
of
our
instrumentation
and
then
there's
also
a
couple
of
issues
where
it
has
also
surprised
so
like
it
seems
like
this
has
surprised
more
than
one
person
more
than
once,
and
I
guess
it's
a
question
as
to.
F
Context
feel
like
that
makes
this
api
method
a
little
bit
less
surprising
to
me,
but
I
do
have
this
like
slightly
uneasy
feeling
that
we're
over
in
tracerland
we're
just
dealing
with
tracer
and
inspan,
yet
we're
kind
of
like
manipulating
context
outside
of
our
kind
of
domain.
If
that
makes
any
sense.
G
Yeah,
the
the
issue
is
that
you're
working
with
a
tracer
you're
just
talking
about
spans,
but
suddenly
you're
you're,
hiding
your
implicit
context
and
making
the
new
implicit
context.
This
explicit
context
that
you
passed
in
so
you're
kind
of
combining
these
two
things,
and
it's
not
obvious
that
that's
what
you
should
be
doing.
G
F
F
Secondly,
like
there
is
there
is
this
like
convenience,
api
group,
and
I
should
probably
drop
a
link
to
this
in
there
and
get
some
feedback.
Perhaps
actually
I
will
ask
the
group
if
I
should
do
that,
because
we
should
only
do
that
if
we
want
their
feedback,
but
I
think
we
should
do
that.
Okay,
all
right,
great
yeah.
It's
always
it's
a
double.
It's
a
double-edged
sword
most
times,
but
usually
the
conversations
are
healthy
that
end
up
coming
out
of
that,
but
yeah.
F
I
think
we
are
going
to
probably
define
a
set
of
convenience
methods
that
will
be
adopted
across
open
telemetry
so
like
it
would
be
slightly
unfortunate
if
we
define
like
an
in-span
like
method
that
has
like
a
slightly
different
behavior
and
we're
kind
of
stuck
with
ours
so
like
that
is
not
awesome.
It's
just
something
to
keep
in
mind,
but
at
the
same
so
yeah,
so
I
I
have
laid
off
some
options.
F
D
I
I
have
to
say
I
like
the
in
span
api.
It's
it's
incredibly
ergonomic
and
I
know
it
cuts
across
different
domains,
which
is
somewhat
frustrating
when
we're
authoring
a
library
but
like
as
a
user
of
it,
it's
very
nice.
It
did
surprise
me.
I
actually
did
not
know
until
just
now
that
the
context
manipulation
worked
as
it
did.
D
I
thought
it
worked
as
the
alternate
method
implies
that
if
you
pass
into
context
it
just
uses
that
context
for
everything,
including
the
parents,
like,
I
thought,
that's
what
it
meant
personally,
so
I
am
personally
in
favor
of
adopting
the
alternative,
behavior
and
fixing
and
usage
that
we
need
to
fix
with
parent
option.
I
don't
know
about
the
controversy.
I
personally
think
it's
okay,
but
you
know
controversy
is
a
thing.
Yeah.
G
I
was
just
going
to
say
the
issue
is
that
you
need
to
think
through
all
the
use
cases
for
this
in
span
and
consider.
Is
there
ever
a
use
case
where
somebody
has
set
some
context
that
they
expect
to
be
to
apply
to
everything
in
you
know,
for
the
duration
of
a
block
of
code
and
where
that
is
no
longer
applying?
G
If
you
pass
an
explicit
context
right,
basically,
your
explicit
context,
rather
than
being
merged
with
the
implicit
context,
it
actually
completely
overrides
it,
and
I
don't
know
if
there
are
any
use
cases
like
that.
I
just
feel
like.
We
need
to
consider
what
the
use
cases
are.
The
dominant
place
where
this
is
being
used
and
where
it's
become
problematic,
is
where
people
are
propagating
context.
G
F
I
was
gonna
say,
like
it
probably
extends
beyond
that,
once
you
start
using
baggage
in
process
and
you
are
progressively
modifying
the
baggage.
I
think
this
also
becomes
an
issue.
I
think
it's
something
that
hasn't
been
run
into
that
much
because
baggage
has
been
severely
underutilized.
F
A
No,
it
wasn't
so
much
a
question,
I'm
just
trying
to
figure
out
for
for
me,
it's
sort
of
like
what
do
we
define
as
idiomatic
code
for
folks
to
know
how
the
I
guess
not
be
surprised
by
the
code
right.
So
in
our
case,
we're
trying
to
use
baggage
to
store
some
values
for
backward
compatibility
with
some
of
our
legacy.
Telemetry
code
right
and.
A
Working
with
making
these
immutable
objects
and
having
to
change
them
and
then
set
the
current
implicit
context
so
that
something
can
be
used
downstream
and
the
only
way
to
do
that
achieve
that
really
was
with
current
safely.
I
should
say
achieve
it
safely
or
inconsistency
was
was
using
like
the
context
with
current
to
say
now,
I'm
setting
the
current
context
to
include
all
this
package
information
and
then
hope
that
somewhere
down
the
line,
somebody
doesn't
erase
that
that's.
A
What
I
was
I'm
struggling
with
a
little
bit
and
part
of
me
looks
at
other
examples
and,
let's
say
like
if
you
ever
used
mdc
contacts
for
logging
or
if
you've
used
semantic
logger-
and
you
add
log
contacts-
it's
in
a
sense,
less
complicated,
because
it's
keeping
these
values
around
for
that
black
scope
and
there
isn't
a
immutable
objects
that
you're
worrying
about
being
returned
from
those
values
when
you're
seating
them.
So
it
feels
a
little
more
comfortable
to
work
with.
G
I
guess
some
added
history
here
with
parent
used
to
take
a
span
context,
so
this
used
to
be.
G
About
spans
and
trace
context,
propagation,
it
didn't
take
a
general
context,
object
and
then,
when
we
morphed
it,
you
know
we
we
changed
it
to
take
a
general
context
because
span
context
wasn't
supposed
to
be
a
thing
that
is
widely
used.
G
It's
only
meant
to
be
used
by
the
propagators,
so
this
this
was
changed
to
do
that,
but
all
we
did
there
was
assume
that
the
with
parent
would
be
a
context
that
wrapped
a
span
and
a
span
context
that
it
wouldn't
necessarily
carry
any
other
context,
but
that
again
leaves
open
this
problem.
Where
you
know,
maybe
you
already
have
a
context
set,
and
you
want
that
you
want
to
use
that.
You
want
that
to
continue
to
be
part
of
your
context
within
this
block.
A
G
You
just
want
to
pick
up.
The
parents
span,
information
from
this
explicit
with
parent.
F
D
However,
I'm
gonna
say
like
maybe
we
actually
should
open
like
start
specking
out
what
we
think
it
should
do,
whether
or
not
it
stays
in
the
gem
or
moves
to
a
separate
gem
is
actually
I
hate
this
word
it's
orthogonal
to
how
it
behaves.
We
need
to
figure
that
out,
and
I,
like
I,
I
I
have
thoughts
on
it
but
like
actually,
I
kind
of
feel
like
I
need
to
sit
and
think
about
it
for
a
while.
You
can
very
really.
H
G
That's
exactly
it
was
purely
a
convenience
method.
It
actually
got
more
complicated
because
there
were
corner
cases
where
an
exception
could
be
raised
before
the
span
was
created,
and
so
we
need
to
deal
with
that.
We
need
to
deal
with
error
handling,
so
it
kind
of
got
inflated.
The
original
code
was
pretty
much
exactly
what's
written
in
the
ruby
dock.
H
H
H
Make
in
span
maybe
in
span
is
a
convenience
method
somewhere
and
to
to
andrew's
point.
Maybe
it's
maybe
it's
in
the
core
gym.
Maybe
it's
not,
but
if
it's
a
convenience
method,
let's
make
it
convenient
and
not
handle
all
of
these
edge
cases.
It's
just
for
the.
D
I
just
yeah,
I
think
that's
reasonable
and
and
if
we
outline
specifically
what
it
does,
then
people
who
are
authoring
more
complicated
things
can
look
at
the
docs
and
say:
oh,
this
isn't
going
to
do
what
I
want
it
to
do.
Let
me
see
how
it's
implemented
and
start
to
figure
out
how
to
do
it
on
the
run
right.
This
thing
is
not
going
to
expose.
G
Yeah,
so
you
know
the
middle
option
here:
removing
the
with
parent
option
kind
of
gets
rid
of
the
controversy,
because
you
don't
have
an
or
what
you
don't
have
a
way
to
explicitly
pass
context.
G
So
that's
that's,
certainly
one
option
and
then
the
other
option
is
like:
let's
move
it
out
into
a
separate
gem
that
is
explicitly
a
convenience
api
and
figure
out
what
we
can
do
and
just
document
it.
Clearly
there.
F
Yeah
and
maybe
a
combination
of
those
because
I
feel
like
that
was
one
of
the
discussions
going
on
with
the
convenience
api
group-
is
that
these
things
should
be
separate
from
the
core
api.
F
D
I
I
don't
know
that,
like
that,
that's
that
makes
sense,
especially
if
you
want
to
move
the
spec
and
the
convenience
apis
at
different
rates,
but
to
people
who
are
coming
to
the
project
and
trying
to
get
started.
If
the
nice
to
use
things
are
not
included
in
the
core
project,
it's
it
just
feels
like
an
additional
barrier
that
might
end
up
hurting.
H
More
than
it
helps
is
that
is
that
a
difference
between
including
it
in
the
api
and
including
it
in
the
sdk
so
like.
If
I'm
coming
out
the
telemetry,
I'm
going
to
pick
up
the.
G
Sdk,
it's
more
about
it's
more
just
a
versioning
and
stability
thing.
There
are
stability,
guarantees
that
come
with
version
1.0
of
either
the
api
or
the
sdk,
so
anything
that
we
decide
to
include
there
we're
going
to
be
supporting.
I
think
it's
for
you
know
three
years
or
something
is
the
guarantee
there.
F
Sense
right,
so
we
are
trying
to
come
up
on
time.
I
will
drop
this
in
the
convenience
api
slack
channel
for
further
discussion.
G
D
That's
a
great
question:
my
best
answer
is:
if
you
don't
see
a
button
for
it,
you
probably
can't
do
it.
I
would
would
the
buttons
be
in
this
general
area.
I
don't
know,
let
me
let
me
look
at
it
real
quick.
G
Yeah
so
let's
create
an
issue:
yeah
create
an
issue
referring
to
this
discussion
and
just
make
sure
that's
pinned
to
the
milestone
cool
yeah.
I
will
I.
F
Will
do
that
and
yeah,
so
we
we
are
at
a
time.
Is
there
anything
that
we
well?
I
feel
like.
We
didn't
fully
finish,
arielle's
suggestions
and
questions
around
the
context
and
baggage
api
usage.
F
So
I
would
I
guess
I
would
encourage
us
to
continue
this
conversation
on
the
github
discussion
and,
like
I
agree
like
the
ergonomics
here
are
not
great,
but
there
is
this
yeah
there.
There
is
a
requirement
from
the
spec
that
contexts
be
immutable.
A
Like
we,
this
is
a
a
problem
that
a
lot
of
other
libraries
face
as
well
right
where
it's
sort
of
like
saying
like
I
want
to
be
able
to
add
some
metadata
for
the
scope
of
this
block
that
is
going
to
be
shared
for,
let's
say,
logging
and
once
it
pops
all
that
data
should
be
gone
remaining.
The
data
that
was
included
outside
of
the
scope
of
that
block.
So
it's
just
so
I'll.
A
Take
a
look
at
some
of
those
other
examples
bringing
it
here
and
see
if
any
of
that
could
be
useful
to
us
and
into
this
project.
So.
F
G
Yeah
one
one
thought
here
is:
is
there
value
in
having
a
set
values
as
well
as
a
set
value
for
baggage,
so
something
that
allows
you
to
set
a
whole
bunch
of
values
simultaneously,
instead
of
being
forced
to
use
a
builder
interface.
F
F
All
right
yeah,
so
I
guess
we'll
get
a
few
more
issues
in
in
the
milestone
and
we
will
burn
that
down
yet
one
more
time
and
then
I
think
the
other
ask
was
just
to
look
through
what
we
have
make
sure
that
it
is
both
spec
compliant
and
be
like
internally
consistent.