►
From YouTube: 2022-10-19 meeting
Description
OpenTelemetry PHP SIG Meeting
A
B
B
C
A
So
the
the
bottom
one
has
been
through
a
couple
of
reasons
of
review:
I
hope
it's
getting
I
hope
it's
getting
close
I,
don't
think
of
anything
to
say
about
that
one
and
the
SDK
Builder
is
how
I
am
hoping
to
fix.
The
my
last
required
for
beta
issue
is
that's
about
how
that
that's
as
far
as
Java
has
gone
and
as
far
as
I
can
tell
them
nobody's
gone
as
far
as
we
tried
to
go
with
it.
A
C
C
A
A
C
B
B
Yes,
so
my
first
question
was
whether
this
hooks
that
we
would
like
to
Define
for
different
Frameworks
should
be
a
part
of
this
open,
Telemetry,
PHP,
instrumentation
Repository,
because
for
now
it
contains
only
this
extension
and
I
was
thinking.
If
that
this
hooks
should
be
part
of
it,
or
maybe
this
should
be
another
package,
a
repository.
D
I
think
it
should
be
in
the
contract
repository
because
those
hooks
are
user,
contributed
stuff
and
not
directly
related
to
the
development
of
the
extension
and
users
can
then
pour
the
hooks.
They
want
similar
to
other
country
repositories
or
extension
repositories,
because
its
API
said,
but
I
wouldn't
put
it
in
the
same
repository
as
the
extension.
B
Okay
and
so
for
now,
I
added
it
here.
So
as
you
can
see,
there
are
two
files,
in
fact
hooks
stream
and
hooks
PHP,
which
is
kind
of
generic
thing.
But
now
the
the
question
is:
if
what
Tobias
you
said
so
then
user
will
be
preparing
these
hooks
or
I.
Don't
know
how
this
this
workflow
should
work,
because
probably
the
contributors
of
this
country
should
prepare
the
hooks
for
the
most
common
Frameworks,
I.
Think
and
then
a
user
can
extend
it
right
because
I'm
thinking
about
end
users.
D
B
B
A
B
A
A
D
D
B
And
the
next
finger,
it's
it's
related
to
the
to
this
collable
problem
is
about
getting
all
right,
all
right,
headed
so
so,
for
instance,
slim
framework
has
a
function
at
co-level
and
we
can
hook
into
it.
But
then
inside
this
function
there
is
a
Anonymous
class
created
and
there
is
a
handle
function
in
in
this
Anonymous
class,
which
calls
another
function
from
the
middleware.
But
the
question
is
if
in
this
case,
it's
also
possible
to
to
somehow
inject
into
this
handle,
for
instance,
where
I
have
this
Anonymous
class.
A
A
C
B
B
A
It's
I
mean
the
demo
itself
is
really
just
to
to
demonstrate
a
whole
lot
of
different
languages,
generating
Telemetry
and
it
all
working
together.
So
in
what
in
that
respect,
it
doesn't
really
matter
whether
it's
manually
or
Auto
instrumented
or
if
we
want
to
why
not
both
you
know
once
once
we're
comfortable-
and
you
know
our
Auto
instrumentation
is-
is
fairly
stable.
A
A
B
B
Because
we
we
don't
have
we,
we
will
not
prepare,
probably
cook
for
that,
so
user
can
prepare
hook
for
that,
and
in
this
case
probably
there
is
an
example
of
mixing
manual,
instrumentation
and
auto
instrumentation,
because
here
probably
user
need
to
to
add
these
calls
to
for
open
telemetric.
Do
you
agree
or
I.
B
A
B
C
A
A
B
C
B
A
A
A
Yes,
we
we
can
put
some
up
there
as
as
their
own
contributions,
sometimes
just
saying
that
we're
not
responsible
for
going
out
and
instrumenting
every
framework.
That's
that's
out
there,
but
certainly
a
few
a
few
of
the
the
more
popular
ones
we
should
definitely
do
and
that
we
we
encourage
users
to
test
them
out
for
us
and
that's
how
we
gain
the
confidence
that
the
extension
works.
A
B
A
Yeah,
that
was
just
a
question
for
the
absolutely
see
which
was
that
events
theme.
We
were
originally
thinking
of
that
as
a
way
to
probably
in
his
metrics
from
different
parts
of
the
instrumentation,
but
but
that's
that
there's
another
way
to
do
that
now,
so
we
actually
have
say
the
batch
process
at
the
meeting
Matrix
it
doesn't
need
the
event
system.
So
it's
there.
It's
not
doing
anything
and
I'm
not
I'm,
not
sure
what
what
its
purpose
is
anymore.
A
Timo
had
ideas
for
it
for
something
that
he
was
working
on,
but
that
hasn't
eventually
made
it
should
be.
So
the
question
is:
should
we
pull
it
out
or
I?
Don't
know,
Market
is
deprecated
or
just
ignore
it
for
a
while
and
pull
it
out
later.
If
we,
but
not
yet
I
can't
see
it.
You
saw
it
feeling
before,
but.
D
I
think
we
should
cop
it,
especially
because
Cloud
events
are
now
specified
in
the
spec
as
if
curtain
semantics,
that
we
don't
respect
currently
because
Cloud
events
are
mostly
for
entire
process
propagation
I'm,
not
how
we
currently
use
it.
For
you
know,
process
publication,
so
I'm
in
favor
of
removing
it.
A
A
Optimum
I
have
one
other
pull
request,
which
is
almost
ready
for
a
draft
which
is
to
buy
us.
It's
a
it's
an
offshoot
from
one
of
your
comments
on
one
of
my
other
pull
requests,
which
was
that
people
should
be
able
to
or
users
should
be
able
to
register
their
own
transguds
and
factories
So.
Currently,
our
exporter
Factory
has
knowledge
of
all
of
the
different
exporters
in
contrary,
which
is
a
violation
of
our
dependencies,
because
the
SDK
knows
about
contrary
and
it
shouldn't
be
so.
A
I'll,
get
one
more,
which
is
the
art,
was,
might
be
a
good
question
for
something
for
you,
guys
is
the
exporter,
so
we
can
currently
install
it
via
pickle.
Sorry,
not
the
exporter.
Sorry,
the
auto
instrumentation
extension
we
can
install
the
Via
vehicle
is
that
is
that
sufficient
to
what
we
think
it's
worth,
trying
to
look
into
having
it
published
on
vehicle
t-e-c-l.
B
C
B
A
True,
but
that
that's
that's
not
going
to
be
a
problem,
I
think
because
the
the
ecosystem
will
grow.
So
if
you
and
I
submit
instrumentations,
for
you
know,
slim
and
a
couple
of
those
things
and
someone
else
does
different
Frameworks
like
it'll
grow
and
demand
will
grow
and
yeah.
You
know
people
can
put
in
requests
for
new,
auto
instrumentations
and
I
actually
I
think
well
just
last
week.
A
What
do
you
know
a
a
template
for
for
that
people
creating
creating
issues,
so
people
can
request
them,
and
hopefully
random
developers
out
there
on
the
internet
will
create
auto
instrumentations
for
us
and
and
contribute
them
into
either
into
our
country,
repo
or
they'll.
Just
they
can
live.
They
can
live
elsewhere
as
long
as
they're
published
on
on
packages
and
discoverable,
then
then
they
could
be.
They
can
be
gotten
and
installed
from
there.
B
Okay,
maybe
one
thing
I
will
share
a
screen
for
for
a
moment,
so
I
was
thinking
that
this
Auto
instrumentation
should
work
in
the
way
that
when
you
have
this,
let's
say
main
main
file
of
your
application.
You
should
only
add
One
require,
and
this
requires
also
all
the
Frameworks
that
we
support.
So
do
you
agree
with
this
kind
of
approach,
I.
A
B
C
A
All
right
here
we
go
okay,
so
what
this
uses
is
just
this
little
file
called
register
what
it,
what
it's
called
it's
not
important,
but
it
it
runs.
Some
functions
to
register
middle
words.
Here's
my
Slim-
and
this
probably
looks
very
similar
to
the
one
that
we've
written-
and
this
is
the
new
cached
instrumentation-
that
device
distributed
last
week
are
the
important
that
I
need
to
show.
You,
though,
is
my
composer
file
as
soon
as
I
locate
it.
So
you
can
Auto
load
files
as
part
of
a
composer.
A
A
So
in
my
index
file
when
I
do
composer,
sorry
include
vendor
Auto
load,
we'll
execute
this
file,
and
this
file
will
can
be
part
of
the
repository
that
you
download
and
so
it'll
Auto
instantiate
itself.
When
you
run
your
composer
autoload
file,
so
the
your
actual
code
itself,
you
might
not
need
any
changes
at
all,
with
the
exception
of
actually
creating
your
Tracer
provider
and
your
Matrix
provider,
and
you
know
your
exporters,
so
those
things
have
to
happen
somewhere.
A
B
A
A
I
just
didn't
think
it
was
ready
yet
because
all
our
instrumentations
I
don't
know
we've
only
just
this
week.
I
still
I
still
don't
think
that
we've
agreed
on.
You
know
the
best
way
to
write
instrumentations,
but
this
is
this
is
a
way
and
having
the
instrumentation
abstraction
certainly
helps
a
lot
in
reducing
the
startup
sort
of
configuration
and
initialization
of
an
instrumentation.
So
yes,
yes,
sorry!
So
that's
on
me,
I
will
I'll
push
my
stuff
up,
yeah
I!