►
From YouTube: 2022-10-26 meeting
Description
cncf-opentelemetry meeting-2's Personal Meeting Room
A
A
Okay,
yeah
Michael.
This
is
for
making
sure
that
our
public
API
surface
is
same
for
all
the
Frameworks
right
for
HTTP
instrumentation.
C
Yeah
so
kind
of
a
breaking
change.
C
A
D
And
you
might
have
breaking
changing
the
feedback
idea
also
collide.
E
D
D
D
A
A
So
everything
that
was
part
of
the
web
request
instrument
options
would
now
be
here.
C
Yeah
before
we
tried
to
limit
what
you
saw
in
the
code
based
on,
if
you
were
done
that
framework
or
netcore.net
newer
stuff,
but
it
doesn't
really
work
because
you
can
compile
to
Don
that's
standard
2-0
and
you
get
essentially
the.net
framework
API.
But
then,
if
you
consume
that
into
like.net6
it
breaks
Because.
The
actual
binary
that
you're
going
to
get
in
the
host
doesn't
have
that
API.
C
C
A
E
A
C
We
could
that
might
be
a
valid
case,
though,
like
if
you
were
wrapping
this
in
a
net
standard,
2o
library,
and
then
you
were
consuming
it
into
a
Net,
Framework
and
net
core.
You
could
actually
have
that
2o
code
set
them
both
and
be
able
to
handle
both,
but
only
one
path
will
be
executed
on
the
actual
host
when
it's
running,
if
that
makes
sense,.
A
B
D
C
On
both
runtimes
they
know
how
to
create
the
other
API.
So
if
you're
on.net
framework
and
you
use
HTTP
client,
so
it
uses
the
HTTP
request
message
class,
it's
going
to
new
up
HTTP
web
requests
like
Legacy
thing
and
then
that
gets
fired.
The
reverse
is
on.net
core.
If
you
do
an
HTTP
web
request,
Legacy
thing
it's
going
to
new
up
a
newer
HTTP
request
message,
so
we
could
kind
of
do
the
same
thing
and
just
say
like
on
that
framework.
C
We're
always
going
to
allocate
that
HTTP
request
message
so
that
we
can
expose
the
same
API.
It's
just
it's
going
to
be
a
perf
killer,
because
you
have
to
allocate
the
thing
you
have
to
copy
all
the
properties.
Then,
whenever
you
get
the
response,
you
have
to
do
the
same
thing
for
the
response,
which
may
include
buffering
the
whole
response
body.
I'm,
not
sure
I'd
have
to
kind
of
look
at
the
details
of
those
apis,
but
on.net
core
HTTP
client
does
a
really
good
job
or
tries
really
hard
to
not
buffer
anything.
C
B
No,
it
makes
complete
sense,
no
I
agree
like
I
I.
Think
there's
the
perfect
concern
also
what
to
do
with
the
with
the
response.
I
on
that
point
like
I,
wonder
how
many
users
are
actually
using
something
like
a
filter
or
you
know,
enrich
and
actually
reading
the
response
from
the
Callback.
That
would
seem
like
Bad
News,
Bears.
D
C
C
C
C
C
System.Net.Http
nuget
package
contents,
so
you
get
all
of
this
stuff
out
of
the
box
on.net
framework,
but
you
can
also
reference
this
package,
so
what
I
was
expecting
to
see
is
if
you
reference
this
package
is
expecting
to
see
it
to
start
to
use
the
new
code
path,
but
it
does.
It
uses
the
same
built-in
stuff,
so
I've
been
trying
to
figure
out
like
how
is
that
happening?
What's
going
on
so
this?
These
two
guys
will
do
like
the
diagnostic
source.
C
C
C
So
that's
no
longer
part
of
the
code,
so
I
don't
know.
If
there's
a
reason.net
has
just
stopped
releasing
this
package,
but
we
could
ask
them
if
there's
a
possibility
to
get
a
newer
version
and
that
might
open
up
some
Avenues
here
to
have
a
unified
API.
If
we
just
say
you
must
have
this
nuget,
you
know.
If
we
add
this
as
a
dependency,
we
would
basically
force.net
framework
users
to
take
the.net
core
the
current
version,
and
then
we
would
only
need
the
diagnostic
Source.
C
E
So
Blanche,
can
you
explain
like
what
benefit
would
it
bring?
If
the
you
know
get
package
is
published.
C
C
If
we
could
do
that,
then
basically,
what
we
would
be
doing
is
anyone
on
the
Net,
Framework
runtime
would
get
the
new
HTTP
client
bits
which
then
use
the
diagnostic
listener,
so
they
would
always
fire
instead
of
our
HTTP
web
request
stuff,
which
is
kind
of
like
the
Legacy
code
path.
They
would
always
flow
through
the
same
stuff
that
we
see
on
like
net
six
net
five.
E
E
Know
why
it
stopped
so
the
date
shows
yeah,
it's
probably
2.1,
I'm
free.
E
C
E
Yeah
I
think
I.
Remember
like
asking
this
once
like:
do
they
allow
HTTP
client
packages
also
to
be
released
like
out
of
pan,
just
like
diagnostic
Source
I
heard?
The
answer
was
no
at
that
time,
but
I
never
asked
like
why
not
so
there
must
have
been
like
strong
race
in
other
ways.
They
would
have
just
turned
it
I
assume,
but
anyway,
let's
find
it
out
officially.
B
I,
don't
know
if
this
totally
well
I,
don't
think
it
answers
the
question,
but
it
was
an
interesting
Twitter
back
and
forth
from
emo
a
long
while
back
regarding
advice
to
specifically
Library
authors,
I
think
he's
he's
speaking
to
when
and
when
not
to
reference.
The
the
nougat
package
from
your
library
versus
depend
on
the
what
he's
calling
the
inbox
versions,
shipped
with.net
framework.
B
E
I'm
also
looking
at
like
one
blog,
which
the
Tottenham
team
published
some
time
back
about
the
APA
combat
package,
which
we
used
to
detect
like
backward
compatibility,
change
that
also
detected
or
called
out
things
like.
If
you
have
multiple
targets
and
if
your
public
API
is
different,
it
could
throw
some
like
violations
or
some
errors.
I
I
I'm
on
a
phone,
so
I
cannot
really
read
it.
But
let
me
paste
it
into
the.
E
Yeah
yeah
I,
don't
know
who
is
sharing
like?
Can
you
just
open
that
link.
A
E
Because
it
did
mention
like
something
about
like
how
do
you
deal
with
a
situation
where
you
have
different
API
in
different.
E
A
A
B
C
D
C
You're
never
executing
that
standard.
It's
always
shim
to
like
your
final
run
time,
so
we
were
switching
that
API,
we're
removing
it
removing
the
HTTP
web
request
API.
If
you're
you
end
up
on
not.net
framework.
So
if
you
code
it
against
2o,
and
then
you
ran
on
that
core
or
dot
net
five,
it
blows
up
on
you
same
idea,
but
it's
subtly
different
or.
A
E
It
looks
like
the
right
thing
to
do:
I
I
I,
even
if
we
do
not
get
the
wishlist
from
HTTP
client
being
published
as
soon
you
get
like.
What's
our
best
option,
assuming
that
wish
never
happens.
C
You
couldn't
enhance
it
a
little
bit.
So
if
you
set
these
filters
and
enriches,
we
could
like
block
warnings.
You
know
at
runtime,
if
you,
if
you
set
it,
if
it's
never
gonna
fire,
we
could
do
that
at
least
but
I.
Don't
I,
don't
think
throwing
would
be
good
because
then
we
could
get
into
the
same
situation.
We're
like
you'd,
have
the
pillow
library
and
you
use
all
of
them
so
that
you
support
whatever
run
time.
C
You
happen
to
be
running
on
and
then
all
of
a
sudden,
you
launch
on.net
core
and
you're
setting
the.net
framework
ones.
Just
you
know
as
a
standard
practice
and
it
starts
throwing
on
you.
It
would
essentially
be
the
same
problem
except
now.
It's
a
runtime
thing.
Instead
of
a
build
time
thing,
yeah,
probably
a
bad
idea.
D
C
We
could
also
ship
separate
packages,
we
could
have.
You
know
HTTP
web
request
instrumentation,
but
I.
Don't
if
we
do
that
if
we
split
the
packages
I
don't
think
we
could
have
have
the
net
standard
Target,
so
we'd
have
to
have
a
net
462
package,
and
then
we
could
have
you
know
whatever
our
minimum.
What
are
we
at
net
six
now
yeah,
which
would
be
totally
fine?
D
E
Yeah
I
I
understood
that
part,
but
I
I
I
think
we
did
discuss
the
possibility
of
stating
the
packages.
But
even
if
you
do
that,
if
it
doesn't
solve
the
purpose
of
helping
Med
standard
to
targeting
customers,
then
yeah
it's
the
same
problem.
Yeah.
C
Really
splitting
the
two
it's
kind
of
like,
but
we
had
a
few
days
ago,
where
the
the
one
package
that
we
do
have
just
Target
the
targeted
the
concrete
run
times
and
then
just
gave
you
two
separate
apis.
It
was
effectively
the
same
thing
we
would
do
if
we
had
two
packages,
so
it
fixed
it,
but
it
doesn't.
It
doesn't
help
you
as
far
as
the
net
stand
or
2o
wrapper
Library
case
that
we're
kind
of
dealing
with.
D
E
B
B
C
I
think
what
this
PR
is
doing
is
like
best
practice.
You
don't
want
to
have
different
apis
in
your
nuget,
so
I
think
it's
okay
for
us
to
do,
especially
if
we're
already
breaking
it.
It's
just
we're
kind
of
we're
kind
of
pushing
it
onto
the
user,
then
to
like
make
sure
they
they
use
the
things
which
I
don't
love
them.
I
wish.
There
was
a
way
to
make
it.
E
So
what
what
would
the
user
do
like?
For
example,
there
is
a
user
who
has
a
wrapper
Library,
which
is
targeting
extended
2o,
and
they
used
our
HTTP
client
and
they
got
like
they
got
binded
to
the
incorrect
one.
They
were
running
on.net
framework,
but
they
got
bound
to
the
or
the
other
way.
What
would
be
the
action
item
we
asked
some
like
we
just
asked
some
to
modify
their
wrapper
to
have
an
explicit
Target
like
net60.
Is
that
what
we
are
going
to
ask.
C
E
But
is
that
like
a
bad
thing
or
I
think
it's
a
reasonable
thing?
But
if
you're
writing
a
wrapper,
then
they
should
also
understand
the
pain
of
shipping
libraries.
A
E
Think
that
this
issue
only
occurs
when
someone
writes
a
shared
Library
which
targets
net
standard.
That's
the
only
time
this
issue
would
occur,
because
if
you
are
using
the
actual.net,
5
or
dotnet6
application,
and
then
you
add
our
package,
then
it
will
always
get
binded
correctly
or
if
you
use
an
asp.net
classic
framework
thing.
It
will
also
pick
the
right
one.
The
only
time
when
this
mismatch
occurs
is
if
there
is
an
intermediary
targeting
the
net
standard
one.
E
So
if,
if
that
is
a
like
very
specific
case,
where
we
are
going
to
break,
then
maybe
it's
just
okay
to
let
them
also
multi-target.
C
D
E
Yeah,
that's
I,
don't
know
okay,
but
the
fix
for
them
would
be
to
change
the
net
standard
to
O
alone,
to
net
standard
2.1
and
whichever.net
framework
they
are
using.
So
is
that
considered
a
like
bad
thing
or
like
hacky
way,
or
is
it
just
considered
a
normal
thing?
I
consider
it
as
a
very
normal
thing,
because
if
you
are
writing
wrappers,
then
you
need
to
pick
the
right
targets.
B
I
think
I
mean
it
I
think
it
begins
to
like
intersect
with
old
that
standard
conversation
like
do
we
ever
do
we
ever
anticipate
that
we
want
this
to
be
supported
for
like
xamarin
or
mono.
Those
types
of
Frameworks
then
that
standard
two
one
or
a
Net
Framework
Target,
would
not
work
for
those
rendering
this
unusable
and
then,
furthermore,
the
the
example
where,
if
we
have,
if
we
ever
dropped,
say
net
four
six
two
and
we
opt
to
net.
E
So
it
looks
like
we
cannot
just
drop
and
extend
it
to
go
and
replace
it
with
next
10
day
to
one.
But
what
what
we
can
do
is
just
ask
the
people
who
write
shared
library
or
this
to
have
multiple
targets,
one
four
that.net
framework
question:
they
are
targeting
and
the
specific
version
of.net
core
runtime
like
P,
3.1
or
5.06.2.
C
E
Is
there
like
anyone
else?
We
need
to
ask
like
someone
from.net
regarding
this
specific
I
think
we
briefly
discussed
this
in
the
past
as
well,
but
like
Blanche
or
like
do
you
think
it
would
make
sense
to
have
another
round
of
discussion?
E
E
Yeah,
because
if
we
are
doing
something
which
violates
their
thinking,
let's
get
a
blessing
that
hey
we
are
doing
it,
but
we're
doing
it
because
of
XYZ,
and
that
seems
reasonable.
So
then,
we'll
be
like
somewhat
playing
the
right
game
here,
because
I
mean
we
already
explored
all
the
other
options
and
everything
has
their
own
drawbacks,
some
of
them
being
like
really
Unthinkable.
So
maybe
that
will
convince
them.
Okay,
we'll
ship,
HTTP
client
as
a
nugget.
A
What
is
like,
so
what
is
like
ugly
about
this
option
of
the
lack
of
better
word.
C
It's
not
like
a
pit
of
success,
type
of
design
where
there's
just
like
one
enriched
you
know
enriched
requests
and
Rich
response
and
filter,
really
simple,
not
likely
to
have
any
mistakes,
but
now
there's
these
like
six
things
and
you
have
to
read
it
carefully
and
you
have
to
do
the
right
thing
and
if
you
mess
up
it's
just
gonna
silently
fail.
I
guess
is
the
the
risk.
B
I
mean
I
think
from
the
standpoint
of
like
the
best
thing
for
the
end
user
would
be.
You
know,
a
unified
API
that
just
did
the
like.
We
had
our
own
wrapper
around
these
things
to
me,
I
think,
that's
the
that's
the
ugliest
thing
about
the
about.
This
is
just
as
much
that
it's
just
kind
of
the
putting
on
this
on
the
end
user,
to
figure
this
out.
A
A
E
Yeah,
because
if
they
put
the
wrong
enrich
they,
they
think
that
it's
going
to
work,
but
it's
not
going
to
work
same
with
the
batch
thing.
I
think,
like
user
might
say,
batch
size
equal
to
like
2000,
but
first
they
have
to
pick
the
processor
equal
to
batch.
Then
only
that
makes
sense
so
yeah
in
in
that
way,
I
feel
it's
pretty
inflated.
It's.
C
D
E
Even
if
it
object,
we
have
to
it's
not
possible
for
us
to
do
that.
It's
like
in
enrich.
We
don't
know
what
property
they
are
interested
in,
so
it
it
will
boil
down
to
be
creating
our
own
wrapper
around
these
two
and
internally
broadcasting
or
like
internally
coding
the
right
API,
but
that
would
be
very
bad
for
performance.
So
I
think
a
better
option
is
to
let
user
pick
the
right
one
and
yeah.
We
can
do
our
best
job
in
the
remarks.
C
D
D
E
Okay,
then
I
think
that's
a
like
a
good
way
to
proceed
for
now
and
like
we
will
see
like
how
people
react
to
it.
I
I,
don't
know
how
to
measure
it,
but
at
least
we
still
have
opportunity
to
fix
it,
because
it's
not
going
to
be
stable
anytime
soon,
at
least
in
the
next
six
months.
So
we
will
have
like
another
attempt
at
it.
C
So
I'm
working
on
today
in
the
HTTP
instrumentation
project
for
the
tests
on
NET
Framework,
we
only
run
the
Legacy
stuff
for
net
6
and
Net
7.
We
run
HTTP
client
tests.
They
are
actually
both
valid
for
both
runtimes,
so
I'm
trying
to
update
the
test
Suite.
So
it
always
runs
the
full
set
of
legacy
and
new
on
all
run
times.
But
then
I
have
to
add,
like
you
know,
little
if
checks
to
make
sure
that
the
correct
callbacks
are
firing.
So
it's
a
little
bit
of
effort.
C
E
C
E
A
Just
one
last
question
again:
what
was
the
issue
with
say,
making
having
separate
packages
separate
package
for
request
web
request
and
separate
folder?
The
regular
HTTP
client.
C
We
could
do
that,
but
I
don't
think
we
could
do
that
and
support
net
standard
20.
as
soon
as
you
add
in
that
standard,
2-0
you're
in
the
same
situation.
So
if
we
split
the
projects,
we
have
one
that
just
Targets
in
that
framework.
We'd
have
one
that
targets
net
six.
Let's
say
we
could
do
that.
You
get
a
nice
API,
so
it
eliminates
the
need
for
the
user
to
have
to
choose,
but
we're
not
fulfilling
our
mission
here,
which
was
supporting
that
standard
2-0.
C
E
Yeah,
so
if
you
add
like
net
standard
to
One,
then.net
Core
2.1
will
be
unsupported,
so
I
think
we
made
a
decision
at
the
very
early
like
I.
Don't
know
how
early
probably
like
much
before
I
joined
Spencer
gave
us
the
maintainer
he
did
put
in
not
saying
that
if
Microsoft
supports
it,
we
should
I
found
that
note
that
was
decided
like
long
before.
So
we
just
continued
that
tradition.
If
Microsoft
supports
it,
we
should
support
it.
E
So
maybe
that's
why
we
started
with
net
standard
2.0
to
allow,
in
fact,
it
was
even
possible
at
that
time
to
have
asp.net
core
projects
which
targets
the
full
framework.
It
was
a
thing
at
that
time.
It
got
all
like
moved
eventually
but
yeah.
Maybe
there
are
like
really
like
corner
corner
scenarios
like
that,
but
anyway,
I
think
like
what
we
discussed
like
based
on
what
we
discussed
like
we
can
make
this
change.
E
Like
let
user
read
the
dog,
we
can
try
to
make
it
as
obvious
as
possible
in
like
readme
code
commands
whatever
else
and
then
yeah
then
just
go
for
it
and
see.
If
someone
really
complains
and
based
on
that,
we'll
have
another
opportunity
before
we
call
it
1.
stable.
E
Or?
Is
that
same
fault
or
is
it
only
foreign.
E
Okay,
then
it
will
be
HTTP.
I
mean
this
is
a
request.
E
E
All
right,
let's
go
to
the
next
topic,.
A
E
Oh
actually,
I
made
a
mistake:
I
put
the
wrong
link,
but
anyway
the
the
basic
idea
is
it's
the
previous
PR
which
I
wanted
to
put
the,
but
it's
still
fine
like
we
can
open
the
readme
of
that
file.
E
So
this
is
basically
like
what
do
we
do
with
the
versioning
if
we
are,
since
we
are
already
changing
the
observable
count,
wages
to
observable
up
down
counter,
so
we
did
check
with
Microsoft
back-end
like
someone
checked
Splunk,
and
you
would
like
also
checked,
and
we
already
know
Prometheus,
it's
no
issue
slowly,
people
who
would
really
be
worried
or
affected
would
be
those
who
are
using
a
back
end
which
distinguishes
between
gauge
and
up
down
counter
and
to
the
best
of
my
knowledge.
E
We
do
not
have
such
a
system
yet,
but
there
could
be
something
which
we
do
not
know.
So
with
that
and
the
comment
which
I
think
piyota,
he
made
a
comment
saying
that
we
could
just
treated
us
about
like
we
should
have
used
up
down
counter
since
it's
in
it.
These
are
like
additive,
so
it
should
have
been
like
up
down
counter
in
the
first
place,
but
we
made
a
bug
and
we
just
fix
it.
We
use
use
the
right
one.
E
Okay,
no
one
is
opposing,
which
means
everyone
is
agreeing.
B
E
E
Okay,
oh
since
we've
been
stable,
I
think
yeah.
We
were
asking
like
Microsoft
customers
to
use
it
a
lot,
because
the
dotnet
team
gave
the
blessing
by
approving
the
1.0
release.
So
that
gave
a
lot
of
confidence
to
a
lot
of
folks
because
it
was
upload
by
the
people
who
owned
the
threading
Library,
the
GC
owner
Diagnostics
owner.
So
maybe
they
also
did
some
marketing
or
sharing
okay,
it's
very
popular
yeah,
but
at
least
based
on
my
knowledge,
like
I,
can
confirm
like
within
Microsoft.
E
E
B
Maybe
it's
me
it's
maybe
it's
possible
that
people
won't
upgrade
to
101,
just
because
it's
a
minor
version
bump
like
if
it
were
a
200
like
it
would
be,
they'd
be
more
likely
to
upgrade,
and
so,
if
there
were
any
breaking
changes,
Downstream
related
to
back
ends
we'd
find
out
sooner
than
then.
If
we
did
a
minor
version
bump
yeah,
but
there.
E
Is
a
other
side
of
it
like
if
someone
sees
2.0
because
then
people
say
okay,
this
is
a
breaking
change.
I
don't
have
time
to
deal
with
that,
so
there
is
a
chance
that
nobody
would
upgrade
if
they
see
2.0,
even
if
we
explicitly
State.
This
two
daughter
is
just
because
say
type
of
counter
change,
so
you're
not
likely
affected.
So
you
don't
really
so
it.
It
may
be
like
difficult
to
message
that
also
so
we
would
be
like
having
the
same
trouble
again
like
people
would
not
just
update.
E
Yeah
I
mean
the
other
Pier
which
I
had
in
the
same
way
remove
the
net
core
3.1,
but
we
still
retain
the
net
standard
to
go,
so
it's
still
aligned
with
what
the
other
I
mean
earlier
discussed
as
well.
So
if
someone
wants
to
really
use
it
in
dot,
Net,
5
or
net
core
3.1,
it
would
just
work.
They
have
to
just
Surplus
the
warning
if
they
are
affected
by
that
one.
E
Okay,
yeah
I,
don't
have
anything
else
to
discuss.
I'll
I
mean
when
we
are
ready
to
ship
it
we'll
use
one
dot
one
as
the
next
version.
D
Yeah,
so
so
this
one
I
started
working
on
it
today,
so,
like
I,
think
I
I've
discussed
this
with
sigil
and
Blanche
briefly,
so
we
in
order
to
see
if
we
can
update
the
return
type
for
the
filter,
functions
across
the
instrumentation
libraries
right
now.
The
filter
function
returns
to
it's
a
Boolean,
true,
false
and
based
on
true
or
false.
We
either
collect
the
request
or
do
not
collect
the
requests.
D
Yeah,
so
so
to
make
it
more
clear,
the
solution
was
to
use
you
know
where
we
can
clearly
specify
what
what
that
written
result
will
do
so
like
as
an
example
here,
I
have
updated
written
type
for
asp.net
core.
D
So,
as
you
can
see,
there's
one
include
request
and
exclude
request,
so
it's
self
explanatory
and
will
make
it
more
clear
what
what
exactly
do
users
need
to
written
for
use
on
in
their
filter
functions,
so
so
the
so
I
had
remembered
to
get
some
feedback
on
like
whether
we
should
have
this
filter.
The
enum
different
one
like
across
across
different
instrumentation
libraries
or
like
the
way
I
have
it
here,
which
is
just
have
one.
D
E
We
could
do
that,
we
can
make
it
like
uniform,
but
we
can
just
have
to
remove
the
word
request
from
it,
so
it
would
be
just
include
exclude,
so
we
can
make
a
very
generic
every
instrumentation
Library
can
use
it
if
you
make
it
part
of
the
API,
but
it's
optional
I.
Don't
think
we
need
to
do
that,
but
it
won't
see
any
reason
we
need
to
have
it
specific
to.
D
Each
Library,
okay,
so
yeah,
so
one
of
the
things
this
was
and
I
discussed
it.
Putting
that
in
the
API
is
like
something:
I
mean
it's
not
like
a
special
editing.
So
the
question
is:
is
that
okay,
to
put
that
at
the
API
level,
I
originally
started
with
the
SDK,
because
we
have
SDK
dependency
right
now,
so
we
could
use
it
from
there,
but
then
yeah.
We.
E
Could
put?
Oh
that's
just
an
accidental
thing
yeah.
So
the
fact
that
some
instrumentation
libraries
have
a
SDK
dependency
is
something
which
we'll
want
to
revisit
at
some
time
in
the
future,
because
I
think
that
was
specifically
to
get
access
to
the
suppress
thing
which
the
spec
folks
never
specked
out
in.
So
we
just
put
it
in
the
SDK.
But
there
is
a
chance
it
will
come
as
a
official
spec
and
then
we'll
move
it
to
API
itself.
E
So
the
instrumentation
libraries
can
simply
rely
on
API,
okay,
but
I
want
to
hear
like
if
anyone
else
has
opinion
on
this
one,
or
should
we
be
just
fine,
just
keeping
it
as
true
false
I
think
this
discussion
has
come
like
several
times
when
we
were
originally
defining
it
and
then
later
as
well.
C
E
Would
it
include
like,
would
you
suggest
the
name
include
request
or
just
include.
C
E
Yeah,
that's
what
I
I
would
suggest
it
can
be
just
include
and
exclude,
or
drop
and
include
like
instead
of
exclude,
we
can
use
the
word
drop
because
that
word
is
used
in
The,
Matrix
and
tracing
sampler
to
indicate
we
are
dropping
it,
but
I
I
want
to
first
see
if
everyone
agrees
with
dropping
the
request,
part
from
it,
because
for
SQL
it's
something
else.
It's
not
necessarily
a
request.
It
could
be
something
else,
so
we
should
be
able
to
like
make
it
more
like
generic,
rather
than
try
to
request
itself.
C
Why
I
like
having
a
copy
of
it
in
all
the
instrumentation?
That's
actually
using
it,
because
then
you
could
tweak
the
name.
Maybe
if
some
case
ever
came
up
where
you
needed
a
third
type
of
behavior,
you
wouldn't
block
yourself
right.
You
have
complete
control
over
whatever
you
need,
which
seems
like
an
advantage.
E
That
seems
right.
Yeah,
like
one
possibility,
is
like
exclude
exception.
So
if
the
filter
throws
an
exception,
then
we
are
excluding
because
that's
the
current
behavior,
but
maybe
we
can
make
it
more
explicit,
yeah,
okay,
so
I
agree
with
like
having
each
instrumentation
having
their
own
copy
and,
like
anyone
else
with
comments
for
for.
D
E
But
whatever
this
is
only
a
return
type
right,
this
is
just
a
return
type,
so
even
you
see
how
multiple
things
for
the
user
to
make
the
decision
on.
Ultimately,
the
return
type
is
still
the
same.
Let's
see
the
true
false,
as
currently
over
it
will
be
the
e
m,
which
returns
one
of
the
things.
A
E
Collector
and
drop
seems
nice
like
Drop
is
definitely
favored,
because
spec
also
calls
drops
when
we
are
dropping
something
on
the
floor.
Instead
of
exclude.
D
D
E
Guess
yeah
so
then,
at
least
by
default
like
there
is
nothing
else
preventing
that
item
from
being
exported
unless
user
writes
their
own
further
activity
processor,
where
they
change
the
sampling
decision
default.
So
for
the
East,
all
data
requested
equal
to
four.
So
that's
a
very
custom
thing.
So
by
default,
I
think
we
can
say,
collect
and
drop.
D
E
In
other
option
is
maybe
include,
but
anyway,
since
we
are
out
of
time.
Let's
leave
it
up
to
us
to
comment
on
the
pr.
E
Because
then,
we'll
get
like
some
more
time
to
think
of
any
better
options,
but
I
think
the
general
agreement
is
yes,
we
need
to
change
the
true
faults
to
a
specific
enum
and
we'll
copy
the
options
to
each
and
every
class.
So
if
they
ever
need
a
possibility
of
expanding
it,
they
can
freely
do
so.
The
only
thing
which
we
are
like
trying
to
close
is:
what
would
we
name
it
like?
Is
it
excluding
load
or
is
it
drop
collect
so
with
that
I
think
we
can
leave
that
to
appear
comments.
E
Yeah
I
think
that's
it.
We.
A
I
see
that
Dan
you've
posted
something
on
the
chat,
discuss
that
like
I
seem
to
use
it.
Oh.