►
From YouTube: 2021-08-19 meeting
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).
C
A
You
can
I
mean
that
when
they
make
its
things
everything
complicated,
but
I
think
I
finally
got
all
my
paperwork
done
for
a
little
bunch
of
stuff
that
I
have
to
do.
A
A
A
All
right,
so
I
think
alex
and
lydon
are
out
of
obvious
today,
so
they
won't
be
joining
us,
so
we
can
give
maybe
a
couple
of
minutes
for
folks
to
join
in
the
meantime,
as
usual,
please
add
your
names
to
the
attendees
list
in
the
document.
E
D
Yeah
so
let's
begin,
the
first
thing
I
want
to
discuss
was
currently
in
our
current
implementation.
The
attribute
limits
the
limit
on
length
of
attribute
or
count
of
attribute.
We
also
apply
it
to
resources.
D
So
if
you,
if
a
user
adds
a
number
of
attributes
to
resources
and
it's
greater
than
the
limit,
then
we
draw
we
truncate
attributes
of
the
length
integration
and
specified
limit.
So
this
is
interesting
because
the
one
spec
does
not
mention
resources
anywhere
when
it
mentions
limits
and
resources
are
supposed
to
be
immutable.
So
should
we
be
going
ahead
and
like
modifying
resources-
and
the
third
point
is
that
the
resources
limits
are
mostly
useful
in
practice.
D
D
So
that's
one
example
where
limits
are
useful,
but
for
resources,
I
don't
I'm
having
a
very
hard
time
to
think
about
any
real
world
use
case
where
limits
would
be
useful
for
resources.
So
spec
is
completely
silent
on
this.
I
don't,
I
don't
think
spec.
Actually
expects
us
to
apply
limits
on
resources,
so
I
think
we
should
my
opinion
is.
We
should
not
apply
limits
on
resources
and
let
them
be,
I
think,
suicant
had
the
same
opinion.
Does
anyone
have
any
other
thoughts.
A
The
only
thing
I
can
say
is
that
have
we
asked
in
the
spec
channel
in
slack
or
something.
D
No
not
yet
it
just
came
up
like
and
earlier
today
or
yesterday.
Okay,
we
haven't,
we
haven't
clarified
with
spike
authors,
but
yeah.
We
probably
should
yeah.
A
Yeah,
I
I,
I
think
what
we
can
yourself
thing
is
very
reasonable.
I
will
just
ask
just
to
be
sure,
but
I
I
I
won't
do
anything
now
without
that's
compulsive.
F
I
would
also
probably
agree
that
yeah
the
limit
shouldn't
apply.
I
think
an
important
thing
to
call
out
to
is
in
otlp.
You
only
send
the
resource
once
per
batch
of
metrics
or
traces.
F
So
in
that
sense
it's
a
lot
less
costly
because
you're,
not
attaching
it
to
each
span
in
the
actual
on
the
wire
yeah,
make
sense.
D
D
So,
in
my
opinion,
one
daughter
only
means
that
we
guarantee
we
won't
make
breaking
changes
to
this
package
going
forward,
but
it
doesn't
mean
that
we
will
be
supporting
it
in
the
sense
that
we'll
be
fixing
bugs
in
a
timely
manner
or
anything.
So
I
think,
taking
on
support
responsibilities
are
different
from
guaranteeing.
We
won't
make
breaking
changes.
So,
in
my
opinion,
we
1.0
shouldn't
a
country
package
shouldn't.
Have
the
requirement
to
have
a
code
owner
like
maintenance?
D
D
So
that
was
my-
that
was
another
thing
I
wanted
to
bring
up.
F
I
have
a
question
on
this,
like
I
thought.
Well,
I
thought
we
discussed.
I
don't
remember
if
we
documented
anywhere
but
like
if
you,
I
think
the
example
you
always
come
up
with,
is
like
scikit-learn
like
if
we're
not
really
familiar
with
it
and
we
release
it
guaranteeing
stability
and
then
it
ends
up
being
like
completely
wrong
and
we
really
have
to
break
stability
like
will.
A
F
A
F
Yeah,
like
so,
for
instance,
the
I
think
another
one
was
the
aio
http
like
that
one,
I
think,
is
pretty
common
library
used
everywhere,
but
we
weren't
sure
how
to
instrument
it,
and
I
guess
that
one
like
like
we're
not
stable
now,
but
I
think
that's
just
another
example
like.
D
So
so
yeah,
that's
a
very
well
point,
but
I
think,
like
probably
the
process
solution
to
that,
should
be
that
we
need
to
kind
of
audit
every
package
before
we
release
1.0
and
people
can
volunteer.
If,
as
a
group,
we
feel
like
scheduler
needs
one.,
we
can
edit
at
an
issue,
and
someone
can
volunteer
to
to
spend
time
on
it
and
and
and
figure
out
if
we
are
confident
enough
to
release
one
another.
A
Policy
wise,
we
will
probably
it
doesn't
make
much
sense
to
take
up
a
an
instrumentation
package
for
library
that
we
don't
know
much
and
we
and
just
deciding
to
making
it
1-0
because
there's
no
pressure,
I
guess
to
do
so.
A
So
I
guess
in
most
of
those
of
the
cases
we'll
be
doing
it
like
that
of
first
having
a
code
owner
who's,
an
expert
and
then
releasing
it
upgrading
it
to
1.0.
A
B
B
The
the
point
of
this
pr
was
just
to
meet
the
ask
that,
like
aaron
brought
up,
we
mentioned
in
the
sig
that
we
wanted
this,
because
contrib
packages
are
supposed
to
be
community,
hosted
like
easy
to
find
instrumentation
packages
that
people
can
download.
So
for
the
core.
Repo
yeah,
like
the
maintainers,
should
probably
know
most
of
everything
that
every
line
of
that
people
does
so
that
they
can
release
it
and
be
confident
for
stable
releases,
but
for
the
contributors
I
gave
in
an
example.
B
In
my
comment
that,
for
example,
we
want
to
release
the
aws
package,
the
sdk
extension
package
to
users,
and
we
at
aws
feel
confident
that
it's
ready
to
go,
and
so
we
would
want
that
to
be
released
and
the
maintainers
should
do
the
final
release,
but
we're
just
offering
to
be
code
owners
so
that
we
can
be
points
of
contact.
You
know
if
things
do
break
or
things
happen.
D
For
example,
they
take
another
example,
let's
say
classic
instrumentation
as
a
group,
we
let's
say
if
we
are
very
confident
about
the
state
of
class
instrumentation,
and
we
know
it
works
very
well
and
we
want
to
release
one
double
so
some
aws
or
lightsteppers
one
customers
can
go
ahead
and
use
it
confidently,
but
maybe
no
one
wants
to
volunteer
to
be
code
owner
and
support
it
down.
The
line
like
there
could
be
a
situation
like
this.
Does
that
mean
we'll
never
be
able
to
at
least
one
other
task?
D
I
don't
think
that
should
be
the
case
like
as
a
group.
If
we,
if
we
feel
confident
about
losing
one
at
all
for
any
country
package,
we
should
be
able
to
do
it.
B
I
see
what
you're
saying
I
I
I
agree
with
you
that
we
probably
shouldn't
require
like
flask.
We
could
do
it
as
a
group,
but
then
we
could
also
just
set
open
telemetry
python
approvers
as
the
code
owner.
In
that
case
you
know
kind
of
like
something
that
the
community
feels
confident
about
releasing.
B
I
can
update
them
the
wording
to
say
that
it's
not
required.
If
that's
what
we
want,
but
I
guess
just
now.
I
explained
the
intention
behind
it
originally.
B
A
F
So
I'm
I'm
curious
like
what
say
hypothetically,
we
ended
up
with
like
100
instrumentation
packages
or
200
after
like
a
few
years
or
something
like.
Would
we
be
comfortable
like?
Wouldn't
we
want
to
have
some
contact
on
the
hook
for
each
one
that
I
mean
I
understand
they
could
leave
and
everything
I'm
just
like
curious.
F
If
this
is
supposed
to
be
a
place
for,
like
nathaniel,
said
community
to
put
instrumentation
packages
and
stuff
or
like,
we
could
also
just
tell
people
to
make
instrumentation
packages
in
their
own
github
repos
and
release
them
like
if
the
point
of
contrib
is
to
be
like
a
nice
place
for
them
all
to
be
together.
It's
the
intention
also
that
the
maintainers
like
release
all
the
code
and
and
own
it
or
like
have
support
okay.
I
know,
like
I'm
curious,
oh
what
you
think
about
support,
because
you
said
it's
separate
and
I
agree.
D
I
mean
it's,
I
don't
know
if
if
the
package
has
the
owner,
they
would
obviously
active
owner,
they
would
obviously
take
care
of
it.
If
they
don't,
then
it,
I
guess,
falls
on
the
stick
and
they
say
good.
D
Just
like
we
have
many
dozens
of
issues
open
onto
the.
When
you
take
care
of
them,
I
guess
we
will
take
care
of
it
in
a
similar
way.
Whenever
someone
has
some
bandwidth
but
yeah,
so
I
guess
we
would
it'd
be
support
in
that
case
would
be
this
effort,
I
would
say,
but
the,
but
it's
the
like
whether
we
find
a
code
owner
first
and
then
we
release
sorry
whether
we
don't
find
a
coordinate
first
and
then
we
release
without
coder
or
other
case
where
we
release
under
the
code
owner
leaves.
D
It
is
the
same
entry
survey.
This
is
the
same
situation
so
requiring
having
this
requirement
for
1.0
to
have
a
code
owner
doesn't
really
solve
anything
because
the
code
owner
could
just
leave
a
month
later
like.
How
do
we
enforce
that
with
some
process,
so
like
yeah
in
the
real
world
and
the
end
result
is,
is
literally
the
same.
D
So
we
have
to
take
care
of
take
care
of
the
situation
anyway.
Even
if
we
agree
to
this
requirement
that
before
releasing
one
dollar,
we
need
a
code
owner.
We
still
need
to
take
care
of
the
situation
where
a
coroner
leaves.
What
do
we
do
about?
It
then
exactly
same
situation,
so
if
you
cannot
find
a
solution
for
that,
then.
A
You
mentioned
that,
whatever
what
we
will
do
if
we
have
like
200
libraries,
I
think
right
now
we
have
like-
I
don't
know-
maybe
20
or
30
libraries
and
I'm
I'm
already
willing
to
give
all
the
control
to
to
a
code
owner.
A
In
my
opinion,
it
is
right
now
it
is
way
too
big
for
us,
maintainers
and
approvers.
I
would
prefer
to
have
the
code
owners
be
have
a
maintainer
power
in
for
each
one
of
their
packages.
A
That
is
a
controversial
idea.
I
have
suggested
it
already
because
that
will
probably
imply
having
to
separate
this
into
multiple
repos
so
that
we
can
give
permissions
to
people,
without
I
mean
only
for
for
the
particular
package,
so
yeah
I'll
be
willing
to
do
that
now.
I
think
we
already
have
like
too
many
libraries
that
we
can't
be
experts.
F
Okay,
so
it
sounds
like
boy
point
taken
like
for
releasing
a
1.0.
We
shouldn't
need
that
and
then
maybe,
like
the
scaling.
This
repo
would
be
like
a
separate
discussion.
D
Yeah,
I
think,
making
it
a
suggestion,
would
be
great
not
entirely
removing
it,
but
not
having
as
a
hard
requirement.
D
Know
you
want
to
talk
about
this?
No.
F
I
don't
I
added
this
and
it
was
directly
targeted.
A
Okay,
the
famous
matrix
prototype,
so
I've
been
working
at
this
for
a
long
time
and
pretty
much.
The
prototype
is
consistent
in
implementing
two
examples.
One
of
them
are
grocery
store
and
the
other
one
an
http
server.
A
A
A
I
don't
know
one
hour
ago,
so
I'm
actively
trying
to
make
them
pass,
but
the
most
important
thing
so
for
for
people
to
take
a
look
for
people
to
be
able
to
take
a
look
is:
is
it's
going
to
be
available
when,
when
I
mark
this
as
as
a
pr
so
hopefully
in
a
couple
of
hours,
something
I'll
fix
the
tests,
because
at
least
I
want
all
of
them
to
have
a
reject
and
then
I'll
update
this
smart
dspr
and
you
can
start
taking
a
look
at
it
and
adding
your
comments.
F
Awesome
well,
I'm
excited
to
look
at
this
and
great
work.
This
is
really
exciting.
Do
you
think
so
is
this.
This
is
an
sdk
and
an
api
prototype.
A
It
is
yes,
it
is
an
sdk
and
an
api
prototype
with
the
sdk
being
much
more
of
a
prototype
than
the
api.
This
reflects,
of
course,
the
current
situation
we
have
in
our
spec,
where
there
are
like
three
very
important
prs
for
the
spec
that
are
still
on
the
review.
A
So
so
yeah
definitely
add
any
comments
or
doubts.
You
have
about
the
sdk
implementation,
but
just
be
aware
that
everything
is
very
subject
to
change
still
because
stuff
is
still
being
decided
and
also
this
is
a
very
minimal
implementation
of
the
sdk
as
well.
The
there
are
some
stuff,
that's
still
being
discussed
as
explorers
that
are
not
part
of
the
sdk
prototype
right
now
they
are
still
pr's
in
the
spec
site.
So
that's
gonna
take
a
while,
probably.
F
A
The
I
created
a
new
branch
named
metrics
new,
because
the
other
branch
that
leyden
had
opened.
It
was
of
course
like
one
year
old,
and
I
mean
bringing
that
back
and
resolving
all
the
conflicts
we've
made
would
make
no
sense
right
since
it's
pretty
much
starting
from
zero
again
so
yeah.
This
pr
is
to
be
this
disappear.
That's
opened
against
that
metrics
new
branch,
so
that
yeah
at
least
we
can
have
like
the
first
pr
merge
into
the
metrics
new
branch.
Hopefully.
F
Okay,
cool,
so
one
other
question:
would
it
be
possible
to
separate
this
one
into
an
api
pr
and
then
an
sdk
pr
just
for
like
reviewability.
A
G
F
I
don't
know
if
we
want
to
go
into
like
so.
I've
been
going
to
the
metrics
thing
like
this
whole
time
to
roll
this
thing
in
I
know,
you've
been
going.
Sometimes
diego
I've
seen
seen
you
joining
lately.
I
think,
like
srikant
brought
up
a
good
point
about
some
questions
around
like
what's
gonna
happen
with
like
whiskey
servers,
so
when
this
is
running
with
like
a
fork
model,
how
are
we
gonna
deal
with
like?
Is
there
gonna
be
a
separate
sdk
for
process
like?
F
Are
we
gonna
send
you
know?
I
think
this
is
kind
of
a
unique
problem
to
python
and
maybe
like
ruby,
I
would
assume
like
things
that
have
a
global
interpreter
log,
that
generally
they
run
as
like
multiple
processes.
So
I
don't
know
if
it's
applicable
to
the
broader
metric
sig,
but
yeah
like
do.
Do
you
want
to
have
any
discussions
about
stuff
with
metrics
or
like
sticking
points
you
see.
A
So
sorry,
what
is
the
the
question
you
have
regarding
python
on
the
global
interpreter.
F
Yeah
yep,
so,
like
generally,
if
you,
if
you're
running,
like
a
flash
server,
you'd
run
it
with
like
micro,
what
is
it
micro,
whiskey
or
like
gunner,
corn
or
whatever
unicorn?
However,
you
say
it
so
when
you
do
those
you
like,
they
have
the
forking
model,
and
then
you
end
up
with
separate
processes
for
like
multiple
processes
for
the
same
application
right.
You.
F
Okay,
so
so
we'll
end
up
with
like,
like
basically
all
of
the
metrics
will
be
per
process,
and
they
won't
be
aggregated
for
your
entire
app
running
on,
like
the
given
machine.
F
A
You're
thinking
about
the
frameworks,
that's
split
up
in
processes
because
of
performance
reasons:
right,
yep,
okay,
yeah,
that's
a
good
point,
not
sure
the
I'll.
I'm
pretty
sure
that
that
has
not
yet
been
discussed
in
the
metrics
say
I
think
so.
F
A
A
That
I
I
realize
that
that's
that's
an
important
problem,
but
I
I'm
not
sure
if
caring
about
it
right
now
be
a
case
of
premature
optimization
right.
A
E
That
makes
sense,
and
also
I
want
to
you
know,
bring
up.
I
was
looking
in
the
collector
repo
issues.
There
was.
There
was
one
issue
like
some
people
came
up
with
some
some
sort
of
proposal
to
address
this
problem.
It's
it's
almost
a
year
now
I
think,
yeah.
We
we
can
probably
like
that.
A
Yes,
just
out
of
curiosity,
this
concern
of
yours,
it
occurred
to
you
when
you
were
working
with
the
logs
prototype.
E
No
logs,
don't
don't
have
this
problem
I
was
I
was
looking
at
like
I
was
looking
at
your
pr
and
I
know
one
thing
like
so.
I
have
like
very
simple
lab
that
I
wanted
to
use
this
and
then
it
occurred
to
me
that,
like
I
have
a
simple
request
counter,
but
since
I
have
different
processes,
they
are
not
aggregated
and
then
sent
to
the
the
backend.
E
So
that's
when
this
occurred
to
me
and
then
I
asked
I
don't
if
you
know,
since
he
is
following
the
matrix
he
closely,
I
asked
him
how
how
would
we
solve
this
in
python?
He
said
it's
not
possible
at
this
point.
A
Yeah
and
and
also
think
that,
sooner
or
later
we're
gonna
face
this
problem,
but
maybe
even
maybe
this
something
that
can
be
solved
at
the
instrumentation
library
level,
because
it
will
only
apply
to
some
certain
frameworks,
maybe,
but
I'm
not
sure
that
the
instrumentation
library
have
all
the
power
to
access
all
this
stuff.
That's
needed
to
make
that
fix,
but
it's
made.
I
don't
know.
E
Yeah,
so
I
I
I'm
sorry
to
disturb
yeah,
I'm
just
one
time,
so
I
was
looking
at
the
unicorn
source
code,
see
if
you
know
if,
if
they
have
something
that
that
we
can
use
to,
you
know
address
this
problem.
There
is
some
some
instrumentation
with
the
stats
t
that
I
have
seen.
I
I
I
did
not
understand
it
fully,
but
yeah
probably
this
can
be
even
you
know,
addressed
something
in
the
instrumentation
level
as
well,
but.
G
E
A
Sure
yeah,
definitely,
if
that's
possible,
that'll,
be
great
but
yeah.
I
won't.
I
won't
bet
all
my
money
on
that
being
possible.
F
Okay,
yeah
just
to
be
clear,
I
wasn't
I
wasn't
like
trying
to
specifically
talk
about
that
problem.
I
was
just
trying
to
like
get
your
feedback
from
doing
the
prototyping
like
if
there's
anything
you're
concerned
about
or
like
I
was
just
throwing
that
out
as
one
possible
thing
and
also
we
can
move
on
if
it's.
If
we
have
other
topics
too
so.
A
Yeah,
it
is
definitely
an
an
excellent
point
just
to
give
you
the
complete
picture,
this
prototype
of
the
http
server.
I
implemented
it
completely
with
async.
I
o
so
it's
running
in
my
thread.
So
that's
that's
important
information,
maybe
only
for
so
do
you
know.
D
So,
just
one
more
point:
before
we
move
on
so
people
most
likely
do
deploy
like
horizontally
scale,
python
services
and
multiple
servers
running.
So
is
there
something
stopping
us
from
thinking
of
like
unicorn
workers
as
independent
servers
from
their
own
meter,
and
do
we
want
to
adopt
that
worldview?
And
just
do
you
mean.
F
F
Okay,
unicorn
so
like
do
we
want
to
tell
people
if
they
use
that
they
shouldn't
fork
like
they
should
force
it
to
be
one
process.
D
F
Yeah
yeah
so
like
in
the
resource
cement
conventions,
there's
actually
one
for
process
id,
so
we
could
stick
the
process
id
in
there.
It's
just
a
matter
of
like
I
don't
know.
Maybe
I'm
a
little
selfish
about
this,
because
it's
for
for
google,
it's
kind
of
tough,
we
sort
of
need
to
aggregate
those
beforehand
if
they're,
if
they're
going
to
be
like
running
on
the
same
container.
Even
so,
that's
it!
That's
that's
fine,
but
yeah
like
it's
totally
possible.
It's
just
maybe.
D
Maybe
they're
not,
I
just
want
to
try
it
out
yeah.
We
should
definitely
look
for
a
whisky
based
solution
for
sorry,
g
unicorn-based,
solution,
class
and
ipc,
or
something
if
you
can
come
up
with
a
solution
for
that.
It
will
also
be
also
greatly
help
tracing
setup
because,
right
now
it's
a
major
platform.
You
need
to
set
it
up
for
every
process,
yeah
yeah
right
so
update
on
distro
configuration.
D
So
I
had
a
small
small
chat
with
earlier
and
we
decided
to
the
merge.
There
goes
a
couple
of
pr's
that
split
sorry
that
introduced
the
pre
and
post
hooks
after
we
release
the
next
version
on
tuesday.
That
should
give
us
enough
time
to
merge
it
and
then
have
it
ready
for
district
authors
to
to
migrate
to
it
by
next
but
next
week.
D
So
I
guess
still.
No,
we
still
don't
have
a
have
any
agreement
on
what
this
story
should
be,
how
you
want
to
solve
the
original
problems
that
came
up,
but
at
least
next
week,
we'll
we'll
actually
split
the
instrumentation
in
distro
packages
and
then
take
it
from
there.
A
Yeah,
I
also
think
that
this
is
valid
progress,
because
we
we
will
at
least
have
an
answer
for
a
few
of
the
quest
questions
that
make
up
this
big
issue
right
and
afterwards.
We
can
finally
discuss
something
else
and
we
can
focus
on
the
implementation
of
the
mechanism
to
solve
the
distros
or
you
know
the
resources.
D
Yeah,
so
some
open
vrs.
I
think
we
only
talked
about
the
matrix
vr,
so
we
talked
about
for
this
one.
No,
this
is
a
different
one.
Yeah.
I
took
a
look
at
this
earlier.
This
looks
good
to
me.
I
guess
only
comment
I
have
is:
do
we
have
a
way
to
test
these
scripts
without
having
to
release
and
release
a
real
package
and
then
okay,
let
me
turn
this
on
to
that
and
then
another
thing
that
came
up
that
I
didn't
comment
about
yet
is.
D
Raised
package,
so
we
do
this
and
we
try
to
find
a
package
name.
Is
this
object?
How
reliable
is
let's
put
this
object
with
something
else
that
has
similar
name?
I
guess
it's,
it's
very
unlikely,
but
do
you
think
it
would
be
worth
it
having
an
explicit
mapping
or
tag
names
to
the
trees,
or
is
this
good
enough.
D
B
We
tried
a
different
couple
of
different
options
and
I
felt
happy
about
this
one
because
there's
the
setup.py
file,
which
could
help
and
yeah
like
you
mentioned
directories.
There
probably
won't
be
conflicts
for
package
names
and
directories,
so
I
think
it's
okay
to
try
and
it's
hopefully
simple
to
understand
and
yeah.
If
it,
if
it
does
break,
we
can
fix
it
in
the
future.
D
Only
top-note
directories.
That
means
it
won't
help
with
within
dimension
packages,
because
they're
in
in
this
directory
right.
B
F
A
Okay,
just
just
be
aware
that
that
has
a
green
button
right
now
and
yes,
click
it.
A
tired
maintainer
may
click
it,
because
it's
very
tempting
to
click
that.
So,
if
there's
something
that's
still
pending,
it'll
be
better
to
mark
this
pr
draft
or
something.
A
C
B
F
A
C
That
work
for
you,
diego
aaron's,
follow
the
jokes
today.
F
Cool
does
anybody
was
that
the
last
thing
on
the
agenda.
F
F
I
don't
know
if
they
ever
did
that,
but
I
think
one
of
the
things
they
brought
up
was
like
the
monkey
patching
and
in
our
instrumentations
and
and
sort
of
like,
like
our
ci
stuff,
I
don't
know,
has
any.
Has
anybody
thought
about
that
at
all.
A
An
issue
or
a
discussion,
so
I
think
what
was
the
name.
D
D
D
Like,
instead
of
automatically
monkey
badging,
we
also
expose
them
to
through
code
and
let
people
use
them
directly
without
patching.
So
if
we
have
a
middleware
and
then
we
monkey
patch
to
automatically
inject
the
middleware,
then
we
should
also
expose
that
middleware.
So
people
can
import
it
and
use
it
directly.
Okay,
but
isn't
the
instrument
or
the
middleware.
D
Yeah
not
in
all
cases-
and
I
think
that
was
one
of
the
us
like
the
instrument
in
instrumentation-
shouldn't-
be
the
middle
there,
so
the
middleware
is
independent
entity.
People
can
import
it
and
use
it
and
at
the
same
time,
people
can
also
run
the
instrumented
or
instrument
function
which
automatically
injects.
A
A
But
yeah
now
that
you
mentioned
that,
I
think
I
remember
one
of
the
comments
where
that
the.
A
D
Yeah
yeah,
I
think,
it'd
be
a
nice
goal
to
have.
Maybe
we
probably
need
like
documentation
or
guidelines
on
how
to
write
an
instrumentation
anyway.
So
when
we
do
that,
maybe
we
should
include
it
that
include
a
point
that
says:
try
to
decouple
the
framework
specific
entities
from
the
instrumentation
like
this
is
a
good
example
right.
D
D
F
A
Well
also,
the
monkey
patching
is
not
something
that
is
related
to
the
instrumentation
mechanism
that
we
have.
Our
our
instrumentation
mechanism
is
agnostic,
because
the
only
thing
that
it
does
is
that
it
calls
instrument
some
instrumentations
use,
monkey
patching
and
some
some
others
don't.
But
our
our
mechanism
does
not
know
any
of
that.
It
just
calls
instrument
and
if
you
monkey
patch
it
in
the
instrument
method,
that's
fine,
and
if
you
don't
that's
fine
as
well
for
our
instrumentation
mechanism
as
well,.
D
Yeah
yeah,
that's
true,
I
don't
think
they
had
issues
with
that.
So
with
flask.
I
don't
know
if
there's
an
easy
way
to
hook
in
things
like
mirrors,
but
maybe
we
have
instrumented
class
class
here,
instrumented
version
of
flask
app.
Maybe
we
could
I'm
not
proposing
this,
but
for
that
user.
If
this
was
an
ex
exposed
class,
maybe
they
could
import
it
directly
and
instead
of
instantiating
clusters
flask
they
would
instantiate
their
service
with
instrumented
philosophy.
Telemetry
is
that
I
guess
that's
what
they
were
getting.
A
Already
well,
we
can
provide,
I
mean
the
the
instrumental
is
a
class
that
can
have
any
any
method.
For
example,
this
one
has
this
instrument
app
method
there
right
there
in
line
263,
so
we
can
add
another
method.
That's
I
don't
know
instrument
with
middleware,
something
like
that.
D
Yeah,
I
I
don't
think
that
was
what
they
were
asking.
We
can
add
that,
but
I
don't
think
that
was.
That
was
what
they
were
asking
for.
D
E
E
F
Think
the
one
the
one
diego
is
pointing
out,
though,
is
like
that.
So
if
you
scroll
down
a
little
bit
this
instrument
app,
does
it
without
longer
patching
it?
Does
it
adds
up
before
requesting
after
request.
A
A
A
We
can
provide
a
method
for
each
one
of
those,
so
it
happens
some
something
different,
maybe
if
the
user
wants
our
instrumentation
to
instrument
via
middleware.
In
that
case,
we'll
well,
of
course,
we'll
need
to
define
environment
variables
and
they
can
select
which
method
they
want
better.
D
Yeah,
I
think
that
makes
sense.
It'd
be
it'd,
be
great
if
he
could
get
couldn't
get
a
good
time
with
that
person
again
andrew
with
their
name.