►
From YouTube: 2022-11-09 meeting
Description
cncf-opentelemetry meeting-2's Personal Meeting Room
A
B
B
Okay,
I
think
like
we
first
wanted
to
start
with.
B
That
we
released
beta
3
version
of
Hotel
code
packages
and
also
the
RC
9.9
of
the
non-core
packages
yesterday,
and
we
would
like
to
review
the
public
API
changes
in
this
meeting
so
that,
hopefully
we
can
start
off
with
our
RC
releases.
Next.
A
B
B
Cool
so
blands
like
how
do
we
want
to
start
this
best
way.
A
B
A
D
B
B
C
B
A
C
I
can
recall
gone
gone
through
it
in
this
meeting.
I
think
it's
a
great
exercise
but
I
think
in
the
past,
we've
done
it
kind
of
asynchronously
and
all
of
us
kind
of
swarming
over
it
and
raising
issues
where
we
see
them,
but
at
least
for
me
this
is
how
I've
gone
about.
It
is
just
looking
at
these
unshipped
files
and
kind
of
reasoning
over
each
method.
Okay,.
B
Yeah
I
think
we
can
just
look
at
this.
One
then
like,
if
everything
seems
okay
to
us,
so
we
mainly
wanted
to
do
it
for
the
DI
and
the
configuration
part,
but
I
think
the
other
changes
are
not
as
many
so.
This
is
essentially
about
making
the
log
record
attributes
setable.
B
B
B
So
this
one
is
not
related
to
like
we,
the
extension
and
Di
work
that
we
configuration
and
DIY
that
we
wanted
to
look
for
was
mainly
for
traces
and
metrics
right.
What
this
is
this
one
related
to
the
DI
part
or.
D
That
was
added
before
by
some
I
think
it
was.
Some
random
contributor
might
have
been
someone
from
spec.
B
Okay,
but
is
it.
C
Those
were
added,
I
mean
this
is
the
logger
one,
but
there
should
be
one
somewhere
for
traces
and
metrics
as
well.
C
Then
the
the
alternative
is
that
we
still
have
a
method
called
I
think
it's
called
set
resource
Builder
and
it
accepts
a
builder
rather
than
a
an
action
like
this,
so
yeah
that
was
done,
I
think
pretty
early
on
right
immediately
after
the
130
release.
So
it's
it's
been.
That
was
good
out
there,
a
while
foreign.
C
C
It
was
introduced
in
support
of
some
things
that
I
think
happened
in
the
control
repository
for
like
Docker
and
so
on.
If
I
recall,
but
you
mentioned
my
service
provider
thing
I,
don't
I,
don't
know
what
the
backgrounds
story
is
there
offhand.
D
This
is
kind
of
interesting
one,
so
there
was
that
later
PR
ior,
where
they
it
might
be
active.
Now
there
was
like
a
sampler
detector
and
then
I
have
a
PR
for
like
the
auto
configuration
where
I
moved
all
that
stuff
to
its
own
sort
of
nude
it
its
own
package.
I
thought
this
had
already
shipped,
but
if
it
hasn't
shipped,
maybe
we
should
pump
the
brakes
on
our
resource
detector.
Maybe
it
should
also
go
into
that
package.
B
D
Yeah,
oh
yeah
totally,
so
this
this
just
kind
of
Builds
on
top
of
the
dependency
injection
surface.
So
once
that
stuff
is
public,
it's
sort
of
like
the
fundamental
minimum
level
of
API
service.
You
need
to
kind
of
build
extensions
to
like
the
startups.
You
can
register
Services.
Once
the
service
provider
is
available,
you
can
register
delegates,
so
you
can
build
a
lot
of
the
stuff
we
need
in
SDK
as
sort
of
add-on
packages.
That's
kind
of
what
this
is
proving.
B
So
you
say
this:
one
could
be
a
part
of
that
like
with
this
API.
We
don't
need
to.
We
don't
need
this
to
be
part
of
the
SDK,
and
it
could
be
part
of
that
package.
C
C
C
For
Samplers,
you
know
like
there's
they're
Samplers
and
you
can
extend
you-
can
create
your
own
custom
Samplers.
It's
I,
guess
it's
a
class,
not
an
interface,
but
this
notion
of
of
like
detecting,
which
sampler
views
are
detecting,
which
I
don't
know.
Resource
detectors
to
use
is
feels.
C
C
Interesting
so
maybe
maybe
our
assumption
about
the
unshipped
files
was
wrong
or
my
assumption
I
guess
I'm
the
one
to
put
that
out.
There.
D
B
D
Why
would
you
use
this
if
you
needed,
like
let's
say
you
were
building
a
resource
detector
that
needed
something
from
the
service
collection
or
the
service
provider?
It
might
need.
C
I
think
it
was
probably
made
in
support
of
this
Docker
extension.
D
I
think
I
actually
use
this
method
for
the
environment
variables,
so
the
environment
variable
detector
used
to
just
call
the
static
API,
the
dominant
framework
ad.
Now
it
will
also
take
them
from
I
configuration,
but
you
need
to
get
I
configuration
out
of
the
service
provider,
so
I
think
I
needed
this
to
extend
the
environment,
variable
detector,
to
look
into
environment
variables
and
eye
configuration.
If
that
makes
sense,.
B
B
Yeah
does
this
Docker
extension
use
that
same
add
detector
overload
or
is
it
yeah.
B
B
Again
this
one
but
okay,
yeah
I,
mean
looks
like
they
are
passing
a
proper
instance
of
a
detector.
Here,
at
least.
B
Like
did
we
have
any
requests
for
this,
like
did
someone
ask
for,
for
this
feature.
B
Okay,
let
me
just
write
that
down
for
now,
foreign.
D
Tricky
to
explain
so
back
what
I
was
saying
with
the
environment
variables
previously,
how
we
managed
environment
variables
was
in
these
option
classes
they
would
have
a
Constructor
or
that
just
called
into
the
static
environment,
variables
API.
So
the
feature
request.
The
issue
was
that
only
works
for
environment
variables.
D
B
D
A
D
Existing
public
Constructors
on
all
of
these
option
classes
basically
do
this
pattern
now
or
if
you
don't
give
them
my
configuration,
they
just
create
an
eye
configuration
from
environment
variables,
that's
like
to
preserve
the
existing
Behavior,
then
there's
an
internal
Constructor
that
takes
the
eye
configuration.
This
is
now
where
it
actually
pulls
the
values.
So
if
you
scroll
down
to
the
bottom
of
that
method,
right
there
on
line
80.,
so
it
needs
to
new
up
an
instance
of
this
child
options,
but
it
has
to
be
able
to
pass
in
that
configuration.
D
D
D
B
D
B
D
C
Yeah
I
think
we're
beginning
to
get
the
things
back
on
the
right
track,
but
and
I.
The
thing
we've
talked
about
in
the
past
is
at
some
point,
marking
the
batch
export
processor
options
here
and
also
the
export
processor
type
most
likely
above
Obsolete
and
pushing
all
of
that
down
into
well
similar
to
this
class
that
you
have
now
with.
D
If
you
want
good
there's,
a
PR
I
have
out
there
for
a
doc
update.
D
So
here
I
did
a
different
pattern
where
you
have
the
exporter
options
and
then
the
batch
activity,
processor
options,
there's
just
two
separate
things
there
and
then,
if
you
scroll
down
to
the
bottom
of
it,
I'm
callingthebuilder.ad
exporter
method.
So
it's
sort
of
I've
used
a
little
bit
more
of
what
the
Builder
provides
and
its
helpers
and
then
I
repurpose
the
options
class.
So
if
we
sort
of
have
this
pattern
in
place,
we
wouldn't
need
that
public
API.
It's
just
sort
of
exist
because
of
the
state
we're
in.
B
D
But
if
we,
if
we
updated
our
exporters
to
do
it
more
this
style,
we
could
clean
all
that
up.
So
the
question
is
on
that
API
we
could
make
it
internal.
We
could
use
the
internal
visibles
hack
to
get
everything
up
and
working,
and
then
we
could
work
to
move
everything
to
that
pattern
so
that
we
can
clean
it
up
and
we
don't
need
this
public
API.
D
B
D
C
D
A
B
Sorry,
what
I
missed
that.
B
E
E
Yeah,
it's
provider
specific
they,
the
control
of
that
isn't
yours
as
a
consumer
of
that.
So
you
could
have
lots
of
cold
starts.
You
could
have
one
called
start
really
up
to
the
provider
of
God
of
how
they
do
that.
But
yes,
you
will
potentially
get
cold
starts
and
anything
that
we
had
to
start
up,
which
is
one
of
the
well.
You
heard
I'm
doing
some
performancy
type
things
and
writing
a
Blog
about
it.
E
But
yeah
the
hot
path
is
configuration
for
those
for
the
cold
starts,
which
it
might
be
fine
for
a
lot
of
things.
But
if
we
start
adding,
you
know
15
20
milliseconds
onto
these.
That
could
be
a
thing
if
we're
adding
nanoseconds,
probably
not,
but
you
know
every
second
counts,
Nano
or
millisecond.
Otherwise,.
B
D
D
D
Is
firing
off
the
service
collection,
traditionally,
all
our
extensions
fire
off
the
Builder,
so
these
configure
calls
allow
a
library
author
to
configure
the
Builder
without
needing
it
passed
in.
So
you
could
write
an
extension
that
the
user
just
calls
like
Services,
you
know,
add
thing
and
then
your
ad
thing,
you
can
put
it
on
your
Singletons,
your
transients
and
you
can
also
configure
open
Telemetry.
You
could
add
your
sources,
I,
don't
know
what
else
you
would
turn
on.
D
If
the
user
never
starts
up
their
Tracer
provider,
there's
different
ways
to
do
that,
you
can
call
add,
so
you
can
call
add
open,
Telemetry,
tracing
or
metrics,
or
you
can
just
ask
the
service
collection
for
the
final
provider.
If
that
never
happens,
then
these
calls
will
just
know
on.
They
won't
do
anything.
They're
just
registering
configuration
actions,
so
this
was
a
case
I
put
in
for
Martin
I.
Think
really
early
on.
There
was
another
guy
like
Eric
who
was
asking
for
this
stuff.
D
There's
some
internal
Microsoft
teams
that
you
know
are
building
these
sort
of
platforms
to
have
asked
for
this.
It's
really
like
a
super
Advanced
way
to
just
separate
all
your
concerns
in
your
startup
code,
so
you
don't
have
to
drop
dependencies
everywhere.
E
Log
into
the
SDK
team
about
the
is
your
SDK
team
about
something
similar
as
well,
so
within
the
SDK
you
can
just
turn
on
the
metrics
or
that
kind
of
stuff
without
having
to
have
it
within
your
open,
Telemetry
stuff,
so,
basically
making
it
the
easy
mode,
non-action
stuff.
So
people
don't
have
to
jump
into
having
a
big,
open,
Telemetry
method.
So
the
use
case
that
we
came
up
with
was
around
say
Entity
framework,
so
Entity
framework
would
have
a
when
you
set
up
Entity
framework.
E
E
If
that
has
all
made
sense,
it
makes
sense,
but
it
is
a
the
other
sort
of
use
cases.
We
had
were
third
pipe
providers,
so
myself,
obviously
from
honeycomb
and
being
able
to
do
things
like
adding
exporters
by
being
able
to
do
Services,
dot,
add
honeycomb
or
Services
dot,
add
New
Relic
as
a
Services
extension,
rather
than
it
being
off
the
back
of
the
Builder.
D
To
go
to
that
PR
with
the
documentation
there's
a
little
example
that
I
came
up
with,
but
yeah.
Basically,
what
Martin
is
saying
wrote
down
below
that
one
so
that
that
one
right
there
that
first
one
go
up
a
little
bit.
This
talk
is
going
to
change
a
little
bit.
I
don't
have
some
feedback,
but
if
you
go
up
above
this
code
block
so
I
have
some
text
there
saying
like
the
recommended
way,
is
to
do
it
off
the
Builder,
because
you
get
really
nice
code
completion
and
intellisense,
and
it's
just
highly
discoverable.
D
That's
just
my
opinion.
I
don't
know,
that's
should
be
our
official
guidance,
but
it
seems
reasonable
to
me
and
it
matches
like
everything
that
we
already
should.
If
you
go
below
this
one.
So
that's
the
attached
registration,
meaning
it's
attached
to
the
Builder.
If
you
go
below
it
here
now,
I
have
the
detached
example,
and
this
is
what
we're
talking
about
so
in
this
little
example,
I
cooked
up,
you're
calling
add
my
library
and
then
you're
calling
add
my
library
instrumentation
on
the
tracing
Builder
and
the
same
on
the
metrics
Builder.
D
So
you
imagine
a
really
big
Enterprise
application
with
a
lot
of
like
sub
libraries
you're
just
going
to
get
a
lot
of
kind
of
spaghetti
code
where
you're
calling
the
same
Library
like
two
or
three
times,
maybe
four
times.
If
there's
some
logging,
who
knows
if
you
scroll
down
a
little
bit
so
what
the
detached
allows
you
to
do
is
write
an
extension.
So
this
is
add
my
library,
it's
passing
in
the
service
collection
and
then
in
this
one
function
which
lives
in
some
Library.
You
don't
care
about.
D
So
then,
if
you
scroll
down
I,
guess
I
don't
have
the
final
example,
but
it
it
simplifies
your
startup
code,
so
that
all
you
need
to
call
is
that
one
thing
you're
just
calling
The
one
extension,
add
my
library
and
then
everything
just
works
sort
of
magically.
So
it's
just
kind
of
a
style
that
allows
you
a
little
bit
better
decoupling
separation
of
concerns,
and
then
what
you
lose
is
the
connection
to
the
Tracer
provider
Builder
or
the
meter
provider
Builder.
So
you
won't
get
kind
of
intellisense.
D
E
I
think
the
other
thing
to
note
on
this
is
that
this
is
I
would
say
more
aimed
at
library
authors
than
it
is
at
end
users
of
something
for
their
own
Library,
so,
whether
it's
your
internal
Library
teams
that
build
your
shared
libraries
or
whether
it's
people
who
are
building
like
the
Azure,
sdks
or
Entity
framework
sdks
or
service
bus
and
service
bus,
that
kind
of
stuff,
it's
aimed
at
those
sort
of
people,
because
that
example
that
you've
got
there.
E
If
you
were
to
provide
an
option
syntax
on
the
end
of
that,
you
could
actually
have
an
options
that
says,
enable
open
Telemetry
as
an
option,
which
only
does
those
if
you
want
it
turned
on.
So
it's
I
think
it's
more
aimed
at
library
authors
than
it
is
at
people
using
this
directly.
E
Well,
I
think
this
comes
onto
the
banner
for
me
of
how
do
we
make
things
easy
for
people
to
add
more
and
more
Telemetry,
and
this
to
me
is
the
easy
mode
stuff
that
Library
authors
can
now
just
either
do
it
by
default,
which
I
wouldn't
advise
them
to
do,
but
at
least
provide
their
users.
The
ability
to
just
go
yep
and
add
it
add
this
particular
extra
bit
to
it.
E
So
I
could
come
up
with
a
decent
example.
Maybe
we
want
to
add
some
stuff
to
the
docs
as
an
example.
So
there's
a
partial
options.
Class
example
that
we
had,
where
somebody
could
add,
say,
entity,
framework.open
Telemetry,
which
extends
the
options
class
to
have
this
extra
option
on
there
so
that
they
don't
have
to
bring
the
open
Telemetry
dependency
in
what
we
talked
about
really
early
on
was
building
this
into
maybe
an
abstractions
type
class.
E
D
Yep
I
mentioned
you
on
this
PR
Martin.
If
you
want
to
drop
your
example
or
read
it,
give
me
feedback
Alan's
beating
me
up
on
it.
E
I
I
watched
I
watched
it
all
happening
on
unfolding,
so
yeah
I
I
got
the
tag,
I
think
the
example
Works.
E
How
many
examples
we
want
in
there
is
a
an
interesting
thing:
I'm,
not
sure
how
many
would
be
useful
and
whether
it's
you
know
just
gonna,
be
a
wall
of
text.
If
we
add
more
in
there
ultimately,
I
saw
what
was
there
and
I
was.
You
know
pretty
happy
with
what
we've
with
in
the
end,
so
I
think
it
meets
a
lot
of
use
cases
in
case
anybody
didn't
get
the
the
tone
here.
I'm
really
I
really
don't
want
this
to
be
an
internal
I.
C
Yeah
100,
no
I,
I,
think
I.
Think
these
These
apis
are
phenomenal.
I,
the
main
yeah,
the
main
thing
I'm
beating
you
up
on
Mike
is
just
that.
You
know
end
users
who
maybe
may
not
be
Library
authors
just
coming
in
here
and
and
being
getting
confused
or
bogged
down,
but
but
I
think
the
functionality
that
we're
servicing
is
very
important.
E
I
couldn't
come
up
with
a
backward
then
detached
either
I,
don't
like
the
detached
and
attached,
but
yeah
I
couldn't
come
up
with
anything
better.
So.
B
Okay,
yeah
I
haven't
gone
through
this
bi
Yet
Michael,
but
yeah
sounds
like
this
is
going
headed
in
the
right
direction.
So,
coming
back
to
this.
B
D
You
will
there
so
anytime
you're,
you
know
once
you
have
the
meter
provider.
Builder
you'll
get
all
the
extensions
off
of
it,
but
you
won't
like
these.
Like.
A
D
D
B
D
Which
is
only
a
problem
because
everything
that's
ever
been
shipped
is
targeted
to
the
Builder.
So
if
had
we
done
it
differently
from
the
beginning,
it
would
be
no
problem,
but
because
that's
the
style,
it
has
always
existed
now.
We're
enabling
this
other
thing
we've
just
sort
of
put
ourselves
in
that
situation,
for
better
or
worse
I,
don't
know
if
it'll
be
a
huge
problem.
People
just
have
to
read
documentation
when
they
want
to
set
up
telemetry,
which
isn't
the
end
of
the
world.
D
There
are
some
talks
with
runtime
team
about
introducing
some
interfaces
into
diagnostic
source.
Like
you
know,
an
eye
meter
or
I,
don't
know
if
the
eye
activity
Source
there
is
some
push
for
that.
So
if
we
got
some
sort
of
like
fundamental
interface
in
there,
we
could
probably
make
it
even
nicer
where.
D
C
E
Yeah
I
would
expect
most
Library
authors
to
do
both
but
yeah
it
would
just
be
an
overload.
I
would
imagine.
B
D
D
E
I
I
think
I
think
it's
my
worry
would
be,
which
I
think
is
probably
everybody
else's
worry
as
well?
Is
we
get
seven
or
eight
different
ways
of
people
doing
it?
So
some
libraries
have
stuff
off
the
Builder,
some
have
it
just
off
the
service
collection
and
then
we
get
feedback
from
users
saying
I.
You
know
I
find
this
hard
to
understand,
which
one
should
I
be
doing,
that.
That
would
be
my
concern.
D
E
B
E
We
were
just
going
for
one
way:
I
would
go
off
service
collection,
not
off
the
Builder,
but
you
know
I
work
in
di
most
less
most
of
the
time,
so
I'm
slightly
biased.
D
Foreign,
we
could
also
differentiate
I
feel
like
instrumentation
or
libraries
that
are
only
adding,
like
listeners
strong
case
for
those
just
to
go
into
the
service
collection,
something
like
an
exporter
or
a
resource
detector.
Maybe
it's
better
suited
to
the
Builder
I,
don't
know
so.
I
feel
like
as
a
person
setting
up
a
host
I'm
very
interested
in
my
exporter,
like
I,
want
height
control
over
that,
whereas
things
I'm
listening
to
are
probably
just
want
to
register
those
libraries,
and
it
should
just
pick
them
up
magically
Maybe.
E
Yeah
I
think
processes
is
a
weird
one.
So
after
doing
a
lot
of
work
on
the
performance
stuff,
it
can
be
dangerous
if
people
aren't
explicitly
doing
it
as
part
of
their
open
Telemetry.
So
somebody
put
something
in
the
ads,
maybe
I
don't
know
one
or
two
milliseconds
as
part
of
a
processor.
All
of
a
sudden.
It
affects
everybody's
action
when
it
tries
to
dispose
the
activity
and
that's
a
problem.
So
processors
to
me
feel
like
that
might
be
something
we
want.
E
We
don't
want
people
to
do
as
part
of
service
collection,
because
it's
not
as
obvious
sources
yeah
that
to
me
was
the
the
whole
basis
of
this
was
being
able
to
add
the
sources.
Exporters
is
a
weird
one:
I
I
like
the
idea
of
not
having
to
do
that
on
the
open,
Telemetry
stuff.
So
I
can
register
my
exporter
early
on
in
the
the
flow
and
then,
if
somebody
adds
open
Telemetry,
it
will
also
be
exported
to
that
thing.
E
I,
like
that
kind
of
delayed
detached,
you
might
say,
configuration
of
that
stuff,
but
yeah
I
think
we
need.
We
need
to
see
what
users
do
with
it
and
what
library
orders
authors
do
with
it,
but
the
worry
is
it
gets.
You
know
this
all
cruft
of
lots
of
different
ways
of
doing
one
thing.
A
C
Adding
sources
is
the
main
use
case
for
the
detached
scenario.
One
question
in
my
mind
about
that
has
been
that
I
think
that's
kind
of
one
of
the
things
that
makes
the.net
SDK
a
little
bit
of
a
little
unique
from
the
other
language
sdks
in
that
the
other
ones.
Don't
really
have
this
notion
of
of
turning
on
or
explicitly
having
to
turn
on
a
a
source
of
telemetry.
C
I
vaguely
remember
I
was
having
conversations
in
the
past.
It's
about
maybe
changing
our
default
stance
there.
Just
simply,
you
know
all
sources
enabled
by
by
default.
C
Oh
please
don't
do
that
yeah,
no
I,
don't
I
I,
don't
know
whether
that's
right
or
wrong
yeah,
it
says,
obviously
sounds
like
there's
some
opinions
that
that
would
be
the
wrong
thing
to
do.
But
to
my
knowledge,
that's
how
the
other
some
of
the
other
language
sdks,
effectively
work.
E
Yeah,
looking
at
the
the
way
that
so
the
performance
hit
of
doing
something
like
that
in.net
at
the
moment,
with
every
activity,
Source
that's
available
on
every
single
one
of
the
things
that
that
would
be
diabolically
bad
for
performance
in
areas
that
would
be
unobvious.
E
But
yeah,
if
we,
if
we
break
it
down
to
those
sort
of
things
like
adding
a
source,
adding
a
processor
and
adding
an
exporter
primary
use
case
for
me,
is
adding
a
source
secondary
use
cases,
adding
exporters
the
processors
one
for
me
is
a
little
bit
of
a.
It
scares
me
a
little
bit
I
like
the
idea
of
the
resource
detector,
stuff
and
being
able
to
do
that
outside
of
the
open
dilemma
and
stuff.
E
But
again,
that's
probably
a
a
tertiary
use
case
for
me,
but
yeah
the
primary
is
adding
sources,
maybe
adding
some
pre-processing
of
those
sources.
C
Yeah,
this
is
all
really
helpful
for
to
getting
my
own
head
around
it.
It's
almost
kind
of
like
it's
like
SDK
concerns
or
API
concerns,
SDK
concerns
being
good
good
candidates
for
the
extensions
off
of
the
or
the
builders,
an
API
concerns
like
instrumentation
sources
and
so
on.
Being
a
good
candidate
for
the
detached
I
I
think
this
is
all
good
things
to
say
in
that
document
that
you're
drafting,
like.
B
So
like
coming
back
to
this,
the
public
apis,
so
we
would
we
want
to
have
both
right.
We
want
to
have
the
service
collection
one
and
also
the
trees
so
and
the
Builder
specific
ones,
and
for
each
of
the
detached
scenarios
we'll
have
two
apis
like
the
same
is
going
to
be
the
case
for
traces
as
well,
and
we
would
have
one
which
takes
in
an
action
of
Tracer
provider.
Builder.
D
We've
kind
of
moved
away
from
that,
because
it's
hard
to
modify
that
stuff,
there's
a
whole
bunch
of
rules
about
adding
other
overloads
with
defaults
or
changing
the
defaults
on
existing
ones.
So
kind
of
across
the
board
in
1.4,
anywhere
I
found
overloads
that
were
using
defaults,
I
just
switched
them
to
or.
B
But
like
most
of
our
current
exported
extension
methods,
they
just
they
follow
that
pattern
right
where
we
just
have
like.
If
there's
a
configured
action,
it's
optional.
D
C
Yeah,
generally
speaking,
you
know,
like
I
mean
this
is
super
General,
there's
obviously
exceptions
to
all
the
rules,
but
in
optional
parameters
in
public
apis
cause
can.
A
B
D
So
this
is
that's
technically
a
breaking
change.
What
I
did
there,
but
it's
pretty
low
risk
like
in
order
to
be
broken,
you
would
have
to
be
trying
really
hard
to
put
yourself
in
a
bad
State
like
you'd
have
to
be
invoking
things
via
reflection,
but
also
like
verifying
parameter
names
and
parameter
order.
A
D
B
D
So
that
method
got
removed,
but
then
it
got
put
back
without
the
default,
so
anybody
that
was
compiling
against
that
pop
one
they'll,
just
compile
against
the
new
one
and
they'll
be
fine.
So
it's
it's
Source
compatible.
It's
binary,
breaking
if
you're
doing
like
some
reflection
stuff
for
the
most
part
it's
safe
like
if
you
dropped
it
in
and
people
were
just
calling
it
normally,
it
would
work
if
you
rebuild
it
will
work.
It's
only
like
some
really
twisted
dark
reflection
cases.
That
would
be
a
problem.
B
A
E
In
the
many
many
years
that
doesn't
mean
I
didn't
deserve
to
be
like
hit
by
a
brick
wall
with
it.
So.
D
D
It's
kind
of
the
helper
thing,
I
think
Martin.
You
asked
for
this
I
think
other
people
have
asked
for
asked
for
it
as
well,
because
most
users
don't
really
understand
they're,
just
saying
like
ad
Jaeger
ad
Zipkin,
they
may
not
even
understand
there's
a
processor
there.
The
processor
is
kind
of
an
advanced
thing,
so
this
was
a
way
to
make
the
common
case
a
little
bit
easier
and
then
that
code
snippet.
We
were
looking
at
earlier,
where
I
had
to
export
our
extension
I
actually
call
into
this
to
even
simplify
some
of
the
code.
D
B
D
This
spaghetti,
we
have
all
over
the
place
where
every
exporter
options
just
has
its
own
type,
and
it
knows
how
to
create
a
batch
or
create
a
simple.
What
those
extensions
do
is
allow
you
to
like
remove
all
of
this,
so
it's
all
just
calling
into
kind
of
a
standard
set
of
helpers
and
if
we
ever
add
like
a
third
type
like
a
re-entrant
processor
batch
exporter
thingy,
we
wouldn't
need
to
go
and
update
all
of
this
code
everywhere.
E
So
I
cannot
tell
you
the
amount
of
times
where
I've
had
to
go
back
to
the
documentation,
to
try
and
find
out
the
actual
syntax
of
adding
my
own
exporter
between
the
the
ad
processor,
new,
simple
activity,
exporter,
processor
and
then
instantiate
my
processor,
on
there
hey.
This
is
I,
wouldn't
even
say,
quality
of
life.
This
is
something
that
should
have
been
there
for
a
long
time
ago,
because
we
had
exporters,
we
don't
add
processors
we
had
exporters
I
know
that
they
are
a
type
of
processor
bought
from
a
an
author's
perspective.
E
D
D
That's
not
strictly
required,
we
could
just
say,
add
exporter
and
you
give
it
either
the
type
you
want
or
you
pass
in
the
instance
and
then
we
could
it
takes.
If
you
go
back
to
that
API,
it
takes
that
options
class
that
we
looked
at
earlier.
So
it
takes
a
export
activity,
processor
options.
Instance,
if
you
don't
give
it
one,
it
will
just
new
one
up
through
the
options
API.
If
you
call,
if
you
pass
a
configuration
delegate,
you
can
impact
it
with
code.
D
E
Yeah
so
I
I
kind
of
fell
on
the
should
it
actually
be
full
methods
rather
than
two
and
then,
when
we
add
the
the
third
one,
maybe
six
methods.
E
So
what
you
actually
have
is
ADD,
simple,
processor
and
add
batch
processor
and
make
it
explicit
that
felt
a
little
bit
nicer
to
me
so
I
added
a
little
extension
method
when
I
was
playing
with
it
and
that
felt
a
little
bit
more
natural.
To
me
to
say:
oh
I,
want
to
add
a
simple
exporter.
All
right,
I
want
to
add
a
batch
one.
D
D
Maybe
you
can
be,
neither
I,
don't
know,
I,
don't
know
if
we
should
have
that
in
our
Trace
exporters
as
well
like
should
they
declare
like
I
am
safe
for
batch
and
simple
or
I'm
only
batch,
and
then
we
could
enforce
those
things.
I
don't
know.
This
is
to
me
a
weird
area
of
the
spec,
where
the
user
can
pick
a
processor
and
just
marry
it
with
whatever
exporter
they
want,
regardless
of
the
performance
implications
or
the
design
of
the
exporter.
Just
seems
very
strange
to
me.
E
Yeah
I
completely
agree.
It's
a
little
bit
weird,
there's
no
precedent,
I,
don't
think
for
this
kind
of
stuff,
so
yeah
I,
I,
agree.
It's
weird
and
the
only
better
thing
I
could
come
up
with
that
made
sense
in
my
head
was
the
doing
more
methods
and
making
that
a
context
of
the
method
name
rather
than
a
parameter
foreign.
D
D
C
E
Ultimately,
I
think
the
odd
export
classes
are
good.
I
think
they
serve
a
very,
very
real
purpose
and
helps
a
problem
that
we've
got
foreign.
If
we
added
you
know
a
add,
simple
one
I
think
you
could
do
that
later
down
the
line.
D
D
Could
add
those
in
addition
or
you
can
people
can
definitely
have
them
as
extensions
if
they
want
them,
I
don't
know
I,
don't
have
a
strong
opinion
either
way,
I.
Definitely
like
the
semantics
of
being
able
to
say
Builder
dot,
add
batch
exporter,
and
then
you
just
tell
it
like
the
type
of
tea
that
you
want
in
your
dinner.
There's
no
parameters,
there's
nothing
that
that's
very
clean.
E
E
Ultimately,
what
I
would
probably
have
is
these
ones
plus
those
other
ones
and
bring
those
other
ones
as
helper
methods
at
a
later
point,
I
know.
Ultimately,
this
is
a
helper
method,
but
you
know
more
helper
methods
is
fine.
E
E
B
We
could
continue
this
in
the
next
one
and
I
think
we
should.
There
are
like
we
still
have
kind
of
halfway
through.
Then
we
can
look
at
the
other
ones
as
well.
The
other
Main
exporters
unshipped
apis.
C
I
think
this
has
been
tremendously
useful
walking
through
this
is
a
group
if
we
think
we
need
some
additional
sessions,
because
we
want
to
move
through
this.
A
little
faster
I
would
be
open
to
that.
If
you
want
to
think
think
about
that,
we
can
put
them
on
the
calendar
schedule
at
some
time.
B
I,
if
you
don't
but
I,
think
like
that
last
time
last
six
meet
the
Sig
meeting.
Cj
was
suggesting
that
we
do
it
by
the
end
of
November,
because
that's
like
dot
Net
7
is
already
out
so
I.
Think,
like
I,
don't
know
the
exact
intention
like
he
did
say
that
it
could
be
any
time
it
would
be
January
as
well.
We
don't
have
to
like.
We
don't
have
a
specific
date,
but
like
usually.
D
D
E
Take
from
take
from
that
response,
whatever
you
will
as
to
whether
this
is
a
good
time,
I
wanted
to
make
sure
I
was
here
to
go
through
those
things
earlier
is
better
for
me,
but
obviously
you
know
it's
you're
the
main
contributors
here,
I'm
just
helping
where
I
can
so.
A
C
Think
that
what
is
what
is
like
8
A.M,
there's,
there's
a
number
of
Sig
meetings
that
are
that
are
at
8am,
I!
Think
that's
better
for
UK
time
right
as
well.
E
I
mean
I
can
make
most
of
those
work.
Just
yeah
I
mean
I
could
even
make
three
hours
earlier
work.
I
I
generally
work
in
honeycomb
is
all
PST,
so
I'm
generally
working
the
evenings
anyway.
E
E
Even
for
a
night
owl
like
me,
so
if
you
book
something
in
and
it's
you
know
three
hours
earlier
or
before
I'm
pretty
sure
I
can
make
it
work.
B
B
Okay
sounds
good,
I,
think
I'll
also
ask
sijo
and
his
availability
I
think
he
is
on
call
this
week.
So
he's
probably
busy
with
that.
But
yeah,
let's
decide
on
the
time
and
then
Martin
will
let
you
know.
E
Awesome
yeah,
you
ping
me
if
you
tag
me
in
the
cncf
slack,
that's
probably
the
easiest
approach.
Maybe
we
dropped
some
stuff
in
there
and
we
can
collaborate
on
a
time
from
there.
Yeah.