►
From YouTube: Open Tracing Call 2017.11.03
Description
Join us for KubeCon + CloudNativeCon in Barcelona May 20 - 23, Shanghai June 24 - 26, and San Diego November 18 - 21! Learn more at https://kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy and all of the other CNCF-hosted projects.
B
B
Let's
see
so,
we
have
an
agenda
and
some
of
these
first
couple
things
were
late
in
my
opinion,
so
I'm
just
gonna
go
down
the
list
I'm
a
little
under
slept.
So
if
I'm,
a
little
slow
or
I've
missed
something
just
like
jump
in
and
say,
hey,
but
starting
with
there's
a
couple
of
issues
that
were
opened
by
Felix
Barney
around
exposing
things
on
span
context,
one
is
a
is
route
whether
or
not
the
span
is
the
route
span
and
should
sampling
decisions
be
made.
B
B
D
E
D
I
mean
I,
don't
know
it's
something
that
we've
we've
discussed
this
and
various
forms
in
the
past,
I've
always
been
really
hesitant
about
adding
getters
that,
like
have
to
you,
know,
suddenly
have
to
do
with
limitation
details
of
various
systems
and
I
think
an
example
that
might
actually
pass
the
test
of
being
like
universally
accepted
as
an
idea
that
it's
worth
putting
in
there
but
there,
even
that,
can
be
like
more
complicated
than
it
seems
like.
There
are
a
number
of
systems
that
exist
already,
that
have
varying
degrees.
D
The
sample
miss
like
there's
sort
of
sampled
and
then
they're
sampled,
with
even
extra
information
and
and
it
can
be
almost
like
a
frosty
flag.
So,
all
of
a
sudden,
you
have
this
like
this
concept,
that's
in
my
mind,
going
beyond
the
scope
of
describing
instrumentation
and
going
into
the
scope
of,
depending
on
insulin,
tations,
that
it's
just
like
something.
F
D
Always
wanted
to
be
really
cautious
about,
but
I
I
mean
I
have
looked
at
the
issue
and
I
understand
why
it,
especially
from
a
few
there's
a
lot
of
optimizations
you
can
make
if
you
know
you're,
not
in
a
sample
test
and
that's
valuable,
so
I
think
I
like
I
get
it
I
just
found.
I
would
just
maybe
want
to
be
thoughtful
about
how
it
might
evolve
and
try
to
avoid
like
just
an
obvious
deprecation
in
six
months
or
something
like
that
as
we
make
it
a
little
more
flexible.
D
D
A
Feel
similar
concern
with
the
sample
bit.
Definitely
because
we're
doing
various
experiments
with
sampling,
which
is
not
necessarily
expressed
as
trend
Falls,
so
that's
kind
of
tricky
to
to
do
and
then
I
don't
have
to
like
two
big
objections
to
his
route.
That
seems
like
a
reasonable
thing,
but
it's
like
I
think
it's
tightly
coupled
to
the
reason
why
Felix
need
that
is
coupled
to
the
sample
thing
so
I'm
not
sure
how
critical
that
is
really.
B
B
B
I
find
it
related
to
to
this
trace
context
workshop
that
just
happened,
so
I
would
be
curious,
maybe
to
dovetail
into
that
and
back
again
to
this,
because
I
see
the
people
trying
to
standardize
and
in
the
context
of
like
what
is
this
wire
protocol
and
what
needs
to
be
on
there.
And
what
can
we
agree
on
there?
That
seems
to
be
pretty
similar
to
the
kind
of
things
we're
sort
of
having
to
hash
out
with
span
context
and
I.
B
Would
you
know
kind
of
in
a
way
make
the
argument
that
there
they
are
the
same
thing?
Open
tracing
is
the
sort
of
language
level
API
for
trace
context,
potentially
and
I
think
it
would
be
great
if
those
two
things
had
alignment
with
each
other,
but
I
just
feel
like
people
who
have
been
having
that
trace
context.
Debate
had
probably
been
in
the
weeds
a
lot
more
about
what
people
could
realistically
support
or
not
so
maybe
can
someone
who's
been
there
report
back
on
what
they
think
about
trace
context
and
how
that's
going
I.
A
C
C
It
was
a
very
difficult
discussion
to
follow,
but
basically
I
think
they
have
a
trace
context,
header
defined
and
they
were
hashing
out
the
details
on
the
what
was
the
other
context
so
trace
context.
Header
is
basically
a
fixed
length
with
specific
fields
it
defined
in
it
and
then
there's
the
the
other
I
can't
remember
if
it
was
like
application
context
or
thing
all.
C
C
G
D
C
D
All
right,
that's
actually
like
a
wise
way
to
I'm
glad
to
hear
that
cause.
It
seem
like
they're
on
github.
The
discussion
has
been
converging
on,
you
know
like
yeah,
you
can
have.
We
don't
need
to
have
everyone
agree
about
the
length
and
particular
fields
themselves
and
I
was
surprised
to
hear
that
going
back,
but
it
sounds
like
you
mean
it
up.
There
is
a
set
of
field
and
an
assumption
that
they're,
like
quote
reasonable
length
like
this
you're,
not
going
to
have
the
kind
of
baggage
issue
a
thing.
C
A
One
thing
about
the
I
guess:
tracing
fields
that
the
length
wasn't
actually
discussed
that
much,
but
what
was
discussed
a
lot
is
the
notion
whether
everyone
can
treat
the
trace
idea
as
opaque
blob,
because
some
tracing
systems
like
in
Amazon
they
actually
encode
time
stamp
on
it
and
they
like
do
some
business
logic
based
on
that,
so
for
them
trace.
Id
is
not
opaque
and
I.
Think
some
other
systems
do
like
my.
What
is
Microsoft.
They
used
this
hierarchical,
but
they
appended
to
the
trace
ID,
rather
than
to
the
request
idea.
A
I
think
they
were
so
I
think
there's
a
lot
of
discussions
about
whether
all
those
systems
can
cope
with
with
the
opaque
trace,
ID
and
I
did
not
see.
The
final
conclusion
in
the
notes.
I
got
the
feeling
that
they
did
agree
that,
like
it's,
it's
like
not
free,
but
most
systems
can
cope
with
with
some
work
to
actually
treat
trace
ideas.
Okay,
because
I
think
that
was
one
of
the
biggest
when
questions
really
yeah.
C
A
D
D
Maybe
that's
considered
an
on
goal,
but
I
was
wondering
if
the
discussion
was
able
to
kind
of
like
dear--there,
that
to
a
certain
extent,
it
just
seems
like
very
brought
to
me
and
it's
the
reason
why
I've
always
had
given
up
on
that
project
beyond
it
like
I.
Just
don't
know
how
to
do
it,
but
like
I,
was
curious,
just
almost
work
for
the
like
dynasties
people
like
is
this
something
that
that's
beneficial
for
them?
If
you
know
they
get
handed
ideas
that
they
can't
work
with
like,
why,
like?
D
A
I
think
that
goes
into
the
second
part,
which
was
pretty
large
discussion
about
the
actual
interrupt
modes
I
which
to
me
is
sort
of
the
the
most
vague
area
of
this
colony
sniffles
like
what
exactly
that
trying
to
achieve,
and
so
there
are
some
proposals
about
like
compatibility
levels
like
level
zero,
you
simply
pass
what
you
were
given
and
you
don't
modify,
whereas
in
level
one
D
actually
replaced
some
portions
of
the
trace
context,
but
I
was
not
part
of
that.
So
I
only
saw
this
from
the
notes.
D
Yeah,
let
me
a
level
zero.
English
is
kind
of
sense
to
me,
but
that
could
be
that
discussion
is
easy.
It's
like
you
decide
on
the
how
to
name
you
put
some
constraints
on
the
length
of
it
and
you're
done.
It's
not
like
this.
You
don't
need
to
discuss
anything
complicated,
but
if,
yes,
it's
the
additional
levels
of
it,
where
I
ask
you
like,
it
would
be
awesome
I.
C
C
B
B
I
and
many
other
people
I
think
want
to
build
tooling
on
top
of
the
open
tracing
API
that
you
know,
helps
correlate
what
you're
doing
with
your
tracer
and
what
you
might
be
doing
with
other
systems
like
metrics
and
logging
and
things
like
that,
and
it
definitely
feels
like
there
isn't
enough
of
that
kind
of
correlative
information
being
exposed
currently
by
span
context.
I
almost.
C
B
I
wholly
agree
with
that
I
mean
I.
Don't
see
it's
hard
for
me
to
imagine
a
world
where
everyone
could
agree
that
this
wire
protocol
is
like
standard
enough.
We're
all
gonna,
adopt
it
and
be
satisfied,
but
we
wouldn't
want
to
expose
those
things
on
the
in
process
span
context.
They
seem
pretty
similar,
so
same
discussions
would
come
up
in
both
cases,
so
it
would
be
great
if
they
dovetailed
and
if
trace
context
is
close
to
getting
over
the
line.
B
A
Thing,
though,
is
that
I
think
Asian
made
a
very
kind
of
pragmatic
proposal
is
that
he
said
okay.
Well,
if
we
cannot
satisfy
everyone,
the
options
are
either.
We
just
drop
this
initiative
all
together
or
we
say
we're
gonna
cover,
80%
and
then
20
I
can
think
what
they
want
to
do.
Maybe,
like
change
their
systems,
to
actually
be
compatible
with
that
one.
A
So
this
this
might
be
like
an
approach
to
choppin
tracing
as
well,
because
yeah
like
we're
saying
that
we
want
to
support
every
possible
like
tracing
system
today
with
the
API,
but
then
in
practice.
Maybe
there
aren't
any
tracing
systems
who
do
not
have
trace
IT,
which
are
often
tracing
compatible
today
right,
so
we
move
on
the
way,
pros
and
cons
of
actually
like
not
providing
functionality
because
of
some
theoretical
possibility
that
someone
may
come
another
place.
Assistant,
yeah,
I,.
B
Predict
no
matter
where
we
picked,
it
has
to
include
you
know
not
applicable
for
each
one
of
these
getters
right
like
if
you
ask
for
trace
ID
and
you
get
a
blank
string
back.
That
means
doesn't
mean
the
trace
idea
is
blank
string.
It
means
there
is
no
trace
ID
or
it's
not
supported
like
what.
If
a
bling
bit
can
be
a
sampling,
you
know
enum,
that
is
like
sampled,
not
sampled
and
not
applicable.
I
think
there's
ways
we
can.
We
can
kind
of
expose
it
in
a
optional
manner,
but
yeah.
B
We
should
wait
at
least
a
bit
until
trace
context,
either
hashes
out
I.
Think
some
of
these
things
are
ash
actively
hashing
it
out.
If
they
like
start
to
stall
or
seem
like
they
can't
get
enough
consensus.
There
I
suspect
the
open
tracing
span
context
requirements
might
be
a
little
more
relaxed
than
their
requirements
like
I.
Don't
think
we
necessarily
need
to
think
about
things
like
the
length
of
the
span,
ID
and
stuff
like
that
to
expose
these
api's,
but
but
there
should
be
some
back-and-forth
there.
So.
C
One
of
the
interesting
things
that
I
heard
from
the
meeting
is
that's
relevant
to
this
current
discussion.
Is
this
notion
of
delegating
the
decision
of
the
is
sample
of
the
sampling
decision
to
a
child
call?
So
this
only
works
when
it
there's
like
a
request
and
response,
but
a
parent
could
say:
hey
I,
don't
have
a
strong
opinion
on
whether
I
want
a
sample
or
not
or
I.
Don't
want
to
take
that
responsibility.
C
It
lets
the
the
child
call
basically
make
that
decision
by
like
denoting
a
question
mark,
for
example,
I,
think
and
then
waiting
for
a
response
header
to
come
back
before,
knowing
whether
they
need
to
sample
or
not-
and
I
think
this
was
talked
about
by
the
gentleman
from
amazon
as
something
that
they
do,
because
they
as
an
infrastructure
provider.
They
don't
necessarily
have
strong
opinions
on
whether
to
sample
and
they
don't
want
to
to
be
in
charge
of
determining
that
sampling
ratio.
C
D
I
mean
I
almost
sometimes
like
what
I've
noticed
that
people
think
about
sampling
in
one
of
two
ways
like
one
is
this
kind
of
thing
that
you're
talking
about
with
an
x-ray
loss
where
it's
like?
Well,
you
want
to
control
the
sampled,
the
other
one
is
really
about
performance,
and
it's
like
it's
just.
Sometimes
there
are
things
that
you
do
on
the
sample
path
that
are
expensive,
and
so
you
want
to
make
sure
you
don't
do
them
unless
you
have
to,
and
that's
like
strictly
a
like
a
robot.
D
The
optimization
kind
of
thing
and
actually
like
kind
of
have
different
implications
to
the
api,
is
just
in
the
way
that
you're
talking
about
this.
I'm
not
I'm
not
composing
what
the
solution
is,
but
it's
it's
an
interesting
problem,
or
I
think
people
often
say.
Oh,
I
want
to
sampled
it.
What
they
actually
want
is
control
over
how
much
time
they're
spending
cpu
time
they're
spending
on
the
sample
path,
which
is
sort
of
like
a
different
thing.
You
know.
B
B
Cool,
oh:
go
ahead,
all
right,
let's
move
on
so
the
next
next
big
item
here
is
the
the
Java
API
release
candidate
scopes
versus
continuations
I
personally
have
been
doing
a
lot
of
outreach
on
this
with
a
number
of
other
people
who
have
been
really
great,
putting
in
a
lot
of
effort
and
thought
into
this
issue,
because
we
really
want
to
make
sure
we
get
this
right
or
close
to
right.
I'm
personally
feeling
pretty
satisfied
at
this
point
that
we
could
get
by
without
continuations,
and
that
seems
to
make
people
happy.
B
I
also
think
it's
conceivable
that
we
could
add
continuations
or
continuation
like
construct
to
a
scope
and
the
scope
manager
proposal
like
we
currently
have
at
a
later
date.
If
it
turns
out,
we
really
really
needed
it,
but
I'm
currently
not
seeing
a
need
for
it.
Those
two
things
to
me
say
that
we
should
start
moving
towards
shipping
with
what
we
have
so
I
have
sort
of
two
questions
for
the
group:
one:
a
people
who
are
interested
in
Java
and
have
been
following
this:
do
you
also
feel
satisfied
and
feel
like
we
could
move
forwards?
B
And
the
next
question
is,
of
course,
next
steps.
What
should
we
do
in
preparation
for
that?
So,
let's
start
with
the
first
question
of
if
we
could
just
go
around
and
people
say
either
like
yay
or
nay
on
scopes
and
the
scope
proposal
so
and
to
make
this
this
easier,
I'm
just
gonna
go
across
this.
This
line
that
I
see
at
the
top
of
my
screen,
so
starting
with
Yuri.
A
B
I
had
a
we
had.
Some
of
us
had
a
really
good
long
discussion
with
some
people
from
like
the
end,
whose
name
Victor
I
believe
his
name
was,
might
be
mispronouncing
that
that
was
really
insightful
and
I
think
they're
going
to
be
showing
up
more,
but
they
they
agreed.
They
had
something
like
continuations
but
kind
of
dropped
it.
So
that
was
a
sign
that
maybe
you
don't
need
this
for
akka,
since
they
may.
A
B
I
mean
the
pattern
really
turns
out
to
be,
if
you
need
some
kind
of
special
mechanism
for
tracking
the
span
you're
doing
that
at
the
instrumentation
level,
rather
than
at
the
tracer
level.
So
so
most
tracers,
don't
most
things
don't
need
this
right
and
the
occasions
where
you
do
need
some
kind
of
reference
counting
thing
or
something
fancy
there's
there
is
a
turns
out.
B
Almost
always
eight
placed
you
to
put
that
it
means
you
have
to
use
a
you
know:
instrumented
actor
or
an
instrumented
future,
or
something
of
that
nature
potentially,
but
that
that
does
in
fact
work
and
we
now
have
implementation
that
proving
that
it
works
with
OT
I.
Don't
think
Carlos
is
on
the
call,
but
he's
been
doing
a
lot
of
a
lot
of
good
work
on
that
front.
B
I,
don't
I,
don't
think
it
will
in
that
respect,
that
they're
we're
not
providing
any
kind
of
mechanism
with
this
current
API
to
put
that
in
there.
But
I
have
a
lot
of
faith
that
in
DC
would
work
as
as
an
observer,
and
so
there's
this.
This
sort
of
actually
dovetails
with
the
Tres
context
fan
context.
B
Discussion
earlier,
which
is
observers
I,
think
suffer
a
bit
of
extra
complexity
because
we
don't
expose
a
correlation
ID
and
some
things
that
would
make
observers
work
better,
but
I
think
if
you
did
that
and
in
fact
there
is
a
Maddon
and
not
sure
what
his
real
name
is.
I
just
call
him
mavin
in
my
head,
because
that's
what
his
github
handle
is
Marcel
Marcel
Marcel
I
apologize
for
thinking
of
use
method,
but
he
has
an
issue
which
I
will
paste
into
the
notes
about
exactly
this,
and
he
also
has
a
conclusion.
B
I
believe
that
if
you
had
some
kind
of
correlation
ID,
you
can
make
this
work
as
an
observer.
He's
made
it
work
as
a
rapper,
but
rappers
are
kind
of
problematic,
so
so
that
that's
my
pitch
on
MDC
that
that's
a
sort
of
optional
thing
that
can
go
on
top
of
that.
That's
the
kind
of
thing
that
should
work
with
observers
and
that's
the
kind
of
integration
thing
we
need
to
be
doing
in
general.
So
it's
not
an
MDC
specific
thing.
It's
a
correlating
tracing
with
whatever
you're
trying
to
do.
C
B
C
B
C
So
I've
kind
of
gone
back
and
forth
a
lot
I
think
that
it
sounds
promising.
You
know,
since
we're
on
this
kick
of,
let's
simplify
the
API.
It
kind
of
got
me
wondering.
Is
there
other
aspects
of
the
open
tracing
API
that
should
be
considered
as
like,
perhaps
too
complicated,
and
that
maybe
we
could
reduce.
C
So
I
mean
one
example
might
be
with
the
advent
of
open
tracing
I'm.
Sorry,
not
open
with
the
the
the
trace
continue.
Sorry
the
distributed
tracing
workshop,
for
example,
and
this
trace
context
discussion.
If
we
have
this
correlation
context,
do
we
really
need
to
have
baggage
or
maybe
baggage,
or
something
like
that
should
be
extracted
out
anyway?
C
C
B
Yeah
I
I
think
it's
possible.
Some
other
things
might
might
be
simplified.
I.
Think
baggage
is
here
to
stay
personally.
I
want
something
like
that.
In
fact,
there's
been
calls
for
even
more
things
like
it,
but
we'll
see
personally.
I
have
no
appetite
for
trying
to
go
any
further
than
we
have
with
this
round.
Given
that
we're
trying
to
you
know,
get
this
continuation
stuff
done,
it's
been
such
a
long,
long,
hard
road
to
really
vet.
B
This
thing,
but
certainly
I,
think
there's
a
window
here
for
people
to
investigate
other
other
knits
I
would
just
be
sensitive
to
the
fact
that
we
don't.
We
don't
want
to
perturb
people's
existing
instrumentation
avoid
it,
but
if
other
people
have
thoughts
about
simplifying
the
API,
please
speak
up.
I
do.
D
Think
it's
a
good
point,
Tyler
and
I
think
there
are
a
couple
of
opportunities
to
do
that.
I
had
a
conversation
that
Foggs
Andrew
who's
worse
at
Google
and
worse
on
census
and
no
consensus-
and
you
know
like
TLDR,
is
like
yes,
sir
I
think
there's
some
things
that
could
be
done
to
the
API
that
might
be
considered
improvements
if
you
ignore
backwards
compatibility
and
since
we're
doing
something,
that's
not
very
backwards
compatible.
Maybe
this
is
a
good
opportunity.
I
would
suggest
that,
like
maybe
to
reframe
Ted's
question
I
think
we
should.
D
We
should
not
be
like.
Is
everything
about
I've
been
tracing
API,
perfect
right
now
and
making
it
more
like
in
terms
of
the
Scopes
change
like
how
do
we
feel
about
it
and
and
on
that
front
I
I
mean
otherwise.
It's
like
the
scope.
The
question
is
too
large,
but
no
pun
intended,
but
for
the
the
scopes
piece
itself,
just
like
some
time
talking
and
I'm
about
to
be
myself,
I'm
I'm,
totally
fine
with
it
and
I.
D
Think
I
would
like
really
applaud
tad
and
Tyler,
and,
and
you
know
really,
a
lot
of
people
want
to
say
who
spent
a
great
deal
of
time.
Trying
to
you
know,
figure
out
whether
this
would
not
work
in
some
important
corner
case
and
I
feel
like
the
given
the
amount
of
work.
That's
been
done
too
bad
at
that.
I
have
no
question
that
is
sufficient
and
and
I'm
like
three
thumbs
up
on
the
scopes
piece
itself.
E
B
G
B
H
Hi
Jonathan,
Facebook
I,
didn't
have
much
context,
so
I
was
reading
through
the
the
discussion
on
the
continuations
versus
ref,
counting
like
given
that
we're
not
currently
using
the
instrumentation
I,
don't
think
we
have
a
dog
in
the
fight.
We've
generally
had
issues
with
ref,
counting
and
application
code,
so
I
think
anything
that
makes
it
explicit
is
usually
easier
to
deal
with,
but
yeah
yeah.
B
B
Yeah
there's
a
lot
of
things
that
make
it
interesting,
which
is
why
we're
very
attracted
to
it.
But
it
then
it
came
down
to
a
question
of
like
well:
did
tracing
itself
need
this,
or
is
it
just
like
something
that
was
interesting
that
opened
up
other
possibilities
at
the
expense
of
making
the
API
more
complicated
and
making
some
people
who
didn't
want
ref
counting
upset?
So
that's
that's
where
we're
pulling
down
and
then
we
have.
F
B
J
So,
as
I
said
before,
what
we
are
waiting
for
is
the
for
the
in
process
context
propagation
to
get
merged
in
Python.
I,
don't
know
if
I
mentioned
this,
but
I
talked
with
the
output
of
the
pull
request
in
Python,
and
he
told
me
that
this
thing
is
going
to
get
merged
soon.
So
once
we
have
that
we
are
ready
to
merge
because
basically
or
pull
request
is
way
more
simpler
than
the
we're
having
with
Java
and
it's
almost
a
1:1
and
mapping
with
the
Python
one.
J
B
I
would
second
that
personally
I've
looked
at
the
work
you're
doing
the
work
man
is
doing
in
Python
and
they
look
very
similar
I,
don't
I,
don't
think,
there's
there's
any
radical
changes
that
are
going
to
occur
or
places
where
the
naming
conventions
are
going
to
get
stray
too
far
from
each
other.
So
personally,
I'm
fine
with
pulling
it
in
and
I
know.
Yet
you
sounds
like
you're
feeling
some
pressure.
You
know
people
are
adopting
it
so
yeah.
J
That's
that's
the
thing
that
worries
me
more
because
people
is
adapting
it
and
I.
Don't
know
if,
like
there
is
already
a
use
case
for
production
systems
in
terms
of
a
like
instrumenting
common
frameworks
without
the
in
process,
contact
propagation
is
not
possible,
but
I
don't
know
if
that
is
a
use
case
for
people
already.
I,
don't
know
like
how
they
are
using
it,
but
like
I
saw
that
there
are
people
using
the
library
and
that's
that's,
maybe
something
we
should
prioritize
great.
B
B
D
One
question
really
quickly:
API
at
the
open
tracing
layer
has
some
kind
of
flush
mechanism
built
in
because
one
of
the
challenges
PHP
at
least
in
its
like
normal
kind
of
like
Apache
ish
mode.
It's
it's
like
you
know
you
have
to
you,
have
to
flush
the
trace
around
every
request
and
in
the
past
it's
been
a
sort
of
an
interesting
design
question
as
to
whether
or
not
that
flash
is
part
of
the
open
tracing,
API
or
the
part
of
the
tracer.
Api
is
exploitation
which,
like
creates
that
tight
coupling
I
was
just
curious.
D
J
They
had
the
same
concern
about
one
request:
one
flash
and
I
open
it,
a
issue
in
my
sip
in
library
for
discussing
this
stuff.
It's
called
bull
reporting,
but
I
will
share
with
you
guys
in
the
chat
and
basically,
whenever
Lake
came
up
with
his
own
experience,
because
he
is
maintaining
a
vendor
called
hideaways
and
he
explains
the
way
they
do
and
how
most
of
the
PHP
IP
and
does,
which
is
that
they
drop
the
traces
in
through
the
tcp/ip
protocol.
And
then
there
is
something
collecting
collecting
the
sponge.
J
But
basically,
you
do
a
light
flush
on
every
request,
because
you
cannot
there's
no
way
you
can
keep
a
a
state
in
PHP
but
like
this
is
a
like
low
overhead,
a
flood,
low
overhead
flush
and
then
all
the
work
is
done
by
a
collector
Barbara
and
another
option
we
explore
was
to
basically
drop
all
the
sponge
into
a
file
and
then
having
again
a
collector
worker
like
getting
the
sponge
from
the
file
and
drop
into
the
collector
problem
with.
That
is
that
we
have
some
other
complexity,
which
is
what,
if
I,
do
a
deploy.
J
What,
if
it's
containerized
at
what,
if
like
yeah
some
other
stuff
so
and
this
issue
that
I
share,
has
most
of
information
from
them
and
that's
the
approach
we
will
have
from
sipc
in
from
open
tracing
perspective.
I,
don't
think
this
is
something
that
should
be
part
of
the
library.
But
of
course,
this
cost
of
these
kind
of
discussions
are
very
cuddly,
and
maybe
we
should
point
out
this
war
flow
somewhere.
I.
D
Think
it's
it's
probably
best
to
be
cautious
in
it,
which
is
to
say,
like
you
could,
leave
it
out
of
the
main
API,
but
putting
something
in
the
readme
about.
You
know
just
like
calling
out
that
this
is
a
really
vidya
matically
common
thing
and
like
how
to
how
to
deal
with
it
in
practice.
It
seems
like
a
nice
compromise
for
the
short
term,
but
I'm
flexible
I
was
just
curious,
there's
something
that
PHP
has
always
been
kind
of
a
challenge.
D
J
So
yeah,
that's
true
I,
so
I
open
it
another
issue,
but
it's
in
the
open
tracing
spec,
which
discusses,
which
was
I
mean
to
discuss
something
similar.
But
since
we
might
take
some
other
approach
because
the
current
approach
was
and
it's
the
approach
that
has
also
lie
step,
which
is
that
every
request,
once
you
deliberate
the
hitters
and
the
body
of
the
response,
you
do
the
flush
in
the
after
shutdown
hook.
J
E
It's
just
case
for
me
a
lot
of
problems
it's
hard
to
debug
in
the
not
only
simple
place,
but
when
you
have
a
some
complicated
case
and
hard
to
find.
Where
is
this
your
Spanish
finish
or
not?
Yes,
go
prepare
much
more
clear
and
easy,
and
actually
all
tracing
libraries
I
can
replace
with
scope
API
without
continuations.
E
B
F
B
I
felt
like
the
feedback,
we're
getting,
it
seemed
just
cleaner
and
made
more
sense
to
have
it
the
default,
be
it
doesn't
do
that
we
made
it
initially
the
default
that
it
did
because
it
seemed
convenient
and
then
we're
getting
feedback
that
that
was
confusing.
But
but
that's
definitely
a
good
good
point
to
bike.
Should
ever
I
don't
know
if
you
have
an
opinion
on
that
Gary.
B
K
B
B
Api
works,
fine,
awesome,
okay,
I
think,
that's,
that's
everyone!
There's
this
list
turns
out
to
not
be
stable,
so
I
call
is
I
if
I
miss
someone,
so
please
speak
up
if
I
did,
but
the
I'd
like
to
move
on
to
sort
of
discussing
next
steps.
Since
we
we
seem
to
be
in
agreement
that
this
should
go
in
in
particular,
I
think
we
shouldn't
just
pull
the
trigger
and
merge.
B
It
I
think
personally,
I
think
we
should
give
people
a
chance
through
some
outreach
to
let
them
know
that
it's
coming
and
I
also
wonder
about
whether
or
not
there's
any
backwards
compatibility
or
other
work.
We
want
to
do
such
as
getting
instrumentations
ported
over
or
something
of
that
nature
before
pulling
the
trigger
versus.
B
C
B
B
I'd
hate
to
open
up
the
bike
shed
of
like
did
we
name
everything
correctly,
but
I
guess
there's
one
last
chance
to
have
an
it
around
some
of
these
names.
My
only
concern
there
would
be
names
if
somehow
something's,
just
not
perfectly
symmetrical
like.
We
have
like
activate
and
closed
versus,
activate
and
deactivate.
For
example,
things
like
that,
but
I
really
don't
want
to
bite
said
about
names,
but
something
does
seem
like
it's
confusing
the
language
when
we
write
Docs.
That
would
seem
important.
A
C
C
B
B
All
right,
there's,
certainly
a
question
about
backwards,
compatibility
or
like
bridges
for
adoption,
because
the
the
current
API
has
been
out
there
for
a
while
a
number
of
tracers
have
bound
to
it.
A
lot
of
people
have
instrumented
with
it
I'm
curious
what
we
people
think
we
we
should
do
what's
like
critical
as
far
as
providing
some
support
to
take
the
pain
away
there.
B
This
is
where
my
personal
lack
of
Java
expertise
really
shows
its
head.
I
know:
there's
got
to
be
some
tricky
things
around
now,
having
like
two
flavors
of
the
same
API
that
are
in
the
same
namespace,
potentially
and
wanting
to
make
shims
and
things
and
how
that
gets
a
little
complicated,
but
I'd
love
to
hear
people's
thoughts
on
that.
C
B
And
I
would
say
like
the
sort
of
inverse
of
that
as
well
like
we
want
to
probably
retain
a
flavor
of
these
things
for
the
existing
API
right,
like
on
a
branch
and
a
question
actually
came
up
there
during
this
process
around
what
the
naming
conventions
should
be.
If
you're
trying
to
tag
a
version
of
your
library
to
be
with
this
API
versus
another
one.
It's
a
bit
odd
I
mean
people
usually
would
just
have
versions
of
their
library,
but
especially
with
like
a
release
candidate.
B
B
Yeah,
well
certainly
it's
going
to
take
people
who
have
instrumented
their
applications,
potentially
a
while
to
port
over,
but
an
alternative
is.
Is
it
actually
easier
to
provide
shims
for
for
tracers,
and
with
that,
would
that
make
life
easier
for
people
I
guess
it
would
make
life
easier
for
application
developers.
They're
gonna
be
stuck
on
30
for
a
bit
and
then
want
to
move
over
I.
D
Mean
it
seems
to
me
that
if
we
had
a
shim
that
that
at
least
syntactically
supported
the
30
API
and
would
take
a
31
tracer
as
a
parameter,
I'm,
not
totally
totally
positive,
as
I
think
that
that
could
be
done
without
a
great
deal
of
difficulty.
Then
application
owners
would
have
a
way
to
like
bridge
instrumentation
and
tracer
owners
wouldn't
really
need
to
care
that
much
about
this
like
they
would
need
to
support
31
and
then
the
shim
could
be
an
answer
and,
in
the
worst
case,
to
support
30
for
a
long
time.
D
That
I
think
the
biggest
sort
of
annoyance,
in
my
mind,
is
that
they
both
live
in
the
same
Java
package
and
having
you
know
like
having
a
sham,
be
an
IO
and
racing
as
well
as
the
as
the
non
shim
could
be
sort
of
problematic
and
I.
Think
it
would
probably
require
like
an
iota
of
increase
in
touch
him
or
something
package.
That
and
and
like
I,
changed
the
code
that
would
like
involved
modification
to
import
paths
or
something.
It
seems
like
that.
D
The
kind
of
stuff
that
seems
really
nasty
to
me
frankly
like
if
someone
here
who
has
a
lot
of
experience,
doing
shading
and
figuring
out
how
to
get
all
the
palms
have
to
fit
together
and
can
like
tell
me
this,
isn't
a
big
deal
that
would
be
relief
but
like
if
we
can
get
that
to
worse
and
all
these
other
problems
can
go
away.
I'd
be
curious
to
hear
what
someone
with
with
like
deep
knowledge
of
kind
of
Java
jar
or
madness
like
had
an
opinion
about
that.
C
From
what
I
understand,
having
an
application
with
certain
classes
on
the
class
path,
so,
for
example,
spam
with
that
they
expect
and
then
a
tracer
unmodified
coming
in
with
the
same
span
class
that
that
it
expects
it
a
bit
of
a
but
of
a
different
structure.
I
think
it
would
be
really
difficult
to
create
a
shim
that
would
be
able
to
translate
those
effectively
given
Javas
class
path.
Behavior.
D
B
Yes,
if
people
need
need
to
drop
off
the
call
that
that's
understandable,
I
think
we
can
continue
this
discussion
on
on
get
er
as
far
as
what
next
steps
are,
I
guess
one
final
thing:
maybe
do
we
want
to
just
give
out
a
release
date
to
people?
Does
anyone
have
an
issue
if
we
move
fast?
That
would
be
my
final
thing
like
if
we
said
to
people
we're
going
to
release
this
a
week
from
today,
or
you
know
eight
or
nine
days
from
now.
B
C
C
B
Yeah
I,
don't
know
just
how
far
out
that
I
would
like
to
announce
that
date
soon
right,
I
want
people
to
be
like
this.
Is
your
last
chance
to
have
a
look
at
this
I.
Just
don't
know
how
much,
how
much
time
we
should
associate
with
that.
If
it's
a
week
or
two
weeks,
person
I
think
two
weeks
is
sufficient.
B
B
Okay,
if
anyone
else
has
has
interest
in
this,
let's
continue
the
discussion
on
Kidder
and
like
Tyler,
suggested.
Let's
let,
let's
create
some
tracking
milestones.
I'll
update
the
github
issue.
That's
been
tracking
this
project
with
this
information,
but
we
should
also
think
about
who
we
want
to
reach
out
to
and
create
a
list
of
people.
We
want
to
lurk
in
about
this
specifically
I'm
thinking
about
tracing
vendors,
who
might
have
bound
to
this,
but
aren't
you
know
involved
enough
that
they
come
to
these
calls,
and
maybe
our
watching
getter
in
sadhana
I'm.