►
From YouTube: 2020-09-15 Spec SIG
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
C
Hey
everybody
add
yourself
to
the
agenda
by
the
way
there
we
have
a
few
items
but
feel
free
to
add
more.
D
C
C
Okay,
let's
get
rolling,
thank
you
for
joining
and,
first
of
all,
a
second
apology
for
the
the
noise
that
you
will
be
listening
to.
Sadly,
in
my
flat
there
was
a
construction
going
on
and
it
has
been
incredibly
noisy,
so
I
apologize
I'm
working
for
a
coffee
shop
today,
but
anyway,
thank
you
for
coming.
C
Yes,
so
what
about?
Starting
with
andrew
and
the
usual
reporting.
D
Okay
sure
yep,
I
can
go
over
our
issue
status.
Let
me
just
move
these
gen
items
up.
D
Thing
this
section
here
is
just
pretty
much
what
we
discussed
at
the
maintainers
meeting.
We
did
a
scrubbing
of
issues
thanks
to
tigran,
carlos
and
armin
last
week,
in
order
to
reassess
some
of
the
p2p3
issues,
see
whether
something
can
be
moved
after
ga
and
just
to
set
the
context
we're
now
in
the
mode
of.
D
Taking
a
hard
look,
making
hard
decisions
at
what's
required,
what
is
necessary
functionality
in
order
to
implement
the
trace
spec?
So
that's
the
line,
that's
going
to
be
delineated.
P1
issues
represent
that
and
p2
and
p3
issues
if
they're
still
open.
When
all
the
p1
issues
are
closed,
then
that's
not
going
to
be
a
blocker
for
us
to
be
able
to
freeze
the
spec
for
for
trace.
In
other
words,
p2
p3
issues
can
be
additive
or
like
edit
changes,
wording,
changes
small
little
changes
that
can
follow
in
afterwards.
D
It's
not
going
to
materially
affect
the
implementation
of
the
languages.
So
with
that
lens
in
mind,
let
me
see
I'll
go
over
this
section
first,
which
is
how
many
issues
we
have
to
do.
Progress
done,
based
on
the
git
hub
project
for
jspec
burn
down.
We've
got
63
in
the
to
do,
which
is
down
a
lot
because
of
the
triage,
and
also
because
of
movement
of
people
working
on
things,
six
in
progress
and
66
done
so
now,
we've
like
turned
an
inflection
point.
D
D
Now
this
search
is
with
a
filter
of
all
p1
issues
that
don't
have
the
label
spec
metrics,
spec
metrics
will
be
taken
care
of
after
we
freeze
will
be
the
next
focus
of
concentration
after
we
freeze
the
trace,
spec
issues,
we
have
13
open
and,
let
me
see,
I
think
one
of
them
here
needs
to
be
assigned.
D
D
Spec
context,
spec
correlation
context,
they're
the
labels
that
are
in
this
filter
right
here,
because
they
related
they
relate
to
the
trace
api,
as,
as
I
understand
it,
going
through
this
with
carlos
okay.
E
D
So
this
everything
this
filter
that
represents
these
13
open
issues.
These
p1
issues
contain
mostly
spec
trace,
but
some
of
them
are
like
correlation
context
like
this
one
right
here,
but
they
all
are.
D
To
specify
the
functionality
needed
for
freezing
trace,
spec
yep
cool
thanks
that.
G
Makes
sense?
Okay,
this
fan
parentage
issue,
I
think,
does
affect
metrics
as
well.
I
think
it
affects
everything,
because
the
core
issue
here
is
whether
or
not
the
way
we're
doing
span
parentage
can
cause
spans
to
get
decoupled
from
the
rest
of
the
context
we
wanna.
G
I
think
this
is
like
a
really
important
last
minute
thing
that
we
just
want
to
make
sure
we
get
right.
I
said
this
the
maintainers
meeting,
but
I'll
say
it
again.
Here
we
want
to
make
sure
that
the
patterns
we're
giving
people
ensure
that
when
they
have
to
move
work
across
threads
or
otherwise
change
the
flow
of
execution,
they
don't
just
move
the
span.
They
move
the
entire
context,
because
it's
more
than
just
a
span
that
that
needs
to
get
schlepped
around.
C
C
D
D
Okay,
then,
so
that
that
pretty
much
explains
all
these
numbers
here
in
the
movements
since
last
week,
there's
a
double
check.
D
C
I
I
A
C
D
Sorry,
a
little
confused
should
I
leave
this
open
for
someone
to
answer
and
explain
the
difference
or
is
this
explain
the
difference
in
the
spec.
G
Well,
no,
it's
just
the
fact
that
they're
literally
different
types
that
we
have
multiple
types
for
essentially
the
same
concept,
one
restricted
to
string
and
the
other
one
not
just
creates
like
extra.
If
we
have
different
types,
if
they
are
different,
we
do
have
have
different
names
but
like
this
is
just
a
burden
on
people
trying
to
adopt
open,
telemetry,
there's
so
many
terms
flying
around
so
there's.
G
For
it
we
do,
but
this
is
just
putting
my
product
design
hat
on.
I
think
sometimes
I
see
this
project
get
pedantic
about
this
stuff
and
put
some
form
of
technicality
in
front
of
simplicity,
so
that
would
just
I
think
this
is
just
one
of
those
cases.
If
we
can't.
I
also
find
thinking
that
it's
too
late
to
to
unify
the
types,
but
I
do
think
it
would
it
would
provide
clarity
to
end
users
if
there
was
just
labels
or
just
attributes.
L
I
proposed
just
a
bit
ago
that
we
create
an
attribute
dictionary,
an
attribute
in
label
dictionary.
I
think
it
would
be
a
reasonable
place
to
call
out
the
difference
between
attributes
and
labels,
and
I
also
suggested
that
we
would
even
include
how
you
might
serialize
some
attribute
values
as
labels
having.
G
Yeah,
I
think
that's
fine.
I
do
like
that
resource
attributes
or
I
would
prefer
like
resource
attributes
and
span
attributes,
also
be
the
same
thing,
but
if
we
do
provide
clarity
on
this,
that's
that's
helpful,
but
we
definitely
throw
a
lot
of
terminology
at
people
trying
to
adopt
this
project.
So
that's
that's
my
new
feedback.
D
There
I
only
have
a
few
minutes
left,
but
I
think
only
a
few
to
triage.
C
On
this
issue
that
you
are
showing
us
at
this
moment,
this
is
something
that
I
have
forgotten.
This
is
about
how
we
store,
expand
or
spam
context,
apart
in
the
context
unboxing
during
the
call.
So
you
know
that
we
implemented
this
differently
in
java.
I
think
it
works
great
for
us,
but
I'm
wondering
it.
It
feels
like.
I
know
that
it
may
sound
bad,
that
we
keep
adding
stuff,
but
this
also
seems
like
important
enough
to
explore.
C
M
Yeah,
so
this
was
one
of
the
things
that
I
pushed
so
hard
on
java
as
carlos
mentioned,
and
we
proved
that
it's
working
a
bit
better
and
it
clarifies
things
and
and
doesn't
complicate
logic.
So
I
think
he's
probably
I
I
believe
this
comes
from
one
sentence
in
the
specs,
the
context,
md
that
says
that
you,
you
should
have
the
ability
to
store
both,
but
I
think
that
needs
to
be
clarified
so
anyway.
M
I
think
there
is
an
action
item
and
I
think
it's
release
required
for
ga,
probably
probably
p2,
because
it's
I
bet
is
not
only
go
that
does
this.
C
G
G
G
G
D
C
F
A
This
is,
I
guess,
editorial
doesn't
have
to
be
before.
G8
would
be
nice
too,
but
not
necessary,
p3
or
after
ga,
after
g8
is
fine.
D
I
What
do
the
others
think?
I
think
if
we
don't
specify
it,
we
have
to
say
if
you
use
asynchronous
resource
detection,
it
is
unspecified
whether
the
resources
will
be
sent
with
dispense,
because
I
think
it
breaks
a
basic
assumption
if
we
don't
send
it
with
dispense,
because
currently
we
say
resources
are
immu
table.
I
F
The
other
part
that
one
of
my
co-workers
brought
up
when
I
was
talking
about
this
earlier
with
him-
is
that,
because
these
are
remote
calls
they
could
potentially
fail.
It's
obviously
unlikely,
but
then,
if
you
use
these
resources
as
part
of
your
service
detection
on
your
back
end
or
something
like
that,
then
the.
If
this
call
to
the
to
gather
resources,
fails,
it
may
show
up,
as
these
spans
coming
from
a
completely
different
service,
or
something
like
that.
F
So
it
may
actually
make
more
sense
to
disallow
these
types
of
asynchronous
or
remote
call
resources
and
create
some
other
place
for
them
to
live,
which
is
obviously
a
bigger
change
and
would
have
been
nicer
to
think
of
earlier.
But
it's
just
something
worth
thinking
about.
I
guess
that
those
calls
can
fail.
That
was
my
concern.
H
As
well
in
the
question
that
we
don't
specify
whether
it
should
fail
the
whole
node
or
continue
on
without
the
ones
that
couldn't
fetch
and
just
continue
trying
to
fetch
them,
like,
I
think,
just
defining
that
would
be
useful.
I
don't
know
if
it
has
to
be
something
completely
different
if
we
specify
whether
or
not
it's
okay
to
continue
on
and
just
continue
trying
forever
or
stop
trying.
I
don't
know.
G
I
definitely
don't
think
that
observability
should
kill
the
node.
That's
certainly
not
a
default
behavior.
I
would
want
to
see
it
should
do
no
harm,
but
I
do
feel.
G
Ideally
we
have
all
of
these
resources
there
at
the
beginning.
So
some
fans
don't
miss
it,
but
I
can
also
see
cases
where,
if
you
were
having
trouble
fessing
a
resource
right
at
the
beginning,
but
you
were
able
to
get
it.
It
would
be
great
if
presuming
these
are
long-running
services
that
perhaps
the
first
batch
of
spans
that
got
out
would
have
incomplete
resources,
but
the
remaining
spans
would
be
normalized
and
have
all
the
correct
resources
on
it.
F
But
then
so
there's
two
one:
you
break
the
assumption
like
what
christian
said
that
spans
are
that
the
resources
are
immutable,
so
if
the
first
spans
have
a
different
resource
than
spans
after
it,
that's
obviously
a
problem
and
then
the
assumption
that
it's
always
long
running,
I
think,
is
a
strong
assumption
to
say
the
least.
If
you
have
something
like
lambda,
you
have
a
quick
startup.
F
M
G
It's
as
important
vendors
are
kind
of
have
baked
right,
like
they
also
don't
have
shutdown
books
which
we
would
really
want.
So
I
I
agree,
it's
not
perfect
in
lambda,
but
I
am
thinking
about
non-lambda
scenarios,
and
would
you
want
your
service
to
just
not
have
a
resource
block
its
startup
time
getting
the
resource
or
append
the
resources
later
so
that
most
of
the
spans
that
came
out
of
the
service
were
fully
indexed,
but.
M
G
M
G
Right,
I'm
saying
for
lambda
environments,
I
think
the
approach
I
think
using
something
like
this
in
a
lambda
environment
would
not
be
good,
but
I'm
saying
for
the
other
use
cases
I
think
which
would
you
prefer
right
for
a
long
running
process?
Would
you
prefer
to
just
have
those
services
completely
to
not
be
indexed
for
their
entire
lifetime
properly,
like,
let's
say,
you're
missing
some
kubernetes
resources?
G
M
Do
that
we
do
that
in
the
collector
in
environments
that
allow
you
to
do
that
so,
for
example,
in
kubernetes
we
we
do
append
kubernetes
informations
for
spams
coming
from
a
specific
process
thought
by
by
knowing
who
initiated
the
connection
to
us
and
so
on.
But
that's
again
there
are
scenario:
there
are
environments
where
we
can
do
something.
There
are
environments
where
there
is
no
other
way
to
do
it
externally,
and
probably
solution
can
be
different.
M
G
So
I
think
it
is
an
important
point,
but
I
we
we
could
solve
this
later.
As
you
say,
what
we
currently
have
is
is
good
enough
to
to
get
rolling.
O
O
Yeah
they
can,
they
can
have
a
callback
they
can,
they
can
say,
like
I
want
to
get
the
resource,
and
until
I
got
the
resource,
I'm
I'm
happy
to
proceed
with
telemetry.
Otherwise,
don't
do
anything
or
they
can
decide.
I
don't
want
to
wait.
Just
give
me
one
second
timeout
and
I'll
give
up
and
set
empty
resource.
I
think
the
application
owner
has
the
best
knowledge
about
what
they
want.
We
can
probably
give
them
some
default,
like
behavior,
based
on
the
runtime
environment,.
G
M
Make
sure
right
now
I
don't
think
our
sdk
does
auto
detection
our
sdk
allows
only
to
set,
and
we
provide,
as
as
as
alternative
or
extensions
ways
to
to
auto,
detect
so
kind
of
we
move
the
problem
to
the
next
to
to
to
outside
our
sdk,
and
our
api
may
or
may
not
be
a
good
thing.
But
that
means
we
don't
have
the
problem
in
our
packages
that
we
ship.
O
Yeah
exactly
yeah
and
that
that's
why
I
I
think
it's
not
a
like
ga
blocker,
but
I
I
do
think.
Besides
sdk,
we
have
other
stuff
like
auto
instrumentation
those
things,
so
it
will
be
very
helpful,
and
this
is
a
common
scenario
that
everyone
will
will
eventually
hit
at
some
point.
So
after
ga
we
can
clarify.
C
Thanks
so
much
okay,
now
on
to
the
fun
yeah,
one
of
the
two
important
things
or
issues
that
I
want
to
discuss
today
is
exactly
using
context
as
a
single
mean
to
specify
parenthood.
Yes,
so
this
is
the
one
we
want
to
discuss.
We
need
somebody
to
help
driving
this
in
java.
We
already
have
this
as
a
prototype,
so
yeah
I
just
wanted
to
have
all
maintainers
and
approvers
of
every
language.
M
I
think
I
think
there
were
some
comments
about
tris
about
this
from
tristan.
That
is
the
most
concerned
about
this,
and
probably
we
should
try
to
to
address
those,
and
maybe
maybe
this
is
the
right
time
to
discuss
some
of
these
concerns
just
in
order
to
make
progress,
because
I
felt
I
felt
reading
that
that
he
is,
he
has
some
understanding
of
of
other
systems
like
airline
where,
where
this
may
not
be
the
good
thing
to
do,
and
I
would
like
to
understand
better
there.
H
So
this
is
about
having
the
context
as
the
parent
to
a
span.
H
So,
in
a
sense,
it's
not
a
concern
if
we're
talking
about
just
you
passing
a
context
to
extract
this
active
spam
context
from
it
to
use
as
the
parent.
But
if
we're
linking
like
using
a
pointer
to
the
context
as
the
parent
that's
stored
in
a
span,
that's
where
the
issue
becomes.
M
No,
no,
no!
So
so
far
so
far,
the
api
just
wants
to
allow
you
to
pass
the
context
instead
of
you
explicitly
getting
the
parent
from
the
context
and
so
on
now
now
it's
a
matter
of
how
we
implement
from
here.
First,
the
api
will
define
this
capability
and
allow
users
to
pass
the
context.
Okay.
M
Now
I
think
you
are,
you
are
thinking
a
bit
further
and
you
are
thinking
what
do
we
do
with
this
context,
but
so
far
we
haven't
defined
that
so
so
maybe
maybe
storing
pointers
is
probably
not
the
right
thing,
but
so
far
so
far
we're
gonna
extract
the
the
parent
and
use
that.
So
that's
that's
a
good
thing,
because
we
we
kind
of
help
the
user.
M
M
Now
now
in
the
future,
we
may
want
to
say:
okay
extract
the
baggages
also
and
store
them
as
attributes,
for
example,
as
one
option
or
stuff
like
that.
I
don't
think
we
should
aim
for
force,
storing,
pointers
or
stuff
like
that,
because
that's
that's
probably
something
hard,
but
we
may
extract
other
informations
from
the
context
and
store
them
in
the
span
as
well,
not
only
the
parent,
but
we
in
the
future.
M
We
may
do
that
and
maybe
that's
where,
when
we
should
have
different
discussions
and
different
concerns,
but
so
far,
let's,
let's
focus
on
only
this
thing
which,
if
which
is
just
to
allow
people
to
pass
the
context
instead
of
extracting
from
the
context
the
active,
the
active
element
that
we
have.
I
I
think
that's
a
good
point.
Currently,
the
pr
the
875
does
specify
that
you
should
store
the
context
that
you
master
the
context
and
pass
it
to
exporters,
because
that
the
problem
I
actually
had
when
I
proposed
this
was
that
I
wanted
to
extract
some
custom
property
that
I
also
needed
in
the
export
and
to
solve
that.
I
I
also
needed
to
pass
that
to
the
exporter,
but
we
can
take
it
part
by
part,
because
this
is
an
sdk
only
change,
and
I
can
remove
that
from
the
pr
for
now
and
it
seems
like
just
changing
the
api
to
extract
the
context.
But
under
then
only
storing
the
span
context
would
on
the
sdk
span
would
be
a
good
first
step
and
we
can
do
the
rest,
probably
after
ga
yeah.
Although.
F
I
Think
in
the
end,
we
will
need
to
store
the
full
context,
but
it
can
be
done
later.
H
I
Yeah,
currently,
the
spec
allows
span
context
and
span
and
I'm
not
even
sure
if
it
allows
context.
Currently,
I
hope
so
I.
H
Think
I
I
I
guess
I
thought
it
was
implicit,
that's
how.
P
M
What
I
would
propose
is
probably
not
to
store
it
and
and
not
to
store
it,
but
but
allow
we
have
spam
processor
and
we
have
onstart
that
happens
synchronously
during
the
start
of
the
span,
where
the
context
is
still
available
because
we
just
pass
it
to
the
to
the
api.
So
that
may
be
the
place
where,
where
we
give
users,
the
ability
to
to
look
into
the
span
maybe
extract
anything.
They
want
into
the
context.
I
M
Yeah,
you
can
store
it
as
attributes
if
you
want
or
or
we
can
discuss
how
we
give
you
another
ability,
but
I
think
holding
on
that
context
may
be
a
problem
because
other
issues
with
the
gc
in
even
so,
I
think
what
we
should
do
is
first
change
the
api
to
accept
the
context,
as
everyone
has
agreed,
including
tristan,
because,
as
he
pointed,
he
was
already
thinking
that
this
is
the
case
and
second
think
how
we
give
access
via
hooks
or
via
other
mechanisms
in
the
sdk
to
custom,
to
users
to
do
custom
things
with
this
context
and
hopefully
without
having
to
store
it.
M
C
Nice,
in
that
case,
I
would
like
to
see
it.
As
I
said.
As
I
said,
we
have
protein
java
prototypes
in
other
languages,
so
yeah
I
would
like
to
have
at
least
see
one
or
two
more
prototypes,
maybe.
H
C
M
The
current
the
current
proposal
is
to
only
pass
context
and
not
anything
else.
So
that's
that's
where,
where,
where
the
prototyping
comes
in
place,
because
just
adding
the
capability
to
to
pass
context
plus
spam
plus
spam
context,
it's
an
addition.
So
we
probably
don't
need
too
many
prototypes,
but
replacing
those
two
with
just
allowing
context.
M
We
need
to
understand
not
only
prototype,
but
we
need
people
to
look
at
some
of
their
instrumentations
and
stuff
and
see
if
it
will
cause
problems.
Essentially.
Another
thing,
as
I
pointed
in
the
issue,
is
even
though
this
may
be
a
dramatic
change
or
a
drastic
change
in
in
that
api.
I
think
we
can
start
slow.
M
We
we
understood
that
we
want
to
pass
context
for
for,
because
for
usability
for
for
future
proof
of
being
able
to
extract
things
if
we
want
and
so
on,
so
we
want
to
have
this
ability
if
we
start
with
this
and
we
identify
in
any
language,
let's
say
in
a
month
that
we
also
need
to
pass
a
span.
We
can
add
it
later
because
it's
backwards
compatible
to
add
new
things.
So
so
I
think
we
can
just
go
ahead
without
even
too
much
too
much
prototyping.
M
As
long
as
we
are
open-minded,
and
we
know
that
hey
we,
we
made
this
decision
without
fully
understand
it
here.
We
know
why
we
really
need
it,
but
we
don't
know
if
we
will
miss
the
capability
of
passing
the
span
so
yeah.
I
I'm
fine
with
merging
it
just
like
that,
and
while
we
are
starting
implementing
this,
we
learn
and
we
add
the
capability
back
if
we
need.
B
I
was
kind
of
looking
at
this
yesterday
and
in
general
yeah,
like
I
think
it's
fine.
I
think
you
ultimately
need
this
and
that
by
only
allowing
parenting
from
a
context,
I
think
you
will
avoid
probably
some
nasty
bugs
by
people
trying
to
pass
in
a
span
when
you,
when
you
want
more
things
from
from
the
context,
potentially
than
just
a
span
context
like
baggage
or
other
things,
but
I
do
recognize
that
it
does
make
the
apis
like
a
little
weird.
B
I
think,
because
start
span
returns
a
span
which
I
think
you
still
want,
because
you're
going
to
want
to
interact
with
this
fan.
Add
some
attributes
add
some
events,
so
it
makes
sense
but,
like
context,
context
ends
up
being
like
this
kind
of
first
class
thing
you
need
to
get
a
handle
on,
but
it
ends
up
kind
of
like
lurking
in
the
shadows.
I
think
in
a
lot
of
these
languages,
where
you
kind
of
have
to
go
through
a
context
api.
B
You
know
what
I'm
saying:
it's
not
exactly
the
return
result
from
a
thing
that
you're
working
with
in
code
so
like
you,
can
still
get
it.
I
know.
Go
have
handled
this
by
returning
both
a
span
and
a
context
from
start
span,
which
would
be
awesome,
I
think,
but
for
a
lot
of
languages
like
multiple
return,
values
are
either
impossible
or
maybe
not
idiomatic
if
they
are
possible.
But
I
that's
just
my
concern
I
feel
like
it
makes
the
apis
awkward.
M
Maybe
maybe
maybe
that's
where,
yes,
maybe
that's
where
we
need
to
look.
We
need
to
look
how
the
api
looks
like
more
than
just
functionality-wise,
because
we
understand
the
the
reasons
behind
this,
but
we
need
to
to
see
how
the
api
looks
and
maybe
maybe
make
the
the
star
span
to
return,
also
context.
So
then
we
simplify
and
we
we
look
more
like
a
context
and
then
user
have
to
extract
the
span
from
the
context
if
they
want
to
add
events
or
another
alternative
could
be
going
even
further.
M
I
F
Yeah,
I
mean
that's,
not
a
problem
in
javascript
nope.
The
javascript
problem
has
much
more
to
do
with,
like
unconfigured
sdk
behave
once
you've
configured
an
sdk
context.
Propagation
is
not
a
problem
in
javascript.
F
F
M
G
There's
also
the
use
case
of
out-of-band
span
reporting,
if
you're
putting
after
the
fact,
then
I
think
only
having
the
active
span
or
active
context
be.
The
possible
parent
would
be
probably
complicate
that
use
case.
I
But
we
decided
to
not
support
out
of
ben's
band
support
reporting,
I
think,
a
long
time
ago
when
we
had
to
spend
data
api,
we
said
it's
to
complicate
that
we
we
remove
this
ban
data
api
and
we
don't
support
out
of
bands.
G
Right
so
we
don't
have
span
data,
but
we
do
out
of
band
reporting
the
same
way
you
do
it
in
open
tracing
which
is
you're
just
creating
creating
span
setting
your
time
stamps,
setting
their
parents
et
cetera,
et
cetera
format,
but.
I
Yeah,
but
I
think
that
that
is
something
different.
For
example,
if
you
have
a
start,
onstart
action,
your
spam
processor,
that
action
might
assume
that
you
are
not
reporting
out
of
band
and-
and
it
may
capture
information
from
the
current
request
context
or
something
like
that
which
would
not
make
sense.
If
you
report
something
out
of
band,
I
mean
it
may
most,
it
probably
mostly
works
in
practice.
It's
just.
G
F
M
Yeah
so
so
I
think
I
think
it's
important
to
have
this
for
for
for
future
reference
and
stuff,
so
there
will
be
places
where,
where,
where
context
is
manually
propagated
because
of
the
environment,
even
if
a
thread
locally
is
available
or
something
look
at
go
for
example.
So
I
would
I
would
go
with.
We
should
have
this
option
anyway.
M
G
A
A
Yeah
yeah,
I
understand
so
I
mean
for
those
that
don't
have
the
notion
of
the
threat:
local
storage,
where
you
can
store
the
context
yeah,
but
I
mean
we
already
have
the
the
example.
We
when
you
say
prototype,
we
have
that
in
in
gold's
implementation.
Today,
that's
that's!
How
gold
2000
things
that
the
start
function
accepts
the
the
context,
not
spam
context,
and
it
returns
the
context
and
spam.
A
I
M
M
We
don't
have
this
capability
and
there
was
a
question
if
the
api
will
be
strange
or
will
be
a
bit
ugly,
because
we
passed
the
context
as
parent,
but
we
return
a
span
or
maybe
maybe
we
can
have
in
languages
like
that
two
different
methods,
one
start
span
that
returns
a
span,
start
span
that
returns
a
context
or
whatever.
Yes,.
H
M
We
we
need
to
to
maybe
polish
that
to
to
make
it
look
better.
Yeah.
G
Okay,
trying
to
move
on
sorry,
sorry
in
when
I'm
writing
actual
go
code.
I
I'm
yearning
for
helper
functions
to
just
grab
the
span
out
of
the
context
like
all
the
time,
so
so
it
at
least
didn't
go.
It
wouldn't
feel
too
weird
to
me
if
we
were
almost
exclusively
dealing
with
the
context,
because
I
almost
end
up
writing
code
that
looks
like
that
anyways.
G
H
H
G
A
A
G
A
K
Q
Yeah,
it
absolutely
does
I'm
just
a
little
confused
about
you,
guys,
yeah
kind
of
going
into
that
one
I
was
looking
at
the
documentation,
couldn't
find
it
somehow
so.
Q
There's
a
large
performance
hit
in
doing
a
lookup
on
the
context,
and
so
having
access
to
the
span
is
actually
very
useful
for
a
lot
of
people
directly
and
so
yeah
it
in
go.
It's
really
nice
because
you
are
passing
a
context,
because
it's
kind
of
it's
not
kind
of
it
is
a
built-in
in
the
language
and
it's
something
that
can
just
easily
be
transmitted,
but
like
the
conversion
between
a
context
and
a
span
is
not
a
trivial
one.
Q
At
times
for
performance,
wise
and
and
there's
a
added
overhead
of
boilerplate
as
well,
so
I
think
that
it's
something
to
be
weighed.
G
Yeah,
I
I,
where
I
want
it
more,
is
in
application
code,
not
an
instrumentation
code,
where
often
what
I'm
doing
is
just
making
a
single
call.
So
I'm
grabbing
the
span.
You
know
adding
a
pack
of
attributes
to
it
and
then
that's
that
or
creating
an
event
or
something
like
that.
That's
kind
of
what
I
wanted
but
anyways.
This
is
a
bike
shed.
H
H
And
I
think
I
yeah
I'll
put
it
in
the
issue
when
I
have
it,
but
I
think
we
should
also
kind
of
I'd
like
to
see
how
other
languages
are
doing
stuff
like
past
starting
a
child
and
adding
sending
it
to
a
go
routine.
How
that
works
in
python
and
java
it'd
be
great.
To
I
mean
we
need
it
for
documentation
anyway,
and
I'd
just
like
to
see
it
to
compare.
M
C
Okay,
moving
on,
we
only
have
five
minutes.
So,
let's
try
to
get.
There
are
there's
another
one,
important
issue.
We
can
follow
up
offline
about
update
updating
center
for
injection.
This
is
for
headers
whether
we
should
support
multiple
values
like
trace
states.
There
are,
more
importantly,
there
are
two
standing
prs
which
address
feedback
that
need
to
be
reviewed.
Please
check
them
out.
C
One
of
them
is
from
yusuke
about
moving
spam
interaction,
active
span,
interaction
to
some
trace
context,
utility
or
module,
and
the
other
one
is
an
alternative
pr
from
sergey
about
having
no
default
propagandas.
So
please
review
that.
We
really
need
reviews
just
go
there
if
it
looks
right
approve,
if
not
just
give
your
feedback
and
then
christian
incomplete
something.
Please
elaborate.
I
I
K
I
I
Maybe
because
the
I
think
the
trace
id
is
probably
a
trace,
id
has
to
be
generated
because
it's
an
input
to
the.
G
But
I
guess
what
I'm
saying
is,
I
feel
like
we
don't
have
implementations
of
samplers
yet,
and
so
that's
why
we're
noticing
things
like
this
at
the
last
minute
and
so
that
that's
my
primary
concern
is
that
people
are
going
to
write
samplers
late
in
the
game
and
then
realize
they're
missing
some
facility
that
they
need
or
whether
it
be
hooks
or
whether
it
be
information
passed
to
the
sampler
or
whether
it's
something
the
sampler
is
able
to
perform
like
an
action
it
can
perform.
G
M
M
M
I
I
M
I
think
I
think
the
generation
of
the
newest
fan
id
was
removed
a
month
ago
or
so
because
people
found
that
as
a
performance
hit,
which
I
don't
know
it
can
be.
To
be
honest
for
me,
for
me,
it
was
much
easier
to
understand
and
everything
if
we
always
generate
the
ideas,
but.
M
I
I
M
Maybe
maybe
this
is
what
they
wanted
it.
So
the
the
thing
is,
if
I
don't,
if
I
I'm
trying
to
create
a
span,
if
I
decide
to
not
record
it
at
all,
instead
of
creating
a
new
id
and
break
the
the
chain
of
the
of
recorded
spans,
I
will
just
propagate
the
parent
id
as
my
span
id.
So
then,
then,
then,
if
there
was
up
the
stack
like
five
layers
up,
there
was
a
span
that
sampled
and
there
is
going
to
be
another
one.
Five
layers
down.
They
will
be
connected.
C
M
I
Before
now,
thank
you
with
what
you
said.