►
A
Hey
everybody,
so
I
will
be
in
scene
today.
We've
got
a
fairly
detailed
agenda
if
you
all
can
pull
that
up.
That
would
be
great.
My
plan
is
simply
to
go
down
the
agenda
as
someone
who
is
related
to
one
of
these
projects
to
speak
about
it
and
it
snows
around
I'll
give
a
brief,
brief
overview,
familiar
with
most
of
them
just
kicking
it
off.
A
B
A
It
would
be
great
to
consolidate
a
bunch
of
examples
into
one
place
and
eventually
put
that
stuff
up
on
the
web
website
and
there's
also
been
talk
about
yet
maybe
like
an
open
tracing
cookbook
or
something
along
those
lines,
especially
with
the
active
with
the
improv
test
content
in
process
context
propagation.
There.
There
are
some
patterns
that
are
still
a
little
tricky,
so
it
would
be
great
to
just
have
all
the
all
the
instrumentation
patterns
in
one
spot.
A
A
A
A
C
C
C
C
A
Cool
that's
interesting.
I.
Do
like
the
idea
of
combining
your
metrics
for
tracing
and
combine
your
implementation
for
tracing
it.
I
think
we've
got
a
Java
metrics
project
at
the
bottom
of
our
agenda
list.
Here,
that's
beginning
an
attempt
to
do
that
through
token
tracing.
So
that's
interesting
that
they're
also
also
going
that
direction.
A
Okay
enough
about
them.
Let's
talk
about
us
so
there's
a
number
of
API
updates
coming
along
three
languages
in
particular,
are
getting
an
overhaul,
but
what's
interesting
is
they're
all
at
different
states,
so
python
has
been
in
production
and
is
now
adding
the
in
process
context
propagation
stuff
that
we
added
to
Java.
So
that's
going
on,
there's
also
PHP
a
prior
to
this
point.
We
haven't
had
an
official
PHP,
instrumentation
API,
so
that's
coming
along
and
then
C++.
A
There
was
some
work
being
done
on
a
C++,
98
API,
but
we
decided
to
set
that
aside
and
go
with
a
C++
11
API
for
now
and
then
maybe
come
back
to
that
98.
So
that's
a
quick
overview
of
the
three
languages
that
are
seeing
some
changes
and
then
there's
also
some
discussion
around
API
rollout
and
compatibility
practices.
We
got
feedback
from
Java
when
the
latest
Java
roll
out
went
out
and
there's
a
room
for
improvement
there
and
so
I
think
we
can
talk
about
that,
especially
in
the
context
of
Python.
A
A
A
A
A
Maybe
going
once
going
twice:
okay,
well,
there's
always
getter,
and
you
can
of
course
check
out
this
pull
request.
So
next
one
up,
there's
PHP!
This
is
brand
new.
A
couple
people
are
working
on
different
implementations
and
I.
Think
they're,
trying
to
boil
it
down
to
one
implementation
is
Felix
on
the
phone.
I
think
I
saw
him
or
maybe
a
mr.
Chavez,
but.
E
E
Bam,
Bam
and
sadek's
have
been
collaborating
with
me
and
reviewing
the
pull
request
in
order
to
get
rid
of
the
concerns
they
had
with
a
original
implementation.
We
arrived
to
a
point
that
more
or
less
we
all
were
happy
with
what
we
have
in
there
in
the
existing
library
and
anyways
we
would
like
to
as
we
were
discussing
earlier
with
them.
C
F
A
That's
an
interesting
question:
I
think
the
main
pocket
is
probably
picking
you
know
which
which
implementation
we
were
going
to
go
with
as
a
baseline,
I.
Think
if
everyone
who
has
been
involved
in
the
PHP
effort
is
agreed
that
you
know
there
is
an
implementation
that
is
like
mostly
correct,
probably
move
it
in
as
a
release
candidate,
just
to
get
people's
attention
on
it
and,
to
kind
of
you
know,
scope
a
bit
and
then
continue
to
refine
it
from
there.
A
G
E
A
Awareness
of
it
as
long
as
there's
something
slapped
on
the
readme
that
lets
people
understand
what
what
state
is
currently
in
I
think
that's,
probably
the
most
important
thing.
So
people
don't
relying
on
it
without
the
understanding
that
that
there's
a
you
know,
this
is
a
release
candidate,
there's
a
couple
big
changes
that
are
best
to
come
in.
So,
okay.
F
E
Something
I
am
I
would
like
to
to
do
is
to
gather
some
ideas
about
how
we
can
get
more
feedback
from
some
other
people
like
which
we
have
been
discussing
it
very
but,
like
I,
don't
know
it
will
be
nice
to
have
a
chat
with
someone
who
actually
implemented
like
in
my
company.
We
were
about
implemented
and
the
ways
puzzles
with
these
gentlemen
about
the
Thunder.
After
that,
we
will
go
for
it,
but
it
will
be
nice
together.
Some
some
other
information
from
from
the
community
yeah.
G
You
talk
about
getting
a
couple
different
language
bindings
in
and
getting
the
active
active
spam
stuff
included.
What
strikes
me
is
when
I
book
a
token
tracing
IO.
The
conceptual
model
doesn't
mention
anything
about
active
spam,
so
that
there's
some
kind
of
a
gap
in
the
docs
here,
if
it's
possible
to
add
something,
that's
that
important
and
it
doesn't
affect
the
conceptual
model
which
are
publishing.
So
somebody
could
address
that
yep.
E
Something
I
also
mentioned
it
to
them
earlier
is
that
in
some
pull,
requests
about
activists
and
I
saw
that
they
pointed
out
something
about
the
specifications
0.3,
which
doesn't
show
anywhere
at
least
I
couldn't
find
it.
So
it
would
be
nice
to
give
more
visibility
to
this
and
maybe
to
link
in
the
libraries
we
started
with
this
changes
for
the
new
features.
E
A
Yeah
I
think
there
could
be
more
work
done,
I
think
opens
racing
in
general
needs
kind
of
a
documentation,
overhaul
and
well.
The
basic
model
in
the
specification
I
think
is
good.
The
the
actual
language
of
the
specification
could
probably
use
some
work.
It's
very
English
II
there
areas
I
think
we
know
where
it's
not
specific
enough
or
these
questions
that
keep
coming
up.
So
there's
there's
definitely
a
round
of
refinement
that
could
be
done
there
sort
of
a
chicken
egg
thing
of
like.
When
do
we
do
that?
A
G
A
Exactly
I
would
I
would
love
to
see
a
a
a
sort
of
effort
to
kind
of.
Maybe
we
can
open
an
issue
on
the
specification
and
kind
of
catalog
start
cataloging.
Some
of
these
things
I
think
it
would
be
great
to
maybe
get
a
chunk
of
it
together
and
attack
it
that
way.
First,
if
someone
would
like
to
start
that,
that
would
be
great.
A
As
far
as
like
the
actual
roll
out
and
getting
attention,
I
do
think
that's.
The
main
thing
we
need
to
hash
out
with
AP
is
there's
issues
around
like
backwards
compatibility
guarantees
that
we
need
to
really
start
paying
attention
to,
but
even
without
those
in
case
of
PHP,
for
example,
there's
still
this
question
of
when
you
roll
it
out,
how
do
you
know
you've
gotten
enough
attention?
How
do
you
know
you've
gotten
the
right
kind
of
attention?
F
F
H
A
H
I
haven't
been
working
on
it
personally
over
the
last
few
weeks,
so
I'm
a
little
bit
out
of
touch,
but
I
talked
with
Manu
earlier
he
wrote
me
a
brief
summary
I
think
it.
Basically,
he
basically
said.
Let
me
recap
that
there's
like
three
up
basically
I
think
sounds
like
Ben
and
maybe
Carlos
are
leaning
towards
having
a
more
of
a
direct
port
of
the
Java
API.
A
My
understanding
is
some
of
the
debate
has
to
do
with
what
what
should
be
supported
as
far
as
context
management,
in
particular
callbacks,
you
know
just
create
user
land
functions
should,
which
is
how
tornado
used
to
do
things
should
that
be
supported,
and
that
I
think
complicates
things
if
you
want
to
go
all
the
way
up
to
that
edge
and
such
a
check.
That's
one
of
the
debates
there
yeah.
A
H
Don't
I
don't
think
I've
been
like
plugged
in
enough
to
like
chime
in
on
my
opinion.
I
do
want
us
to
see
us
like
a
I.
Think.
The
most
important
thing
is
that
we
figure
out
how
we
need
to
make
a
decision,
and
you
know
the
people
who
want
to
make
a
decision
and
just
make
a
call-
and
you
know
hopefully
drive
that
a
little
bit
we'd
be
good.
Yeah.
H
I
think
that
I
think
it's
going
to
be
actually
tricky
to
find
somebody
for
that
last
that
edge
that
people
are
actually
concerned
about,
because
I,
don't
think
people
actually
write
code
that
way
in
practice.
So
but
I
also
can
understand
why
you
want
the
foundation,
no
underpinnings
to
be
as
sound
as
possible.
So
yeah,
okay,.
A
Well,
yeah,
we
definitely
should
in.
We
won't
be
able
to
solve
it
in
this
meeting,
but
people
please
check
out
the
poor
quest
and
then
there's
also
just
like
PHP
open
tration
Python
has
its
own
sub
room
where
this
stuff
can
be
debated
in
detail,
so
we
should
get
people
in
there.
Maybe
we
have
a
roundtable
specifically
around
the
Python
thing
at
some
point,
maybe
next
week
or
after
you
guys
get
it
to
a
spot
where
we're
bono-
and
you
and
Carlos
are
happy
with
it.
A
Cool
okay,
moving
on
to
C++,
11
I,
don't
think
Brian
is
on
the
call
Ryan
you
happen
to
be
coming
around
I,
don't
think
he
is.
That's
fine
I'm
happy
to
talk
about
this
a
bit.
So
what
the
way
things
were
going
in
C++
was.
There
was
an
attempt
to
make
a
sort
of
98
API
and
the
idea
would
be.
You
would
then
maybe
wrap
that
API
in
a
C++
11
API.
A
That
would
be
nicer
and
there
was
a
lot
of
bike
shedding
and
no
one
really
came
to
an
agreement
on
what
that
98
API
should
look
like
and
it
never
got
really
finished.
In
the
meantime,
a
number
of
tracers
had
C++,
implementations
and
stuff
started
getting
instrumented,
basically
with
open,
trace
and
compliant
tracers,
but
without
using
the
C++
API
and
that
got
kind
of
far
enough
along
in
things
like
envoy
and
engine
X
and
other
places
where
we
started
to
feel
like
there
was
this
backlog
of
stuff.
A
A
I'll
do
again
as
part
of
API
rollouts
try
to
actually
pass
some
people
to
actually
implement
this,
which
I
think
will
end
up
basically
being
me
and
Ryan,
and
some
people
will
try
to
make
sure
there's
at
least
as
disk,
in
C++
implementation
that
binds
to
this
and
works
in
envoy
and
then
we'll
instrument
envoy
with
that.
And
that
will
be
the
sort
of
proof
of
concept
that
this
new
API
is
workable.
A
E
A
Yeah
there's
been
I,
do
recall,
someone
coming
in
together
and
asking
whether
or
not
there
was
something
in
C
and
I
believe
you
got
pointed
at
the
right
place.
There's
currently
no
there's
nothing
written
in
C.
Currently
so
far,
we've
had
success
because
these
things
tend
to
be
plugins
being
able
to
to
bind
in
with
the
C++
11
API.
Even
if
the
original
stuff
like
in
genetics
is
written
in
C,
they
usually
allow
these
kinds
of
instrumentation
plugins
to
be
written
whatever
you
want.
So
we.
A
Haven't
seen
a
need
yet
for
an
API
like
that,
and
there
was
just
a
lot
of
difficulty
finding
an
agreement
on
it
on
an
API
that
was
at
the
C
and
C++
98
level,
so
the
new
API
specifically
has
a
space
in
the
repository
for
a
98
implementation
to
go.
Should
someone
want
to
to
pick
that
back
up
and
start
working
on
it?
A
Alright,
moving
on,
we
talked
a
bit
about
API,
rollout
and
compatibility
practices
in
the
context
of
these
3
AP
is
I
think
this
is
civil,
a
work
in
progress
in
open
tracing.
There
is
a
an
issue
that
is
linked
to
in
the
agenda
about
hashing
through
what
it
is
that
that
we
actually
want
and
then
we're
going
to
you
know
kind
of
have
the
next
practice
run
at
this
will
be
a
Python
and
then
and
then
PHP.
A
B
H
A
A
G
So,
in
terms
of
the
criteria
per
saying,
is
release
ready,
you're
going
to
do
it
purely
based
on
the
API?
Or
do
you
want
to
make
sure
that
you
have
a
couple
of
library
instrumentations
working
with
this
API
to
code
like
what's
MVP
here,
I
hate
to
sound
like
marketing
guys,
but
I
have
to
yeah.
Well,
like
someone
say,
doing
a
spring
implementation
and
haven't
actually
proven
it
out
with
the
API
I
think
is
still
a
gap.
Yeah.
A
A
B
A
So
we
can
at
least
you
know,
feel
like
like
it's
been
vetted
and
and
works,
and
also
that,
like
people
in
the
community
are
aware
that
this
is
coming
when
no
one
feels
like
it's
just
something
that
landed
on
top
of
them,
so
yeah
I
don't
have
a
specific
plan
for
how
we
do
that.
But
I
agree
that
we
need
something
like
that.
What's.
C
The
what's
the
world
look
like
for
testing
tracers
for
the
Java
stuff.
You
know,
I've
been
working
on
the
test
suite
for
the
go,
tracer
implementation
and
I
was
I,
didn't
see
anything
similar
to
the
Python
or
go
harness
for
Java
and
I
caught
a
lot
of
bugs
in
my
tracer.
You
know
just
having
to
read
the
spec
and
then
writing
tests
against
it
and
then.
E
C
D
I
think
it
would
be
really
helpful
to
have
like
a
standardized
test
suite
such
that
I.
You
know
you
call
to
API
is
in
a
standard
way
and
have
it
just
returned
something
up
that
it
can
then
be
verified
in
a
cross
language
compatible
way.
I
understand
that
not
all
tracer
implementations
produce
traces,
but
I
still
think
it
would
be
a
useful
abstraction,
yeah.
C
C
Bullets
here
and
the
fourth
one
says:
oh,
it
doesn't
exactly
specify
another
turn
for
this
error
case,
but
I
just
assumed
it
meant
another
term
a
night
when
coded
up
the
test
against
that
and
my
own
kitchen
does
that
but
I
didn't
add,
you
know,
there's
a
lot
of
wit,
there's
a
lot
of
differences
between
traces
that
programmers
might
assume.
You
know
the
return,
values
and
other
things,
and
also
just
checking
the
probability
against
context.
Propagation
I've
got
to
check
if
you're
trying
to
write
two
different
baggage
values
with
case
insensitive.
C
C
Okay,
nil
and
error
values
a
lot
of
stuff
around
our
values
and
our
returns
and
there's
some
stuff
done
baggage
check
in
the
context.
Propagation
yeah
Irene
is
fabulous.
You
can
pretty
much
port
all
this
straight
to
Java
I
assume
with
some
magic
on
yeah.
It
was
a
lot
of
the
similar
comes
Danny,
yeah
I'm,
a
big
fan
of
test
coverage,
and
so
this
was
really
helpful.
For
me
getting
to
100%
test
coverage
from
my
tracer
yeah,
hey
Jaclyn,.
C
A
Be
great:
is
there
anyone
on
the
call
who's
interested
in
bottom
lining,
porting
the
test
harness
to
Java
and
by
that
lucky
I'm?
Never
that
lucky!
Okay,
we'll
do
some
community
wrangling
about
that.
But
let
me
see
I'm
going
to
add
that,
though,
as
a
thing
that
was
on
the
agenda
because
that's
where
these
its
own
own
things
here
I
would.
D
B
That
maybe
we
should
have
a
section
in
both
specification.
Repo
is
an
issue,
and
even
maybe
on
the
documentation
site
of
the
section
saying
that
these
are
the
high
priority,
think
that
we
need
people
to
either
look
at
or
culprits
and
like.
We
can't
decide
on
disclose,
which
are
the
high
priority
items.
A
D
A
A
Cool
okay,
so
I
think
that
that
concludes
talking
about
the
API
updates.
It's
9:10
so
go
20
minutes,
but
I
think
the
rest
of
stuff
a
little
bit
faster.
So
specification
updates
there's
a
number
of
various
outstanding
issues.
The
thing
I
I
flagged
just
for
discussion
here
to
kind
of
point
people
at
is:
you
know
as
time
goes
on,
there's
a
push
to
standardize,
more
and
more
tags
and
there's
a
question
about
like
well.
What
is
the
process
for
standardizing
a
tag?
A
Is
it
that
we
get
together
and
think
that
this
is
a
good
idea
and
there's
clear
use
case,
and
this
looks
like
good
solution.
So
that's
the
standard
and
then
people
adopt
it
or
do
we
first
go
and
kind
of
by
Fiat
are
giving
meanings
to
certain
tags.
Have
tracers
agree
that
those
tags
have
those
meetings
and
then
go
and
try
to
standardize
them.
A
So
that's
the
sort
of
basic
question
and
then
then
there's
also
the
question
of
like.
Is
there
like
a
literal
process
that
we
can
walk
people
through
like
certain?
You
know
just
how
does
something
get
approved
or
not,
and
there
are
several
outstanding
tags
that
are
being
debated
right
now
and
you
can
see
why
there's
some
debate
over
some
of
these
so
there's
a
protocol
tag.
That
seems
a
little
nebulous
to
me,
but
there's
obviously
a
need
for
something
like
it.
A
So
you
can
have
a
look
at
that
issue
and
then
there's
an
issue
with
log
level
for
people
who
are
doing
logging
and
other
things
with
their
they're
tracing.
Should
there
be
a
way
for
tracers
to
have
priority
or
some
other
mechanism
for
choosing
whether
or
not
they
report
these
logs?
So
those
are
examples
of
attempts
of
standardizing
tags
again:
I,
don't
I,
don't
have
a
great
answer
for
how
we
should
do
this.
There
is
a
discussion
thread.
A
H
Guess
I'm
just
interested
to
see
how
it'll
play
out,
like
maybe
I,
think
there
needs
to
be
sort
of
like
a
whip
cracker,
basically
who
forces
discussions
to
happen
and
we
try
to
like
have
some
sort
of
a
deadline
for
a
decision.
I
think
that's.
Basically
the
meeting
I
think
challenge
that
I
think
I'm
sort
of
seeing
yeah.
A
H
To
think
of
it,
just
like
trying
to
yeah
I
wouldn't
like
try
to
like
set
a
process
too
early,
but
at
least
maybe
having
a
timeline
on
like
a
reasonable
window
for
feedback
and,
like
all
of
the
core
group
I
think,
should
do
their
best
to
respond
within
that
that
window
and
if
you're,
not
you
either
take
it
as
a
sign
of
no
or
a
silent.
Yes
at
our
company,
we
do.
It
is
a
silent,
yes,
but
that's
way
easier
to
do
in
a
company
yeah.
A
I'm
willing
to
say
that,
because
we're
looking
at
making
a
standard
which
is
like
a
standard,
is
almost
a
purely
additive
process,
and
so
the
default
answer
should
always
be
no
I.
Think
URI
has
been
pretty
good
at
putting
his
foot
down
on
that
front
when
stuff
comes
flying
through
around
being
like
no
prove
that
we
need
this
prove.
This
is
the
right
way
to
do.
It
prove
that
there's
support
for
this,
but
yeah.
If
you
can
prove
that
there's
a
general
like
push
to
have
this
the
use
cases
of
real.
A
D
A
Yeah
I
think
that's
reasonable.
I
think
my
only
concern
with
the
do
it
for
standardized
later,
which
I
think
is
generally
correct,
is
like
what
happened.
If,
if
you
get
into
the
middle
of
it,
and
then
it
doesn't
go
that
way,
then
there's
like
stuff
out
in
production
and
in
various
places
that
that
works
in
a
sort
of
now
half
supported
manner.
A
D
Have
a
big
list
of
PRS
to
one
the
the
the
standard
document
plus
to
each
of
the
tracing
contributions.
But
then
you
have
a
bunch
of
PRS
and
I.
Think
that,
having
like
that,
proposals
in
a
PR
is
much
less
visible
than
having
it
in
the
actual
official
document,
with
like
a
tentative
flag
with,
like
maybe
a
proposed
date,
or
something
like
that.
Hi.
A
I,
like
that,
I
think
and
I
think
we
shouldn't
yes
totally
debate
the
whole
thing
here,
but
these
are
good
ideas
and
I.
Think
one
thing
that
was
brought
up
was
especially
in
particular
with
tags
or
specification
changes
in
general
there
being
an
incubation
period
where
we
agree.
This
does
look
like
standardized
herbal.
A
This
does
seem
valid,
but
you
still
want
to
yet,
like
you
say,
maybe
put
it
in
the
spec
or
otherwise
get
it
out
of
a
PR,
but
also
have
it
be
in
a
period
where
we're
still
allowing
ourselves
the
opportunity
to
change
our
minds
about
it.
If
it
turns
out
something
serious
that
we
didn't
think
about
it
first,
just
because
it
is
a
standard
and
we
don't
want
to
be
really
versioning
this
standard,
you
want
to
be
adding
things
to
it,
but
we
don't
want
to
feel
like
oh
changed,
everything
wait.
A
You
know
and
I
find
often
with
these
things,
the
the
the
effects
can
be
subtle.
So
you
don't
always
know
what
they're
going
to
be
when
you
first
start
and
that's
the
advantage
of
really
putting
things
through
their
paces
in
production
before
before,
adding
them
to
the
standard.
So
yeah
like
like
you're,
saying
something
that
lets
us
have
an
intermediary
zone
which
maybe
I'll
put
that.
A
A
That's
great,
but
I
do
think
like
something
you
mentioned
earlier,
Yuri
about
there
being
something
on
the
website
or
some
more
centralized
place
that
that
explains
people.
What
what
what
the
state
of
open
tracing
is
would
be
helpful
because,
when
you
go
is
hard
to
figure
out
what's
going
on
just
by
looking
at
the
see
of
github
issues.
Right
like
like
I
do
agree
that,
like
like
that
specification
issue
on
like
what
what
shall
be
the
process
for
doing
all
the
things.
A
It's
like
a
really
important
issue,
but
it's
just
like
hanging
out
there
right
next
to
you
know
other
stuff,
that's
like
hey
here's
a
bug.
Maybe
we
should
fix
yeah,
and
so
it's
just
hard
to
see
the
way
github
x'
UI
currently
works.
So
maybe
that's
really.
The
solution
is
have
something
that's
more
of
a
awareness-raising
place
that
people
can
get
used
to
checking.
A
A
One
is
spring
instrumentation,
so
something
I'm
kicking
off
with
a
Pavel
from
Red
Hat.
Is
it's
just
a
steady
increase
of
instrumentations
for
things
that
are
part
of
the
spring
framework
for
java,
and
we
would
like
to
create
a
repo
that
started
to
house
a
lot
of
auto
configuration
and
compatibility
tests
to
make
sure
if
you're,
using
all
this
instrumentation
together,
there
isn't
some
weird
transitive
dependency
problem,
basically
just
just
some
stuff
to
make
this
spring
tracing
ecosystem
more
coherent.
A
We
were
also
looking
at
a
fluke
which
is
a
sort
of
Zipkin
based
spring
instrumentation
system
to
see
if
we
could
plug
in
to
that,
rather
than
creating
like
a
parallel
pile
of
instrumentations,
but
that
looked
like
it
was
sort
of
a
bad
fit.
So
the
smooth
observer,
API
wasn't
really
designed
to
have
you
put
your
tracer
on
the
outside,
so
it
kind
of
works,
but
it
didn't
seem
to
be
sufficient
to
get
out
of
just
having
open
tracing
instrumentation
for
these
projects.
Other.
A
Are
not
at
this
point
we
did
talk
to
them.
They
may
be
very
valid
point
that
they
are
off
in
production
and
have
a
working
thing
and
the
open
tracing
API
is
while
they
look.
Fine
are,
you
know,
still
changing
right,
like
the
Java
thing
just
changed,
and
so
they
felt
like
it
was
too
soon
to
be
making.
You
know
made
a
like
major
API
change
on
their
part
to
support
this
stuff
and
I
also
think
their
model,
because
it
was
presumed
as
it
can
base
system.
A
For
example,
you
can
do
things
like
like
create
spans
and
whatnot
through
constructors,
outside
of
the
tracer,
but
in
open
tracing
gussa,
no,
no,
the
tracers
in
charge
of
that,
because
who
knows
what
that
span
is
that
is
created
so
stuff,
like
that?
I
think
means
that
it's
not
going
to
be
like
a
great
fit
until
they
decide
it's
like
very
important.
So,
oh
well,
I,
don't
think
it's
a
huge
deal,
though,
because
like
these
things
are
getting
instrumented,
naturally,
anyways,
just
they're,
just
like
instrumentations
for
these
various
components
are
just
rolling
in
rx.
A
Java
showed
up
like
a
couple
weeks
ago,
for
example,
so
I
think
we
just
want
a
repo
to
kind
of
corral,
all
this
stuff
as
it's
coming
in
alright
and
there's
a
github
issue
there.
If
you're
interested
in
that
it'll
hold
of
me
and
Papuan
gator
if
you're
interested
in
spring
instrumentation
Kafka,
just
a
quick
shout
out
here,
because
I
think
this
is
important.
A
The
latest
version
of
Kafka
version
11
supports
record
headers,
so
you
there's
actually
a
place
to
put
metadata
in
cop
canal,
and
so
we've
updated
the
Java
Kafka
client
to
to
use
this.
So
it
only
works
with
the
latest
version
of
Java
Kafka,
but
that's
a
pretty
pretty
major
thing
there
so
check
that
out.
If
you're
interested
in
Kafka,
this
would
probably
be
a
good
time
to
start
writing
open
tracing
instrumentation
for
Tosca
points
and
other
languages.