►
From YouTube: 2022-11-29 meeting
Description
cncf-opentelemetry meeting-2's Personal Meeting Room
A
C
D
C
C
A
C
C
Think
we
have
a
blank
yeah,
a
good
amount
of
people
now
in
the
god.
So
you
all
see
my
screen
right.
B
E
A
B
I'm
kind
of
questioning,
filtered
and
rich
in
general,
I,
don't
I,
don't
know.
Obviously
people
are
using
them.
They're
they're,
bringing
value
to
folks
I.
Think
that
the
thing
that
I'm,
not
super
confident
of
is
that
these
configuration
options
are
being
used
in
context
where
you
know
something
else
couldn't
be
used
so
like,
for
example,
like
filter
our
documentation
even
says
as
much,
but
it
says
you
know,
sampler
is
the.
Is
the
more
General
like
spec
thing
that
achieves
a
similar
thing?
B
So
I
think
you
know
one
one
part
of
my
mind
is
like
well,
maybe
it's
just
a
documentation
problem.
You
know
we
could.
We
could
provide
better
guidance
about
when
to
use
these
things,
but
in
order
to
do
that,
the
thing
that
I'm
struggling
with
right
now
is
when
are
these
things
valuable?
You
know
over
over
some
other
solution.
I,
don't
even
have
a
very
good
answer
for
that
myself.
B
B
Get
other
folks
thoughts
first
on
First
on
that,
like
in
the
context
of
this
PR,
given
that
this
is
a
first
time
contributor
and
so
on.
But
then
the
bigger
conversation.
A
C
So,
like
with
respect
to
the
sampler
example,
I
think
our
filter
options
usually
provide
this
HTTP
context
or
the
request
object.
Response
object
like
which
newly
or
sampler
would
not
have
access
to
I.
Think.
D
Well,
I
think
in
this
case
it's
metrics
right,
so
the
sampler
wouldn't
get
hit
at
all.
Yes,
in
general,
I
agree
with
you
Alan,
but
I
think
these
little
delegates,
they're
just
a
kind
of
a
nice
convenience,
they're
a
little
lighter
weight
than
having
to
plug
in
processors
and
Samplers.
So
when
it
meets
the
needs
of
the
user,
they
just
need
to
do
something
simple.
B
Yeah
so
I
think
on
that
on
this
issue,
I
I
linked
one
thing
that
I
I'm
a
little
wary
of
about
the
nice
to
have
is
that
It
ultimately
can
cause
unexpected
things
down.
The
line
so
I
know
well
Dan's
on
the
call
now,
but
he
has
encountered
this
with
expands
specifically
so
filtering
out.
The
asp.net
core
span
or
activity
doesn't
necessarily
influence,
whether
Downstream
spans
are
going
to
be
filtered,
which
is
I
think
in
some
cases
right
intuitively.
B
What
should
happen,
but
you
know,
isn't
guaranteed
to
happen
with
metrics
I
think
a
similar
concern
could
come
up
in
that
hey
I'm
filtering
out
like
this
specific
asp.net
core
metric,
but
like
down
down
down
the
line.
You
know
that
same
request
might
make
a
whole
bunch
of
other
calls,
which
may
also
record
metrics.
B
And
I'm
just
wary
of
what
that
would
do
to
folks
observability,
like
they
I'm
imagining
like
they'd,
have
a
dashboard.
You
know
they'd
be
seeing
like
that.
A
dashboard
like
incoming
requests
versus
like
outgoing
requests.
You
know
and
the
incoming
requests
being
filtered
by
this
and
then
the
outgoing
requests,
maybe
not
be.
D
So
I'm,
just
looking
at
the
code,
it
looks
like
for
asp.net
core.
If
we
filter
we
kind
of
set
the
activity
to
non-sampled,
so
we
reset
is
all
data
requested.
We
clear
the
recorded
flag,
so
it
seems
to
me
like
we
make
them
basically
propagation,
only
spans
that
might
be
a
newer
thing.
I
don't
know
if
we
always
did
that,
but
wouldn't
that
help
the
children
like
the
sampler,
if
they're
using
parent,
whatever
that
thing
is
called
parent-based
yeah.
B
D
D
D
B
Yeah,
so
so
responding
to
a
couple
of
your
points
so
yeah,
the
sampler
thing
is,
is
it's
like?
It
depends
on
which
sampler
you're
using
I
know.
We
have
logic
there
that
that
sets
the
flags
appropriately.
So
if
you're
using
the
parent
pay,
sampler
you'll
get
the
ex
you'll
get
the
in,
like
the
the
behavior,
that's
intuitive,
and
then
your
other
point
about
like
beating
up
this
first
time,
contributor,
I,
I,
normally
agree
with
that.
B
I
like
I,
like
of
course,
to
to
support
first-time
contributors,
but
one
thing
that
I'm
kind
of
worried
about
this
stuff
is
like
I,
want
I,
think
removing
say,
filter
and
enrich
for
the
purposes
of
activities.
Given
that
this
instrumentation
has
been
out
here
for
a
couple
of
years
now,
I
think
that
that
would
probably
cause
some
ripples.
E
From
like
the
end
user
perspective,
so
on
the
on
the
other
linked
one,
it
talks
about
the
spans.
Obviously
like
one
of
the
things
we
did
with
with
that
sort
of
work
around
that
that
you
had
linked
was
I.
I
started
getting
a
lot
of
questions
like
oh
I'm
filtering
out
this
span,
but
I'm
still
seeing
metrics
for,
like
my
liveness
endpoint
or
my
Readiness
endpoint.
So
like
I,
don't
know,
I
feel,
like
the
expectation
would
be
that
I
would
also
be
able
to
filter
those
out
right
like
there's.
E
E
It
is
like
kind
of
unclear
I
guess
in
terms
of
like
that,
Nuance
with
like
if
I
use
a
current
based
sample
or
if
I
use
a
always
on
Sample
or
some
Trace
ID
ratio
based
sampler
or
whatever,
like
what
behavior
I'm
going
to
get
and
it's
sort
of
like
I,
don't
know
hard
to
know
all
that
up
front
without
like
digging
through
all
the
code
and
like
having
an
innate
understanding
of
what's
happening.
E
And
then,
if
you
do
want
to
like
create
your
own
sample
order,
that
becomes
like
tricky,
because
the
spans
created
that
are
like
based
off
those
I,
don't
even
know
what
it
is
like.
These
listener
classes
that
like
create
the
instrumentation
like
you,
don't
have
access
to
the
span,
the
real
span
name
in
the
sampler
right
you,
you
only
have
access
to
whatever
happens
before
this
thing
gets
created,
so
it
like
becomes
like
kind
of
awkward
to
use.
D
D
If
we
are
going
to
not
take
this
work,
we
should
give
him
some
workaround
code.
We
should
at
least
vet
out
that
you
can
accomplish
these
two
things:
enrichment
of
metrics
and
filtering
of
metrics.
Somehow
I
don't
know
if
you
can,
but
if
we,
if
we
are
going
to
say
we're,
not
going
to
take
this,
and
we
should
have
some
way
to
do
it,
maybe.
B
I
think
so,
I
actually
just
to
side
note
about
the
HTTP
accessor
I
actually
put
an
example
of
that
on
is
PR,
which
is
also
linked
in
the
in
the
Sig
notes.
The
meeting
notes,
so
yeah
I
think
I
think
that
that
actually
can
be
done
and
I
think
it
can
be
done.
I
think
it
can
be
done
safely.
You
know,
cjo
raises
there.
There
is.
There
is
like
you
know.
You
need
to
use
this
context
accessor
with
caution,
because
it's
you
know
it
used
to
be
context.
B
It's
not
thread
safe.
It
should
only
be
used
within
the
flow
of
the
request,
but
I
actually
think
our
instrumentation.
You
know
in
the
when
or
how
how
sampling
is
invoked,
who
pretty
sure
is
always
in
the
flow
of
the
request
and
I.
Don't
think
that
we
would
ever
have
any
like
weird
threatening
concerns.
B
An
approach
like
this,
so
this
was
one.
This
was
one
solution:
I
think
that
gets
around
like
the
ability
to
basically
filter
things
and
then
the
other
solution
is
the
solution
that
I
chatted
with
Dan
about
which
is
to
use
SDK,
suppress
instrumentation,
which
I
think
is
even
better
in
the
sense
that
you
know
it.
It
like
Dan,
said:
hey
well,
I'm
filtering
out,
you
know
activities,
but
then
I'm
also
saying
I'm
I'm,
seeing
metrics
for
my
for
my
health
check
endpoint.
B
B
And
so
I
think,
there's
basically
two
options,
at
least
in
the
context
here
like
an
asp.net
core
app,
it
could
be
used
for
the
filter
use
case.
Now
this
contributor
I
based
off
of
this
PR
description.
He
seems
most
interested
in
in
Rich
and
not
so
much
filter.
I
think
you
just
did
filter
as
as
a
means
to
check
off
like
another
one
of
the
to
do's.
B
B
He
wants
to
enrich
that
metric
with
certain
attributes
and
at
the
spec
level
there
are
a
couple
of
loose
ends,
things
that
have
not
been
landed
yet,
which
is
one
the
ability
to
enrich
metrics
using
the
view
API
or
enrich
them
via
baggage.
In
the
view,
API
and
then
another
possible
idea
that
has
been
floated
at
the
spec
level
is
the
idea
of
a
measurement
processor
which
is
very
similar
to
a
span
processor.
So
when
a
metric
is
recorded,
you
know
you
can
create
a
custom
processor.
B
B
D
E
It's
not
like
as
bad
in
my
opinion,
because
you
know
if
you're
getting
like
thousands
of
requests
in
a
short
period
of
time
right,
like
you're
you're,
only
going
to
get
like
one
metric
per
minute
by
default.
So
like
it's,
not
the
end
of
the
world
right
like
if
it's
like
a
volume
kind
of
control,
as
opposed
to
some
other
kind
of
control.
But.
B
E
And
also
like
going
back
to
like
that's
SDK
suppression
solution
that
I
had.
It
is
a
little
awkward,
though,
because
you
have
to
do
the
filtering
like
in
two
places
you
have
to
you
have
to
do
it
in
the
sampler
and,
and
you
have
to
do
it
in
the
in
the
in
the
filter,
which
is
like
kind
of
awkward.
In
my
opinion,
it
like
it
works,
but,
like
reasoning,
the
code
out
is
is
not
straightforward.
E
Okay,
so
it's
my
understanding
that
in
the
sampler
when
like,
if
I
have
the
sample,
if
I
have
a
samp
custom,
sampler,
there's
I'm
going
to
get
a
an
activity
that
has
a
name:
that's
like
HTTP
request.in
or
something
it's
not
it's
not
actually
the
I
don't
know
something
happens
after
the
sampler
runs
that
tell
me
what
that
thing
is
so
I
can't
decide
at
that
point
whether
or
not
I
need
to
drop
that
thing.
B
Interesting
I
was
originally
I
had
thought
that
the
suppress
instrumentation,
because
you're
you're,
suppressing
that
that's
oh
I,
see
so
the
suppressed
instrumentation
is,
is
simply
suppressing
all
the
downstream
stuff.
But
then.
E
And
I
don't
know
that
until
after
right,
like
I,
don't
know
in
the
request
pipeline
right
there,
you
know
there's
like
all
the
middleware
that
runs
and
then
eventually
somewhere
some
code
in
the
some
code
like
converts
that,
like
event
to
the
actual
activity
or
I,
don't
actually
I'm
using
the
wrong
terminology,
because
I
don't
know
what
it's
called
right
like
I,
don't
know
what
that
HTTP
request
in
thing
is
as
opposed
to
whatever
whatever
they
asked
me
that
core
instrumentation
eventually
emits.
B
E
B
Well,
I
do
hear
the
the
I
definitely
hear
the
argument
for
for
parity
between
signals
and
just
just
continuing
on
with
what
we
have
you
know.
It
makes
it
more.
B
To
end
users,
time.
B
B
You
could
solve
your
issue
without
using
filter
by
using
the
the
HTTP
context.
Accessor
sampler,
like
a
custom
sampler
like
I
put
on
vishwish's
PR
in
addition
to
the
the
suppressed
instrumentation
I.
D
E
B
For
metrics
I
think
that
your
middleware
would
suppress
it.
I.
B
You
this
press,
instrumentation,
I,
haven't
tested
this
out
first
for
sure,
but
I'm
fairly,
confident
that
the
middleware
that
you
have
means
that
the
metric
will
not
get
recorded.
E
I
think
it
is
nice
I
I,
just
I
would
just
like
like
the,
and
maybe
this
would
be
tricky
because
you
could
argue,
there's
like
lots
of
use
cases
but
like
for
me.
Some
of
the
standard
use
cases
like
the
one
for
the
span
example
for,
for
instance,
like
I,
think
having
that
like
kind
of
called
out
or
just
being
like
here
are
a
couple.
Gotchas
that
that
you
might
fall
into
would
would
be
like
really
nice.
E
B
A
B
B
It
would
be
nice,
though,
to
say
here's
the
use
cases
that
this
works
well
in
and
here's
the
here's
the
the
downsides.
You
know
the
the
potentially
unintuitive
things
that
you'll
you'll
see.
If
you
need
something
more
bulletproof
than
don't
use
filter,
you
know,
write
a
custom
sampler
or
whatever.
E
Yeah,
it's
like
the
80
20
rule
kind
of
thing,
like
the
filtering,
in
my
opinion,
solves
like
a
lot
of
cases
really
simply
and
that's
good
but
like
for
the
other
cases,
just
let's
maybe
know
about
them
or
have
some
type
of
you
know,
like
example,
whatever
that
shows
how
you
can
avoid
certain
pitfalls.
I
think
that
would
be
ideal.
E
Like
I
guess
like
oh
you
mentioned,
though,
that
like
the
spec
might
be
like
providing
more
like
I
guess,
the
only
concern
would
be
like
the
spec
comes
out
with
something,
and
then
it
causes
some
weird
division
in
the
future.
But
I
feel
like
that's
not
again,
like
I
think
Mike
mentioned
this
is
like
pre-release
stuff,
like
maybe
it's,
okay,
especially.
B
I
think
what
I
will
do
what
I'll
take
on
here
is
maybe
I'll
open
an
issue.
I,
don't
know.
B
C
Tools
and
I
want
to
ask
one
thing
about
this:
PR,
the
enrich
signature
is
a
little
different
like
we're
using
a
delegate.
Now
it's
kind
of
I
was
wondering
like
what
did
we
have
for
the
trace
on
option,
so
we
we
would
actually
have
the
activity
instance
passed
and
that's
why
people
could
just
call
set
tag
on
that
right.
So
here
do
we
not?
C
C
Making
a
delegate
and
then
have
people
create
whatever
tag
list
or
tags
and
then
just
add
to
that.
They
cannot
do
that.
The
actual
thing
has
to
be
record.
It
has
to
be
done
while
recording
okay.
A
B
D
C
C
Yeah
cool
then
I'll
also
people
with
this
BR
later.
B
B
I
kind
of
want
to
get
rid
of
filter
but
I'm
I'm
hearing
all
the
arguments,
I'm
still
mulling
it
over.
In
my
my
mind
and
Rich
I'm
I'm,
less
less
inclined
to
like
want
to
get
rid
of,
because
I
think
it
has
some
value
but
I'm
not
100
on
any
of
these
thoughts.
Quite
yet,.
D
We
could
I
was
looking
at
the
code
in
the
asp.net
core
project.
There's
like
the
metrics
listener.
It
actually
uses
the
activity.current.
D
Basically
the
elapsed
time
when
it
calls
record
we
could
check
if
the
activity
was
recorded,
so
we
could
sort
of
allow
the
trace
filter
to
influence
the
metric
like
if
you
scroll
down
to
the
bottom.
Here,
it's
like
the
last
line
see
that
activity
dot
current.
We
wouldn't
know
if
that
current
has
been
sampled
recorded
or
whatever
the
different
flags
are,
but
we
would
be
tying
metrics
do
tracing
right
kind
of
already
is,
but
that's
very
strange,
so
I
kind
of
like
having
the
two
independent
filters,
but
it
is
an
option.
D
Probably
best
to
leave
them
independent
yeah,
the
signatures,
I.
Think
of
the
delegates
are
the
same,
so
you
could
hook
them
up
to
the
same
method
if
you
wanted
them
to
participate
with
the
same
logic,
it
wouldn't
be
very
difficult
to
achieve
that.
You
would
be
executing
it
twice
for
the
same
request.
A
D
Maybe
that's
a
spec
thing
or
it
could
be
two
yeah
I'm,
seeing
more
and
more
questions
about
filtering
from
different
teams
at
Microsoft
wanting
to
do
all
sorts
of
different
things.
So
it
seems
like
there's
a
need
for
better
support
of
filtering
than
what
the
spec
has
right.
Now
is
like
a
couple
lines
in
the
processor.
It's
like
you
could
do
filtering
in
a
processor,
yeah.
B
Can
because
it
doesn't
really
work
but
I
think
at
the
spec
level,
like
a
what's
the
what's
the
gotcha
there,
like
the
the
the
the
span
on
end,
is
supposed
to
be
non-writable
or
something
like
you're
not
supposed
to
be
able
to
mutate
the
spam.
This,
but
at
least
that's
how
the
spec
is
written.
C
A
D
So
the
only
way
to
really
filter
today
is
like
calling
all
the
recorded
I
think
that's
how
we
do
it,
but
then
the
issue
that
arises
is
people
have
multiple
exporters
in
the
same
provider
and
they
want
to
send
like
a
certain
volume
at
each
one,
so
they
want
to
filter
independently,
but
whatever's
first
in
the
chain
is
mutating
the
span
and
that
causes
problems
for
the
exporters
down
the
line.
There's
not
really
a
good
solution
for
that.
D
E
B
A
B
D
E
B
A
D
Kind
of
reminds
me
of
when
you're
setting
up
your
asp.net
core
middleware
like
your
routes
and
stuff,
you
can
always
just
add
middleware
that
will
just
kind
of
execute
sequentially,
but
you
can
also
call
like
map
which
establishes
like
sub
middleware
pipelines
for
a
given
route.
D
A
D
And
batch
export
processors,
those
could
have
their
own
filter
mechanisms
so
that
when
those
processors
get
a
request,
they
run
a
kind
of
filter
or
a
selection
delegate
before
they
pass
it
on
to
the
exporter.
So
you
could
sort
of
filter
just
for
that
handoff
from
processor
to
exporter.
But
all
of
this
would
just
be
kind
of
custom.net.
I
feel
like.
We
really
need,
like
the
spec
to
have
a
design.
B
C
Okay,
so
we.
C
B
C
B
B
One
thought
I
guess:
question
Maybe,
maybe
Mike
you
could
answer
like.
Let's
just
say,
we
decided
that
3663
would
have
been
the
preferable
thing
down
the
line.
Could
we
later
do
like
that
type?
Forwarding
thing
with
with
everything
and
from
this
new
package
and
just
have
forwarded
it
all
to
apis
down
the
line.
E
D
That's
a
good
question.
It
would
definitely
be
possible.
It
might
be
a
little
weird
because
in
API
you
have
like
a
tracer
provider,
Builder
and
then
we'd
be
putting
in
another
thing.
Right
now
it's
called
deferred
Tracer
provider
Builder.
So
you
have
both
kind
of
sitting
there
just
a
little
strange,
but
it
would
it
should
work.
D
D
So
what
these
new
classes
are
doing
is
basically
extending
That
Base,
so
whatever's
in
API,
then
the
next
level
up
is
the
dependency
injection
project
that
has
its
own
Builders.
There
are
those
exact
base
ones
with
a
service
collection
and
then
the
configure
Services
configure
Builder
operations
and
then
there's
some
extensions
that
give
you
helpers
for
like
ad
instrumentation,
there's
really
not
much
there.
It's
just
that
dependency
and
then
exposing
those
sort
of
Base
classes,
but
we
could
do
it,
it'd
be
a
little
weird,
but
we'll
have
to
live
with
that.
Probably.
C
A
C
D
They
probably
don't
want
to
force
dependency
injection
in
that
dependency
graph,
but
I
don't
know
if
that's
totally
valid
at
all
that
they
would
add
open,
Telemetry
API,
because
that
itself
is
forcing
sort
of
a
weird
dependency
on
people,
if
they're
not
doing
open
Telemetry
and
that
thing
rides
along
they're
gonna
be
like
what
is
this
so
we're
sort
of
building
for
a
use
case
and
I.
Don't
know
if
is
realistic,
but
that's
the
direction
we're
in
at
the
moment.
B
Yeah
she
just
seem
to
feel
pretty
strongly
in
3663
that
we
would
need
of
a
stronger
yeah.
He
says
like
there
that
second
I
think
that
second
thread
of
conversation
at
the
bottom
Cho
is
basically
says.
We
need
a
stronger
justification
to
add
additional
dependencies
to
API
he's
less
concerned
about
SDK
foreign.
B
A
B
Don't
you
know,
have
the
dependency
injection
abstractions,
you
know,
dependency
I,
think
that's
why
I'm
still
kind
of
stuck
on
like?
Why?
Don't
we
just
do
this
because
nobody's
going
to
want
to
take
a
dependency
on
the
open,
Telemetry,
API
anyways,
no
Library
author
is
going
to
want
to.
B
A
B
In
fact,
I
think
for
the
like
talking
about
the
contribute
things,
I
think
what
should
be
done,
regardless
of
whether
we
have
a
separate
package
or
we
will
say
we
have
a
separate
package.
The
dependency
injection
package
I
think
we
should
change
all
the
all
the
instrumentation
libraries
to
take
contency
on
that.
So
that
then
right
we
can
follow
the
the
the
pattern,
the
options
and
config
pattern
that
that
Mike's
basically.
D
Yeah
yeah
go
back
to
the
new,
the
current
PR
and
then
we
have
like
a
go
to
that
example.
Usage
Link
in
the
descriptions
right.
D
So
that's
what
this
diff
is
doing
so
today
in
the
core
repo,
we
have
SQL
client
instrumentation.
It
only
has
a
dependency
today
on
API,
so
today
it
can't
do
the
options
pattern.
So
what
this
diff
is
doing
is
using
the
new
dependency
injection
package
and
then
hooking
all
of
that
up.
So
if
we
go
with
this
pattern,
this
is
what
we'd
want
to
do
in
contribute
for
any
instrumentation.
D
That's
only
referencing
API.
We
would
switch
it
to
use
dependency
injection
and
then
do
this
same
modification,
which
is
pretty
light,
there's
not
a
whole
lot
to
it,
but
that's
really.
The
whole
purpose
of
this
whole
mess
is
so
that
everything
is
consistent.
All
the
options
work
across
the
board
in
the
same
way
you
get
named
option
support
you
get
the
eye
options,
validation,
framework
and
configuration
entry
points
stuff
like
that.
B
B
And
I
think
at
the
end
of
the
day
you
know
instrumentation
authors:
they
don't
have
to
follow
any
of
these
patterns.
They
don't
have
to
take
a
dependency
on
this
dependency
injection
package.
They
don't
have
to
take
a
dependency
on
open,
Telemetry
API,
just
because
you
know
everything's
in
diagnostic
source.
B
If
they
did
have
some
like
configurable
options,
then
you
know
it
wouldn't
follow
any
of
these
patterns,
but
that's
like
that's
kind
of
their
prerogative
prerogative,
but
I
think
it's
really
handy
that
we've
we've
put
forth
a
strong
kind
of
guidance
and
opinion
to
create
kind
of
some
consistency,
or
at
least
some
some
help
helpful
guide
rails
for
for
people
as
they
adopt
open,
Telemetry
and
instrument
things
with
it.
C
B
No
I
still
stand
by.
You
know,
I,
think
I
think
the
only
reason
so
there's
one
comment
that
I
make
there
is
that
say
the
the
API
currently
has
metric
or
meter
provider,
Builder
and
Tracer
provider,
Builder
and
I
think
that
if
we
had
it
to
do
all
over
again,
those
probably
wouldn't
be
an
API.
You
know
they
they
may
also
be
in
this.
B
Like
I,
don't
know,
dependency
injection
is
the
right
name
for
the
package,
but
like
like
Mikey
tossed
out
yesterday,
like
some
like
Builders
package
or
something
some
configuration
package,
but
just
because
we
made
that
step
in
the
past,
like
I
I,
think
it
makes
sense
to
not
continue
throwing
things
that
don't
make
sense
in
API
I.
C
Okay,
then
I
think
we
will
go
forward
with
this
PR
and
have
a
new
package
and
get
ready
for
the
RC
release
soon,
hopefully,
by
the
end
of
this
week
or
early
next
week.
If,
depending
on
how
things
progress.
D
Okay,
I
will
focus
on
getting
this
done.
It's
I'm
mostly
just
doing
cleanup
and
then
I
got
to
do
the
public,
API
files
and
just
a
lot
of
the
process,
but
it
should
be
done
today.
Maybe
tomorrow.
C
Okay,
yeah
and
I
think
once
this
is
done,
we
just
have
to
review
the
public
API
for
the
main
SDK
project
and
the
new
package
I
think
in
our
very
first
Sig
meeting
when
we
started
the
public
API.
If
you
think
we
had
this
app
detector
API,
which
we
bought
could
be
made
internal
I.
Think
all
of
these
things
also
worked.
D
B
D
B
D
B
A
A
B
B
B
D
It's
a
great
question:
I
was
looking
at
this.
Auto
instrumentation
gave
us
a
PR
a
while
back
or
like
disabling
the
SDK
and
I
was
looking
at
this.
It
probably
should
return
like
the
no
op
provider.
A
D
Doesn't
today
it
just
returns?
No,
it's
like
weird,
it
would
maybe
be
breaking
I,
don't
know
all
I
did
here
was
like
annotate
it
but
I
agree.
This
is
a
super,
weird
and
probably
spec-breaking.
D
B
D
But
yeah
this
is
going
to
be
weird
if
we
ever
do
support
like
disabling
the
SDK,
where
they
have
the
user
in
their
host
code.
You
know
they're
calling
like
sdk.create
provider
and
they're,
adding
everything
at
the
end.
They
call
build
and
then
maybe
they're
just
calling
like
dot
dispose
on
it
or
they're,
trying
to
get
something
off
of
it.
They're
calling
Force
flush
who
knows,
and
then
we
introduce
some
environment
variable
that
could
disable
it
all
and
it
causes
that
build
to
return
null.
E
D
D
Which
is
in
itself
not
I,
think
it
would
be
breaking
to
go
the
other
direction
where
you
said
like
we
never
return
null
and
suddenly
we
start
handing
back
Knoll.
That
would
be
bad,
but
if
we
they
say
it
could
be
null
so
people
should
code
defensively
and
check
and
then
in
the
future
we
just
never
return
null
again.
It
would
be
fine
as
long
as
people
were
defensive
correctly,.
D
In
API
there's
the
notion
of
the
default
provider,
which
just
does
nothing
forever,
which
is
really
strange
if
you
I
was
talking
to
Jack
about
what
Java
does
those
are
sort
of
fundamental,
useful
things
in
Java
at
least
in.net?
We
have
it
defined
and
I,
don't
think
it's
ever
set
anywhere.
It's
just
sitting
there
and
it
will
always
know
up.
That's
weird.
We
should
probably
tackle
these
two
things
together
and
figure
out
how
it's
going
to
work,
probably
important
to
Auto
instrumentation
but
I'm,
not
100,
sure.
D
That's
always
what
you're
going
to
get
you're
just
going
to
get
that
Noah
instance.
So
we
should
probably
when
the
SDK
spins
up
set,
that
to
something
useful.
Maybe
it's
just
the
first
provider,
that's
created,
I,
don't
know,
but
the
spec
to
find
some
behavior
for
the
default
provider
that
we're
not
really
following
never
implemented.
This.
B
D
Yeah
and
from
what
I
can
tell
most
of
the
documentation
and
the
code
like
uses
the
default
to
gain
access
to
the
provider.
It's
just
this
Global
static,
magic
thing
think
if
I
recall
correctly,
just
whatever
the
first
provider
that
gets
created
is
just
set
to
that
instance.
So
if
you
have
multiple
providers,
they
exist,
they
work
you
just
can't
get
to
them
globally
through
the
static
which
we
could
do.
That
would
be
pretty
simple
to
implement
it.
That
way.
B
Actually,
now
that
you're
saying
this
I
think
I've
actually
seen
Java
code
and
I
actually
I.
Think
I've
also
seen
go
SDK
code
that
they
have
methods
of
like
set
global
set
Global
provider
that
you
can
call.
B
I
I
don't
know
if
they
also
have
like
something
like
what
you're
saying
like
some
sort
of
like
well,
the
first
one
that
gets
created
like
that's
just
automatically
set
to
Global,
but
I
I've
also
seen
methods
for
for
setting
up
which
I
guess
we
have
I
guess
somebody
can
go
in
and
just
like
set
this
by
hand
if
they
wanted
to.
D
B
A
B
C
A
C
D
D
B
D
C
Oh
okay,
yeah
I
think
there
are
no
other
topics.
Then
we
can,
in
the
meeting
I'll
update
the
notes.