►
From YouTube: 2022-07-20 meeting
Description
OpenTelemetry PHP SIG Meeting
B
B
A
Sure
so,
basically
my
pr
is
about
v3
propagators.
I
have
implemented
a
multiheader
propagator.
This
pr
is
for
single
header
propagators
and
according
to
open
telemetry
specs,
we
don't
have
all
the
matching
fields
between
b3
propagators,
the
keys
in
the
breathy
propagators
and
our
open,
telemetry
specs.
So,
based
on
that,
I
have
implemented
both
of
them.
The
configuration
also
requires
an
extra
additional
class
that
handles
both
of
these
propagators.
So
basically
you
have
to
create
one
class
by
default.
A
A
Yeah,
so
what
happens
is
I
want
to
test
it?
I
want
to
see
if,
let's
say
first,
it
picks
up
b3
by
default
or
not,
but
as
soon
as
I
do
get
instance
for
that,
in
that
test
case,
it
will
set
it
as
b3
single
only
throughout
the
entire
test
case.
So
whatever
test
cases
I
write
next,
they
are
going
to
fail.
So
I
just
wanted
to
know
why
they
are
implemented.
As
singleton.
I
looked
at
open,
telemetry,
js
and
open
telemetry
python
in
js.
They
don't
have
a
static
class.
A
I
mean
whenever
they
want
to
use
this
propagators.
They
just
create
a
new
object.
Out
of
that,
I
am
not
sure.
What's
the
reason
behind
the
static
class
implementation
for
this
propagators,
I
know
yeah,
but
once
we
initialize
them,
I
mean
we
just
want
to
send
them
right,
so
maybe
it
would
be
redundant
to
create
new
copies
of
this
classes.
Every
time
we
want
to
send
some
header,
but
that
is
causing
the
issues
with
the
unit
testing.
B
A
I
mean
it's
implemented
across
all
the
propagators,
so
if
you
pick
up
any
file
that
I
have
changed
in
that
pr
right,
we
are
implementing
yeah
singleton
class
for
all
the
propagators
we
yeah.
We
trace
context
everything
so
I
mean
initially,
there
was
only
this
trace
context,
propagator
and
that
was
implemented
by
a
singleton
class.
So
that's
what
I
carry
forward
with
this
b3
propagators.
B
B
It
was
teemo
that
did
that,
so
we
should
probably
ask
him
he's
not
here
today,
but
I
saw
you
tagged
him
in
the
pr.
I
can
I'll
follow
up
with
him
and
ask
him
about
that
and
see
if
he
can
get
you
an
answer,
because
that's
unfair
for
you
to
be
waiting
around
for
this
pr,
because
he's
yeah
I'll
follow
up
with
him.
B
C
Yeah,
so
this
is
the
issue
number
415
use
of
need
it
across
the
repo.
So
in
this
issue,
basically
in
few
cases
across
the
repo,
we
are
checking
whether
an
iterable
is
empty
or
not.
So,
basically,
in
most
cases
when
the
I
triple
is
in
the
form
of
array
and
this,
if
there,
if
it
is
empty,
the
anti-function
will
get
true,
but
in
case
of
exhausted
generators,
basically
it
will
give
false.
So
that
was
the
bug
that
was
given
this
issue.
C
Basically,
so
I've
made
the
changes
and
for
review
so-
and
I
have
also
means
correct-
used
my
function
in
which
they
are
created
in
few
of
the
occasions
in
which
it
was
used
in
the
repo.
So
you
can
take
a
look
and
let's
means
when
I
get
the
review
comments,
I
will
also
write
the
update
the
unit
test
cases.
I
have
not
updated
the
unit
test
cases
for
this.
Okay
once
it
is
reviewed.
B
B
C
B
B
A
B
B
I
think
it's
sort
of
a
chicken
and
egg
problem
to
me,
because,
if
we're,
if
our
library
isn't
in
beta,
then
these-
I
think,
let
me
say
this
a
different
way
when
our
library
becomes
data.
I
think
a
lot
more
people
will
take
a
vested
interest
in
having
their
libraries
or
frameworks,
or
you
know
what
have
you
instrumented
with
open
telemetry?
I
think
a
lot
of
people
see
free
beta
as
no
thanks
for
not
touching
that
yet
because
it's
not
ready.
B
A
D
Yeah
just
to
add
what
crystal
is
talking
definitely
auto.
Instrumentation
is
something
which
is
important
for
any
open
telemetry
as
a
php,
the
python
and
other
php.
Definitely
that's
the
something
which
is.
We
are
finding
the
gap
internally.
It
is
a
number
and
also
some
case
who
work
from
my
team.
We
are
discussing
this
thing
internally.
D
We
do
have
some
proposal,
so
that's
what
person
is
mentioning
there
might
be
some
additional
ask
when
we
plan
for
the
auto
instrumentation
one
of
the
things
and
if
you
can
mention
about
that
c,
plus,
plus
sdk
or
maybe
c,
plus
plus
dependency
right.
So
all
those
things
we
will
be
talking
but
about
the
whole
idea
is
come
up
with
the
proposal.
Seek
the
input
from
you
guys
and
whatever
agreeable
thing
should
start
doing
this
auto
instrumentation
as
quickly
as
possible.
B
That's
that's
great.
I
think
that
I
think
that's
a
good
mindset
too.
I
think
I
have
a
feeling
that
when
we
go
to
beta
we'll
get
a
lot
of
really
great
feedback
and
I
have
a
feeling
that
auto
instrumentation
will
be
towards
the
top
of
that
feedback
chain.
So
I
think
the
more
that
we
can
be
prepared
for
that.
The
better
off
we're
gonna
be,
and
I'm
gonna
be
very
happy
to
read
your
proposition
and
probably
I'm
sure
that
we'll
have
a
lot
of
really
great
back
and
forth
with
them.
D
Absolutely
that's
the
thought
we
have
so
yeah
come
up
with
a
proposal
and
as
soon
as
you
are
ready,
bring
it
to
here
in
the
meeting,
and
we
will
discuss
and
bob
you
before
this
you
were
saying
definitely
about
beta,
express
and
we
want
to
complete
hbp
as
possible
and
last
time
I
remember
we
were
talking
about
the
timeline,
though
we
didn't
have
commitment.
Do
you
have
any
sense?
When
can
we
reach
at
the
beta
scale?
What
is
the
current
status.
D
Oh,
that's
great,
it's
only
two
things
so
once
these
things
are
done,
then
we
will
have
our
beta
and
before
even
after
completion
of
these
some
of
the
pr
is
there
any
other
plan
to
have
the
formal
integration,
testing
or
those
kind
of
thing
or
those
things
are
always
happening
as
a
part
of
each
individual.
Pr.
B
D
Yeah
so
let's
have
even
further
discussion,
I'm
sure
in
next
week
or
probably
in
a
two
week,
we
will
have
more
progress
and
I
would
be
definitely
more
than
excited
as
soon
as
we
have
the
beta
announcement,
because
sometimes
it
becomes
the
checkpoint.
Also,
though
community
you
guys
are
putting
so
much
effort,
but
whenever
people
say
oh
php
is
still
not
in
beta
state.