►
From YouTube: GitHub Quick Reviews
Description
Powered by Restream https://restream.io/
A
It
is
tuesday,
it
is
10
a.m
and
some
of
us
are
near
redmond
washington.
So
it's
time
for
an
api
review.
It
is
near
the
end
of
a
release,
so
we
have
issues
painted
in
red,
so
we
oh,
so
I
call
this
meeting
to
order.
A
B
Yeah,
I
can
give
some
background
what
we
are
trying
to
do
here
so
in
general,
about
like
wind
components,
doing
like
outband
operation,
like
you
know,
http
client,
for
example,
it
it
gets
the
tracing
context
and
transfer
it
over
the
wire
I
mean
through,
like
in
watched
tv
client,
http
headers,
so
the
tracing
information
will
get
transferred.
Those
htv.
C
B
The
the
issue
here
is
just
to
currently
I
got
like
you
know.
There
is
no
way
about,
like
you
know,
you
can
control
this
because,
like
the
component
is
just
like
no
http
client,
for
example,
just
like
you
know,
get
the
header
and
put
it
in
some
specific
format
to
stop
some
specific
header
names
in
the
http
headers
and
just
transfer
it
and
in
the
other
end
like
you
know,
for
example,
sbn
net
also
try
to
read
some
specific
headers
and
just
extract
that.
B
B
So
propagators
is
the
solution
here,
for
example,
about,
like
you
know
today,
if
we,
if
you
are
transferring
what
you
call
it
like,
you
know,
key
value
pairs
for
the
context,
addressing
context,
for
example,
which
is
we
internally
call
it
baggage,
so
we
transfer
it
like
you
know,
with
some
header
names
called
correlation
context,
and
currently
I
mean,
like
you
know,
w3c
specs,
which
is
still
under
draft,
is
still
draft.
I
mean,
like
you,
know,
it's
not
finalized,
yet
they
recommended
to
use
the
header
name
as
a
baggage
instead
of
correlation
context.
B
So,
for
example,
about
like
you
know,
if
you
want
to
to
conform
to
this
w3c
specification,
so
you
have
to
change
the
way
we
are
transferring
this
dressing
context
and
change
the
header
name
from
correlation
context
to
baggage.
We
got
some
other
scenarios
also
about,
like
you
know,
for
http
client
I
mean
by
default.
I
think
we
we
just
transfer
the
the
tracing
context,
all
the
time
I
mean
so
you
it's
it's
hard.
I
mean,
like
you
know,
to
configure
anything
to
stop
transferring
this
header.
If
nobody
cares
about
it.
B
So
we
got
this
scenario
about
like
you
know
we
need
to
suppress.
I
mean,
like
you
know,
injecting
this
trace
context
stuff
to
the
to
the
wire
I
mean.
If
we
need
to,
there
is
other
scenarios
I
mean
we
can
get
into
this,
but
but
this
is
a
generic
rule
about,
like
you
know,
boobagator
is
going
to
give
you
more
control
about,
like
you
know
what
what
you
can
transfer
and
you
can
customize
the
way
you
transfer
stuff.
I
mean
the
the
tracing
context
stuff
to
the
world.
B
B
C
I
have
a
high
level
concept
or
question,
and
maybe
this
is
just
me
being
dumb
or
maybe
it's
just
me
not
understanding
the
naming,
but
I
look
at
this
api
and
I
have
no
idea
what
I'm
supposed
to
do
with
it
like
what
what?
Why
is,
why
is
it
called
a
propagator?
What
is
it
propagating
from
what
from
where
you
know
from
who
to
who?
B
Yeah,
that's
a
good
question.
Yeah!
Thank
you.
So
basically,
we
are
sticking
with
with
the
names
that
it's
proposed
by
open
telemetry.
This
is
not
the
name
that
we
we
choose.
I
mean
this
is
what
we
did
also
in
other
areas
like
in
metrics
and
in
tracing
in
general.
So
we
are
trying
to
be
to
sticking
with
the
names
that
it's
proposed
originally
by
by
open
telemetry
yeah.
B
C
C
When
I
look
at
types
I
usually
infer
semantics
and
behaviors
and
things
from
their
names,
I
don't
know
what
I'm
supposed
to
be
inferring
from
these.
So
even
if
we
choose
to
go
with
these
names
because
we're
choosing
pre-existing
ones
from
open,
telemetry,
I'd
like
to
understand
how
I
should
be
thinking
about
the
terms
that
are
being
used
here.
What
what
am
I
propagating?
What
is
the
text
that
I'm
mapping
from
what
to
what
etc.
B
B
E
So
when
I
understand
it,
basically
what
it
is
supposed
to
do
is
basically
it
standardizes
how
you
can
get
from
a
particular
state
like
http,
client
or
whatever
or
sorry
from
an
activity.
Basically
it
maps
from
an
activity,
for
example,
to
an
http
request
right
so
like
the
the
and
it
does
a
text
based
mapping
right,
it
extracts
some
data
from
the
activity
and
stuffs
it
into
the
http
request
right.
That's
what
inject,
I
guess,
does
that's
right
and
then
extract
on
the
other
side.
E
B
E
So
one
question
I
have
is
so
we
basically
have
a
few
built-in
ones
the
legacy
one,
which
is
a
bit
weird,
that,
given
that
we,
you
know,
we
haven't
shipped
it
before.
So
we
start
with
a
legacy
one.
Then
we
have
a
pass
through
one
and
then
a
no
output
one,
and
then
we
have
a
current
one.
So
who
who
will
set
the
current
one
and
what
is
current
like
threat,
local
or
is
that
you
know
process
wide
or
is
it
async
local
or
like
what?
What
is
what
does
corn
refer
to.
B
Current
is
just
a
static,
global
static
yeah,
but
we
are
expecting.
I
mean
like
this
is
just
like
what
we
are
exposing
in
dot
net
sex
and
we
are
trying
to.
I
mean,
like
you
know,
to
to
look
at
like
in
dot
net
seven
or
something
to
look
at.
If
other
libraries
I
mean
like
http,
client
or
any
other
libraries
want
to
have
more
specific
configuration
for
the
library
itself,
so.
B
E
E
B
C
D
I
I
think
I
got
your
question
for
now.
The
intent
is
current
is
set
like,
like
you
said
in
main
by
the
user,
and
then
libraries
will
just
read
the
value
of
current
the
the
idea
is,
if
that
isn't
like
granular
enough,
then
libraries
can
provide
library
specific,
like
api,
so
http
client,
for
example,
could
in
future
allow
you
to
set
a
propagator
on
the
instance
of
http
client
and
not
use
the
global
current.
B
Okay,
it's
it's
going
to
default
to
the
what
we
call
it
legacy
propagator.
We
will
get
into
that
I
mean,
but
but
this
is
basically,
you
can
think
about
legacy.
Propagator
is
what
it's
the
current
behavior
we
have
today.
It's
exactly
behaving
like
what
we
are
transferring
the
trace
context
today
from
http
client
or
receiving
it
in
like
an
sb
equipment.
E
B
What
happens?
No,
no,
no
I
mean
so
injector
extract
has,
as
I
mentioned
carrier
is,
is
just
like
a
big,
opaque
object
tool
to
to
the
api
itself.
I
mean,
so
we
don't
do
anything
with
it.
We
just
like
getting
it
in
the
api
and
cool
and
passing
back
to
the
callback
again.
So
it's
it's
opaque
for
us.
So
imagine,
like
you,
know,
http
client,
for
example.
What
like
you
know,
is
trying
to
do
something.
So
it's
going
to
call
inject
and
passing
like
http
request
and
inside
the
api.
B
E
B
E
B
No,
I
mean
like
it's,
it's
not
just
like
you
know
getting
the
information
and
just
sending
as
it
is,
I
mean
you
have
to
have
to
do
some
operation,
for
example,
about,
like
you
know,
activity
inside
activity,
there's
multiple
things
I
mean
like
you
know.
We
have
like
three
experiments.
We
have
three
still
we
have
baggage,
I
mean
multiple
things
is
not
just
one
thing,
so
we
will
call.
We
will
call
the
setter
callback
with
every
field
of
that.
E
B
So
this
is
why
I
mean
like
inject
extract
has
to
be
like
virtual
or
abstract.
So
so,
if
anybody
want
to
create
their
own
propagator
with
some
with
any
customization
they
they
need
to
override
this
inject
and
extract
to
do
whatever
it
is.
They
want,
for
example,
about,
like
you
know,
in
open
telemetry,
they
have
like
propagators
called
the
b3
bullgetter,
which
is
transfer
stuff
with
some
different
header
names,
like
you
know,
these
three
underscore
transparent,
for
example,
which
is
like
nobody
I
mean,
like
you
know,
specifically,
I
got
like
you
know.
B
E
So
let
me
try
to
understand
the
sensor.
Basically
text
map
propagator,
what
it
does.
It's
like
the
inject
and
extract
methods
effectively
determine
which
part
of
the
activity
gets
transferred
to
what
set
of
key
value
pairs
effectively
and
those
are
being
forwarded
to
the
to
the
setter,
and
then
the
set
is
responsible
for
somehow
stashing
the
key
value
pair
onto
the
carrier.
That's
it.
A
So
in
the
highlighted
line,
a
better
example
of
this,
since
it
put
an
http
request
here,
would
have
been
httprequest.headers.ad
name
value
or
whatever
the
right
api
is
right.
So
the
the
propagator
doesn't
know
anything
about
http
client
stack
and
http
client
stack,
isn't
necessarily
reaching
back
in
to
this
api
to
get
the
data
out,
somebody
has
to
call
inject
to
shove
the
data
from
one
side
into
the
other.
B
A
B
E
B
No,
I
mean
like
so
inject
and
extract
is
going
to
format
the
data
that
is
going
to
be
transparent.
The
way
they
the
propagator.
E
E
B
So
today
I
mean
like
for
our
components
I
think
it's
http
client
is
is
the
main
main
component
that
is
going
to
use
inject.
E
D
B
Okay,
just
to
make
sure
about,
like
you
know,
open
telemetry
just
defines
the
names
of
text,
map
propagator
and
inject
extract
names,
but
the
rest
of
the
names
in
this
proposal
is
as
our
name.
So
we
are
free
to
to
change
the
other
names
like
you
know,
legacy
propagates
or
pass
through
whatever.
E
B
Yeah,
the
name
of
the
of
the
headers-
I
mean
that
this
propagator
is
support,
for
example,
about,
like
you
know
our
our
current
legacy,
I
mean
like
the
ways
that
we
transfer
the
the
trace
context.
Today,
we
we
have
header
names
like
transparent,
tristate
and
correlation
context.
B
E
E
B
The
first
first
overload
will
will
just
return
the
id
which
is
really
the
trace
parent
id
and
the
state
which
is
would
be
trace,
state
id
this
transparent
and
twisted
yeah
those
what
are
trading.
It
returns,
just
the
values
of
that
and
the
getter,
the
getter
callback.
Actually,
when,
when
you
see
the
getter
callback,
it
takes
the
field
name,
which
is,
if
you
can
see,
and
this
field
name
will
be
like
you
know,
transparent
or
tristate,.
E
B
E
B
Okay,
let's
stick
by
example
about,
like
you
know,
if,
if
you
are
an
asp.net
and
you
are
reading
http
headers
for
example,
so
you
will
call
extract
at
that
time.
So
svnet
was
going
to
call
extract
and
in
extract
it
would
burst
us
the
getter
callback
right
and
inside
the
propagator.
We
say:
okay,
like
we
are
in
legacy,
for
example,
so
I
need
to
read
like
transparent
field
from
the
http
headers.
B
So
I'm
going
to
I
mean,
like
this
api
extract,
is
going
to
call
the
getter
and
passing
the
field
name
transparent
and
expect
to
get
the
the
sb
net.
It
will
give
it
the
value
from
the
header
that
transparent
value
is
at
that
time
after
we,
after
get
a
return,
I
mean
we
will
have
like
the
transparent
value,
which
is
we
can
parse
it.
I
mean
the
the
propagator
percept
in
the
way
that
it
can
be
used
in
the
operation.
B
H
H
To
be
a
callback,
so
my
thought
here
is:
if
the
out
parameters
were
the
propagator
getter
callbacks
parameters
right,
so
that
would
be
like
carrier
and
field
name.
If
I
had
like
some
like,
I
don't
know.
Where
are
these
callbacks
coming
from?
If
I
have
some
static,
callbacks
somewhere
that
I
have
to
pass
in
anyway,
I
could
just
call
it
on
the
output
that
would
be
the
carrier
and
field
name
right
like
why
do
I
need
extract
to
call
my
method
for
me.
B
Okay,
imagine
imagine,
like
you
know,
you
are
a
spinet
and
you
don't
have
you
you?
There
is
a
propagator
like
these
three
progresses
that
nobody
knows
about
it.
I
mean
asbent
doesn't
know
about
it
and
ap3
propagator,
for
example,
have
their
own
specific
headers,
which
is
isbnet,
has
no
idea
about
it,
and
so
how
do
you
expect
isbnet
to
support
b3.
H
H
H
D
No,
no,
so
those
are
two
different
pieces
of
information,
so
the
the
two
like
extract
calls
are
for
two
different
pieces
of
information.
D
So
like
in
this
usage
example
right,
the
the
propagator
will
call
extract
multiple
times,
so
it
will
pass
in
multiple
header
values
and
that's
how
it
gets
returned
those
values.
And
then,
if
you
see
like
line
300
onwards,
once
I've
extracted
the
request
id
and
the
trace
state,
I'm
able
to
set
it
on
the
activity
like
that's.
This
is
what
like
idiomatic
usage
by
a
library
would
look
like
right
after
the
extract
and
then,
if
you
choose
to
proceed,
you
can
also
call
extract
on
baggage,
which
is
like
line
311.
E
So
what
I
don't
quite
understand
is
like:
why
does
the?
Why
does
the
actual
callback
for
the
getter
differ
between
these
two
overloads,
because
it
seems
all
they
do
is
basically
say:
how
do
I
retrieve
the
header
value,
given
the
field
name
right
so
and
both
just
index
into
the
header
dictionary
so
like?
I
don't
even
understand
why
they
would
differ.
B
E
Like
it
seems
to
me,
like
all
that,
this
thing
does
is
basically,
when
you
request,
basically
on
the
on
the
first
overlap,
when
you
just
request
the
request
id
and
the
trace
date,
I
assume
extract
is
just
probing,
for
you
know
the
three
four
five
six
different
names
under
which
the
id
could
have
been
stashed
into
the
into
the
into
the
headers
right
is
that
what
extract
basically
does
for
you.
A
C
E
B
B
B
E
Thought
so,
basically,
what
this
method
effectively
encapsulates
is:
oh
yeah,
the
id
could
have
been
stashed
under
trace
parent
or
under
request
id
right,
but
they
kind
of
still
like
I'm
still
not
sure
like
that
seems
to
me,
like
they
probably
get
a
get.
A
callback
idiomatically
should
probably
be
the
same
between
the
two
right,
because
all
it
does
is
just
says.
Given
the
key
give
me
the
value
right,
so
I
don't
know
why
it
would
differ
for
the
id
and
state
versus
the
the
other
one.
B
A
Well,
I
think
I
think
emo's
confusion
and
if
not
his
mind
is
you
have
the
same
static
object,
string
out
string
here
and
I
can't
highlight
two:
oh,
I
can
make
one
blue
and
one
yellow,
so
the
the
yellow
and
the
blue
don't
do
the
same
thing,
even
though
they
do
the
same
thing.
A
B
A
A
E
E
B
B
Yeah,
okay
yeah
I
got
where
is
the
confusion
is
coming
from?
Okay,
so
the
two
parameters
that
is
inside
the
callback.
I
mean
it's
just
providing
for
optimization
reason
because,
like
you
know,
most
of
the
time
the
returned
value
that
we
are
getting
from
the
callback,
it
will
be
streamed,
but
we
have
some
cases
that
it
will
be
multiple
string.
It
will
be
enriched.
B
B
E
E
C
C
B
C
Themselves,
good
because
we've
spent
45
minutes
with
a
fair
number
of
relatively
intelligent
people
on
this
culture.
E
Yeah
I
mean
now
that
I
understand
what
you're
trying
to
achieve
it
makes
sense,
but
yeah
it
seems
like
the
api
shape
is
not
helping
you
like
it's
like.
I
don't
necessarily
know
what
to
do
better,
but
it
just
seems
like
it's
not
very
obvious
from
looking
at
the
apis.
What
the
intended
interaction
pattern
is.
E
Is
that
what
the
propagator
does
it?
Basically,
controls
which
keys
to
send
and
and
how
to
format
the
values
right
and
then
and
then
the
the
the
actual
callbacks
are
just
effectively
the
the
glue
code
that
you
know
given
a
carrier?
How
do
you
put
these
key
values
onto
the
wire
and
how
do
you
get
them
back
from
the
wire?
So,
basically.
E
E
H
So
the
like
the
baggage,
for
example,
isn't
directly
the
output
from
the
multiple
calls
to
the
propagator
callback.
It
could
be
like
formatted
by
the
propagator
to
add
like
stuff
to
the
string
like
I
don't.
I
don't
even
know.
B
Like
it
just
seems
like
it
knows
this,
so
the
propagator
I
mean
the
propagator
with
the
package,
for
example.
Baggage
is
key
value
pairs,
so
the
propagator
was
going
to
take
this
key
value
here
and
formatted
to
into
just
like
one
string
at
the
end,
which
is
included
with
the
url,
including
and
with
some
specific
formats,
that
htv
can
be
transferred
through
http
headers.
H
B
B
B
It's
you
have
key
key
one
value,
one
key,
two
value
two
and
so
on,
and
this
I
mean
the
specs
saying
that
while
you
transfer
this,
you
have
to
format
it
like.
You
know,
key
equal
value
and
comma
and
the
key
value
have
to
be
in
a
specific
encoding
like
you
are,
including
so
you
you
don't
allow
anything
to
transfer
there,
and
all
of
this
key
value
will
at
the
end,
will
be
formatted
in
just
one
string,
which
is
would
be
common,
segregated,
separated.
C
D
B
A
I
get,
but
this
comes
back
to
like
if
the
la,
if,
if
it's
that
the
application
is
using
in
libraries
and
each
of
them
uses
a
different
transport
mechanism,
each
one
of
those
is
carrying
their
own
propagator,
so
no
one's
calling
the
default
propagator.
So
why
is
there
a
default
propagator
or
any
propagators?
Frankly,.
D
I
I
think
that
the
question
is
sort
of
we're
not
optimizing.
For
that
case,
we're
trying
to
optimize
for
not
coupling
the
libraries
to
the
specific
version
of
the
specification
right,
like
as
an
example,
the
baggage
specification
was
originally
called
correlation
context
and
the
header
was
renamed
and
like
http
client,
wasn't
aware
of
the
rename
what
we
don't
like,
I
think
we're
less
worried
about
the
transport,
because,
for
the
most
part
people
are
using
http
or
http
like
safe
transports.
Where,
like
when
you
url
and
code
stuff,
they
can
send
it.
A
No
like
it
like
my
the
amount
of
work
that
has
to
be
done
here.
I
guess
I'm
not
understanding
who's
supposed
to
be
doing
it
in
an
average
http
call
that
they
want
tracing
to
flow.
If
the
average
developer,
who
wants
tracing
to
flow
needs
to
touch
this
type,
then
we
should
just
delete
it
and
they
should
do
everything
manually.
A
If
this
is
somehow
built
into
infrastructure
and
things
just
worked
by
magic,
then
I
guess
it
maybe
makes
sense
except
it's
magic,
which
means
it'll,
never
work
right,
or
rather
it
will
work
right
for
80
of
the
people
and
the
other
20
can't
ever
figure
out
what
to
do
about
it
like
it
it.
I
don't
understand
the
value.
D
So
that's
the
status
quo
right,
it
is
magic
and
it
works
for
80
of
the
cases.
If
you
go
back
to
the
issue,
we
sort
of
have
identified
the
other
20
of
cases
where
it
didn't
work,
and
so
the
hope
is
propagators
would
work
for
all
of
them.
So
like
a
couple
of
ones
that
we've
concretely
identified
or
one
people
want
to
use
their
own
like
custom
header
names
right
like
I
want
to
use
x,
dash
my
organization's
correlation
id
instead
of
like
request
id
well,
you
can
do
it
with
the
propagator.
D
The
other
use
case
we've
heard
is
people
are
using
like
things
like
envoy
and.
A
E
A
Right
right,
so
if
this
type
of
callback
is
always
supposed
to
just
effectively
be
this
object,
add
key
value
pair,
here's,
the
name
and
here's
the
value,
and
it's
just
supposed
to
be.
I
don't
know
where
your
setter
lives.
Please
map
your
setter,
then
I
then
I
guess
that
makes
sense
that
the
propagator
is
trying
to
control
the
http
header
name.
E
I
mean
that's
my
understanding,
because
they're
basically
like
to
the
earlier
example
right,
you
could
imagine
you
have
two
transports,
you
have
a
grpc
based
one,
you
have
an
http
client
one
and
the
propagator
itself
doesn't
know
you
know
the
underlying
transport
and
the
underlying
transport
doesn't
know.
We
know
what
what
header
values
activity
needs
to
inject
right,
and
so
you
have
that
separation
of
concerns
effectively.
A
A
A
B
B
E
Well,
not
the
transport,
it's
basically,
the
the
fields
is
defined
by
the
propagator
right,
the
because
the
propagator
is
the
party
that
given
an
activity,
creates
a
set
of
key
value
pairs
right,
and
so
so
my
understanding
is
that
whatever
keys
the
propagator
con,
you
know
constructs
that's
basically
what
fields
returns,
and
so
those
are
the
values
that
are
passed
to
the
callback
under
the
the
field.
Name,
slash
the
second
argument
right
and
then
the
transport
ideally
wouldn't
with
those
right.
E
It
would
just
take
the
key
and
write
it
into
the
header
collection
right,
but,
strictly
speaking,
nothing
prevents
you
in
the
callback
to
say
switch
right
and
say
if
the
key
is
x,
return
it
to
y
and
then,
when
you
later
ask
for
x.
Well,
I
actually
retrieve
y
right.
I
mean
that
you
could
do
this
at
the
transport
level
right.
For
I
mean
you
could
imagine
a
very
simple
case
where
the
underlying
transport
requires
them
to
be
in
a
certain
format
that
the
headers
aren't
right,
for
example,
dashes
aren't
allowed
or
something.
E
E
D
A
B
A
Mean
you
call
inject
and
it
either
calls
it
with
the
thing
or
it
doesn't.
You
call
extract
it
calls
it
with
the
thing
or
it
doesn't.
What
are
you
going
to
do
if
it
like,
even
the
one
you
gave
as
an
example,
even
if
it
supports
multiple
fields,
it's
not
always
calling
all
of
them
like
this
is
only
conditionally
called
right.
So
knowing
the
possible.
B
C
I'm
also
curious
how
this
interacts
with
schwab.
You
expect
to
you
expressed
a
concern
earlier
that
component
had
to
hard
code
in
the
name
of
the
field,
and
then
the
name
of
the
field
changed.
So
if
the
name
of
the
field's
changing,
how
is
the
component
going
to
use
this
fields
collection
to
look
up
whether
a
particular
thing
is
supported
or
not?.
B
In
general
case,
I
don't
think
the
component
need
to
check
that
I
mean
so
the
component.
It
should
be
like
you
know
the
header
name
and
this
stuff
most
of
the
time
it
will
be
transparent
to
the
component.
So,
basically
about
like
you
know
when,
when
the
component
is
getting
the
code
back,
they
just
take
the
field
name
and
try
to
look
it
up
in,
like
htv
headers
blindly,
I
mean
like
they
don't
have
to
check
the
field
name.
B
What
is
the
name
and
or
whatever
is
that,
but
what
I'm
trying
to
say
yeah,
I
see
the
point
about
like
the
question
about
like
what
is:
what
is
the
values
that
the
fields
property
is
is
giving
to
the
to
the
users
of
the
propagators
yeah
I
and
most
of
the
time
they
most
of
the
people
will
not
care.
I
mean
this
is
just
providing
about.
B
So
if,
if
somebody
want
to
see
about,
like
you
know,
does
this
propagator
can
handle
also
trace
context,
or
not
I
mean
they
can
check
that.
But
this
is
not
the
main
scenario
that
we
are
we
are
targeting.
I
mean
it's.
It's
feels
is
just
provided
as
like
extra
information
that
maybe
it
can
help
for
them
for.
D
D
I
I
actually
interpreted
differently
derek
what
I
thought
is
like
say:
I'm
asp
net
code
right
like
knowing
that
there's
something
called
baggage.
I
make
make
it
a
field
on
like
http,
like
my
http
contacts,
so
that
I
don't
have
to
allocate
a
new
like
baggage
every
single
time,
because
I'm
pulling
my
http
context,
I
thought
of
it
purely
as
a
perf
optimization,
because,
as
a
library
author,
I
don't
care
what
header
names
you
use
right,
I'm
not
going
to
check
for
compat.
The
whole
point
is
to
like
delegate
that
responsibility
to
the
propagators.
A
A
So
the
question
is
really:
when
would
you
call
the
field?
When
would
you
read
the
fields
property
and
what
are
you
going
to
do
with
the
values
that
are
in
it?
If
it's
just,
if
it's
for
diagnosis
of
a
person
and
a
debugger,
then
that
could
be
its
value
and
then
the
question
is:
is
that
going
to
be
useful
enough
that
it
should
be
done
because,
honestly,
it's
just
a
thing
that
can
be
wrong
between
or
on
the
class
right
now
I
don't.
I
don't.
A
E
That's
kind
of
my
concern
like
I
mean
because
it's
just
what
sherrod
said
earlier
is
like,
generally
speaking,
my
understanding
is
that
the
whole
point
of
this
type
is
to
effectively
encapsulate
what
fields
are
being
used
and
what
the
format
of
the
field
of
the
field
values
is
right.
So,
in
which
case
people
should
not
really
have
a
dependency
on
particular
names
in
those
things
right
that
that's
my
understanding
of
the
abstraction.
So
if
you
expose
it
as
if
as
a
property,
it
kind
of
seems
to
me,
you
know
you're
effectively
doing
what
you
said.
E
E
B
E
So
that
so
the
first
line
makes
sense
to
me,
so
I
assume
you
would
do
you
would
call
inject
every
time
you
make
a
request
right,
but
can
you
reuse
requests?
I
thought
I
thought
a
request
is
a
as
a
one-time
object
and
if
you
can
reuse
request,
then
the
line
makes
sense
to
me
because
it
basically
says
before
you
call
the
inject
clear,
all
the
ones
that
this
thing
might
set
and
then
you
know
you
call
inject
and
it
will
only
set
the
ones
it
cares
about.
D
E
A
A
D
E
A
E
Yeah,
basically,
if
the
contract
is
inject,
never
clears
the
calling
party
has
to
clear.
Then
the
calling
party
needs
to
know
what
keys
were
set
right
and
then
it's
either
the
calling
party's
responsibility
to
track
which
fields
were
set.
In
which
case
you
say
you
don't
have
the
fields
collection,
it's
your
job
to
keep
track
of
that,
in
which
case
yeah
you
can
use
every
any
field.
D
D
E
D
E
That's
what
I
meant
so,
but
if,
but
so
that's
what
I
meant
by
the
caller's
responsibility
to
clear
them
right.
So
if
the
caller
is
responsible
for
clearing
them,
then
it's
it's
one
of
two
things:
either
you're
telling
me
the
fields
by
the
fields,
property
that
I
have
to
be
clearing
or
I
have
to
keep
track
of
the
fields
myself
like.
It
seems
weird
to
me
that
you
give
me
80
of
them
because
it
doesn't
that
doesn't
make
my
job
any
easier
if
I
have
to
keep
track
of
the
other
20
right.
E
B
A
Because
it
sounds
like
the
clearing
the
you
know,
for
each
field
and
fields,
clear
it
off
of
the
carrier
before
calling
inject
is
not
a
thing
that
has
been
written
in
any
of
the
prototyping
you've
already
done
which,
but
if
that's
the,
if
that's
the
thing
that
one
is
supposed
to
do,
then
it
makes
sense
to
expose
it.
But
it
does
seem
like
there's
somewhere
on
the
extract.
There's
supposed
to
be
a
thing
called
keys,
which
is
well
fields.
E
Oh,
I'm
so
to
be
clear,
I'm
fine
with
saying
there's
a
field
collection.
The
only
thing
I
think
we
were
debating
is
like
what
fields
are
in
there
and
like
when
you
said
earlier,
it's
like.
Well,
we
give
you
some
of
them,
but
not
all
of
them.
Then
my
question
is
okay.
How
do
I
use
this
property
reliable,
like
what's
the
contract
of
what
I
can
expect
to
be
in
there
versus
not
in
there
and
and
that's
kind
of
my
only
concern
like
I
mean
I'm
fine
with
exposing
the
field.
E
As
I
said
earlier,
like
just
from
a
diagnostic
standpoint,
I
can
see
that
being
valuable,
but
then
I
have
to
there
needs
to
be
a
contract
on
what
I
can
expect
to
be
there
like.
It
seems
weird
if
you
give
me
x
y,
but
then
you
know
later
on
in
the
in
the
inject
method.
You
will
call
me
with
z
right,
that's
the
thing
I
don't
understand
because
then.
B
E
D
E
E
E
E
B
A
A
I
think
that
if
you're
exposing
it,
you
should
have
a
piece
of
sample
code
that
says
what
the
average
person's
expected
like
someone
who's
using
this
like.
If
you
know,
grpc,
is
wiring
it
up
when
they
would
use
it,
because
it
sounds
like
something
somewhere
suggests
that
someone
is
supposed
to
for
each
field's
carrier,
clear
field
field,
and
I
it
to
me
it's
unclear
when
that's
actually
supposed
to
happen,
and
so
it'd
be
great.
A
If
you
could
write
that
down,
I
don't
need
to
know
it
right
now,
but
it
sounds
like
that's
the
reason
it's
in
the
spec
and
it
would
be
great
to
say
this
is
when
you
would
write
this
kind
of
clearing
and
then
the
extract
method.
It
looks
like
the
spec
defines
the
getter
that
you
have
and
then
also
something
to
acquire
the
keys,
and
you
skipped
that
part
and
that's
what
is
supposed
to
say.
A
If,
while
there's
no
propagator,
that
does
this
extra
dynamic
work,
you
don't
need
it,
but
it
seems
like
right
now,
you're
in
the
middle
somewhere,
if
you're
adding
things
because
the
spec
says
to
add
them,
but
then
you're
cutting
things
from
the
spec.
So
it
feels
like
we
should
either
have
a
good
api
or
we
should
match
the
spec,
and
this
is
neither.
A
B
E
A
E
F
A
So
I'm
not
saying
we
need
the
key,
like
I'm
just
saying
this.
The
the
spec
talks
about
a
keys
thing
to
solve
emo's
missing
20
to
the
field
names,
I'm
questioning
the
value
in
the
spec,
but
I'm
just
pointing
out
our
api
is
not
spec
complete
and
it's
also
not
easy
to
use,
and
I
think
that
if
we
it
feels
like,
if
we're
making
a
spec
completeness
argument,
we
can
do
that
and
it's
spec
complete
and
if
you
read
the
spec
and
understand
it,
you
can
call
it
or
we
should
make
something.
E
E
So
is
this
literally
all
the
information
I
mean,
I
guess
my
question
is:
if
we
ever
have
to
somehow
expect
another
set
of
key
value
pairs,
then
the
api
ship
wouldn't
work
super
well
right,
because
you
basically
have
an
overload
of
extract.
That
you
know
would
also
be
without
iron
removal
of
key
value
pair
right.
So.
E
Sorry
what
I
meant
by
is,
like
you
know
if
you
have
to
like,
because
baggage
is
a
bunch
of
key
radio
pairs,
but
if
there's
something
else
that
also
happens
to
be
key
value
pairs,
then
that's
already
taken.
Basically,
that
was
my
point.
A
E
A
H
B
B
B
A
A
Otherwise,
it's
presumably
you
would
either
clear
and
then
call
inject
or
you
would
call
inject
and
then
send
and
then
clear
or
like
somewhere
in
there
there
should
be
the
canonical.
When
do
you
loop
over
this
collection
and
then
the
extra
twenty
percent
of
things
that
got
added
are
impossible
to
detect
unless
you
map
them
in
your
inject
callback
and
then
good
luck
with
that,
but
that's
a
hole
in
the
spec,
not
a
hole
in
the
implementation.
E
The
other
question
on
an
api
ship
is,
it
might
be
useful
to
also
have
a
delegate
for
the
setter,
so
you
can
actually
name
them
like
in
your
own
sample
code.
I
saw
you
edit
comments
for
a
carrier
and
field
name
and
field
value
right,
so
it
seems
when
you
already
have
a
nested
type
for
the
ghetto
you
might
as
well
want
to
have
one
for
the
setter
yeah.
B
E
Yeah,
that's
the
thing
right
I
mean,
I
think.
Funks
and
actions
are
fine.
If
people
intuitively
can
understand
what
the
parameters
are
right,
but
once
you
have
string
string,
comma
in
comma
string,
it's
like
I
don't
have
a
idea
of
what
each
of
these
are
right.
Okay-
and
I
mean
you're,
already
kind
of
in
that
world,
where
it's
a
bit
kind
of
nuanced,
so
I
think
naming
them
is
a
good
thing.
B
B
Yeah,
we
didn't
use
the
generic
t,
because
we
are
thinking
about
the
performance
about
liking
to
have
virtual
generic
while
calling
it
I
mean
like
it's
it,
it
will
have
some
overhead.
This
is
why
we
went
with
object
instead
of
t
right.
So
it's
for
optimization
purpose.
I
mean
we
need
this,
this
method
to
be
fast
as
as
possible,
because
it's
used
millions
of
times
right
yeah.
So
this.
E
A
E
A
E
If
they,
if
even
if
they're
all
unified
to
the
same
thing,
you
still
have
to
go
through
the
double
dispatch,
basically
fair
enough,
I
think
that's
the
performance
cost
that
eric
is
referring
to
fair
enough,
but
I
mean
yeah
I
mean
I'm,
I
mean,
given
that
this
is
only
called
by
infrastructure.
I
think
I'm
fine
with
that.
A
B
Yeah
yeah,
I
I
would
say
the
performance
is
important
to
you,
because
this
is,
I
mean
like
casting
cost.
Is
it
it's
okay
and
I'm
not
seeing
it
just?
I
want
to
take
some
time
also
to
talk
about
the
naming
of
of
the
propagators
that
we
are
we
are
providing
here.
I
mean
like
create
legacy
propagator
fast
through
projector
and.
F
A
Somewhere,
one
of
the
ones
I
saw
called
them,
trace
id
and
trace
state.
That
seems
like
it's
probably
better
names
to
help
indicate
what
id
and
what
state
really
mean.
H
E
A
B
A
B
A
A
B
Yeah
and
just
to
to
clarify
also
about
like
you
know,
I'm
expecting
in
the
future
I
mean
beyond.
We
are
going
to
have
more
extra
overload.
I
mean
more
overloads
for
inject
and
extract
for
some
other
scenarios
that
we,
for
example,
about
like
you
know
today
there
is
a
w3c
specs,
which
is
is
in
draft
mode.
B
E
B
No,
so
I
I
I
can't
expect
like
you
know,
extractor
can
can
help,
can
out
activity
context
and
activity.
Context
today
has
something
called
like
three
spear
id
spam
id
and.
A
Well,
right
now,
there's
nothing
that
your
contract
has
as
an
implementation.
That
would
allow
you
to
add
new
members
to
possibly
inefficiently,
but
still
function
acquire
whatever
the
trace
context
is
like
there's
there's
not
enough
generic
infrastructure
for
you
to
do
it,
so
you
can
add
a
new
virtual
that
just
throws
or
returns
null,
but
your
current
thing
is,
you
have
extract,
trace
id
and
trace
state,
and
then
you
have
extract
baggage.
B
E
Is
like,
if
you
eventually
have,
I
mean
there's
like
two
concerns
here.
One
of
them
is
what
jeremy
just
said.
My
other
concern
is
because
you
rely
on
overloading.
Basically
you
make
a
bet
that
they
always
differ
by
shape
if
they
all
have
the
same
shape,
and
it's
just
you
know
full
versus
bar
versus
something
else.
A
A
This
is
a
good
solution,
so
if,
if
you
ship
this
and
network
around
six,
then
in.net
7,
you
can't
add
new
abstract
methods,
because
then
someone
who
wrote
a
library
against
net
6,
they
will
get
a
missing
method,
some
sort
of
error
that
their
type
can't
be
instantiated
because
they
haven't
provided
a
implementation
of
an
abstract
member.
So
once
you
ship,
you
can
no
longer
add
new
abstracts.
You
can
add
virtuals
that
throw,
but
you
can't
add
new
abstracts.
E
Yes
and
the
problem,
if
you
do
that,
then
you
probably
want
some
way
to
determine
whether
this
will
work
or
not
right,
in
which
case
you
need
to
think
about
what
would
a
virtual
version
of
extract
look
like
that?
Does
nothing
right,
and
so
there's
basically
two
ways:
one
you
just
return
now,
the
other
one
is
you
return
a
bull
which
would
basically
mean
try
extract
right
with
an
out,
but
that's
basically
the
the
thing
I
think
to
me.
E
A
B
A
Yeah,
since
the
trace,
one
is
producing
two
things
returning
two
or
doing
two
outs,
it
seems
fine
because
if
it
gets
complicatedly
overloaded
in
future
versions
to
maybe
if
the
trace
context
would
come
out
of
the
same
or
an
overload
of
this
one,
then
this
is
better
than
a
tuple,
because
you
can't
overload
by
return
tag.
B
Okay,
next
about
the
create
methods,
so
the
first
one
which
is
will
create
the
legacy
propagator.
I
called
it
lexi,
I'm
not
sure.
If
this
is
the
best
name,
we
can
go
with
or
not,
but
but
mainly
about
like
you
know,
this
is
the
propagator
that
it
will
behave
like
what
we
are
behaving
today.
Initially
declined
and
he's
been
in
it.
E
B
E
E
B
E
That's
why
I
don't
understand
the
word
legacy
to
me,
like
what
you're
describing
sounds
like
what
we
normally
call
default
right,
because
it's
kind
of
the
you
know.
If
you
don't
do
anything,
that's
the
one
you
get
and
then
current
is
just
you
know,
defaulting
to
default
right
and
you
can
set
it
to
something
else.
Obviously,
but
then
the
default
one
is
still
the
default.
One
right.
H
E
B
B
H
B
H
E
Yeah,
like
first
of
all
that,
but
then
also.
Secondly,
like
I
mean
like
ignore
the
methods
right,
if
you
just,
if
you
just
create
a
console
app
and
you
ask
textpropergator.current,
it
has
to
return
something
right.
It
can't
right
now,
because
it's
not
nullable
and
so
presumably
in
in
that
world,
where
you
basically
say
everybody
uses
the
w3c
one.
Then
well,
probably
you
want
current
to
return
that
one
anyway
right,
in
which
case
you
already
made
a
breaking
change
anyway
and
which
case
what
stephen
suggested
seems
like
the
most
reasonable
thing.
Sorry,
stefan!
E
I
cannot
remember
this
right
because
I
mean
like
it
seems
like
it's
more
logical
to
say
you
know
you
make
a
breaking
change.
You
document
it
as
a
breaking
change,
because,
ideally
people
shouldn't
be
terribly
broken
by
that
it
should
just
get
that
better
right.
B
D
D
B
D
B
B
B
B
H
J
E
Okay
to
me
makes
perfect
sense
right.
So,
let's
say
let's
say
in
three
months
from
now:
the
the
these
new
is
ratified
right
and
then
we
say
for
net
seven
current
returns,
whatever
the
new
thing
is
right.
Well,
how
do
you
call
this
when
current
returns
this
new
thing?
That
is
your
default
right
so,
like
you,
are
effectively
changing
the
default.
E
All
we
are
saying
is
that
if
you,
if
that's
the
behavior
you
want
to
ship,
you
should
have
a
corresponding
method
that
creates
that
default
right,
and
so,
like
you
already
like
in
that
point
like.
If
your
current
points
to
the
new
thing,
that's
called
the
behavior
breaking
change
and
then
you
say:
okay
cool.
We
have
a
method.
We
always
have
a
method
called
create
default.
That
gives
you
whatever
current
is
initialized
to
and
then
because
we
made
a
breaking
change.
We
may
add
another
method
that
gives
you
back
whatever
the
previous
version.
B
Yeah
this
is
this
was
my
question
I
mean
I
said
that,
like
we
are
going
to
have
create
default.
Propagator
which
is
inducted
sex
will
return
what
we
call
it
legacy
and
whatever
the
name
of
the
program
yeah
the
behavior
of
the
propaganda
and
in
the
future,
get
default.
Propagator
is
going
to
return
w3c.
A
So,
while
you
could
say
you're
going
to
use
the
w3c
names
as
the
preferred
names
in
the
next
version,
I
think
you're,
looking
at
a
minimum
of
an
lts
and
a
half
before
you
remove
the
fallback
so
basically
you're,
never
removing
the
fallback
so
you're
not
actually
you're,
not
making
a
breaking
change,
except
that
I
guess
something
using
the
new
w3c
name
can't
be
read
by
an
old
system.
So
basically,
this
is
the
same
problem
that
all
networking
systems
have,
which
is
as
soon
as
you
ship
it.
A
A
But
the
yeah
so
you're
going
to
have
the
problem
of
you
know
inject
needs
to
do
something
in
a
compatible
way
and
extract
needs
to
do
something
in
a
compatible
way
and
because
this
is
network
boundary
you
you
have
the
trouble
that
people
can't
write
code,
that's
going
to
be
compatible
because
the
people
right
now
can't
write
code
that
can
understand
the
future
and
people
in
the
future.
Don't
know
that
they
need
to
understand
the
past.
A
So
you
need
everything
to
just
work.
So
good
luck.
A
A
E
But
to
me
that's
still
kind
of
an
implementation
detail
of
v.
Next
right,
like
I
think
pattern
wise
you
would.
You
could
still
support
that,
but
you
could
say:
okay,
it
doesn't
matter
the
create
default.
One
is
the
superset
thingy
that
understands
both
the
past
and
the
present
and
then
maybe
there's
an
optimized
one
that
is
called
create.
I
don't
know
optimize
w3
ce
whatever
the
name
is
and
that
one
only
understands
the
future
and
then
yeah
you
opt
into
that.
E
If
you,
if
you
really
want
better
perf,
let's
say,
there's
some
perf
penalty
by
supporting
both
past
and
present
right.
I
think
that's
but,
like
I
think
from
from
from
a
naming
standpoint
to
me,
it
makes
sense
to
say:
there's
a
create
default.
That's
the
thing
that
current
is
initialized
to
there's
other,
create
methods
that
give
you
different
propagators
and
you
can
always
create
your
own
and
assign
it
right.
E
E
D
B
H
D
K
D
E
I
mean
it's
just
easier
to
explain.
I
guess,
but
like
yeah
I
mean
that's
fair,
like
all
I'm
saying
is
that,
given
that
you
don't
return
ineligible,
there
is
a
default
right,
and
that's
just
all
I'm
saying
is
it
to
me.
It
feels
really
weird
if
the
documentation
says
initialize
to
create
legacy
propagator,
it's
like
in
nv5.
That
might
be
a
sensible
statement
to
make
but
like
in
v1,
it's
like
we
just
shipped
this
thing
like
we
initialize
it
to
legacy.
Behavior
yeah.
D
E
Right
yeah,
I
mean
yeah
to
me.
That's
like
the
only
other
word
that
I
can
think
of
is
default,
but
I
mean
you
can
also
just
have
create
propagator.
I
guess
right
but
like.
E
D
D
The
past
pass-through
and
no
output
yeah,
you
use
the
pass-through
if
you're,
using
a
service
mesh,
because
what
you,
your
service
mesh,
has
already
accepted
responsibility
for
distributed
tracing.
So
what
you
don't
want
to
do
is
create
child
activities
like
dapper
was
a
use
case
for
this,
like
they
were
complaining
that
their
users
had
orphaned
activities
for
the
no
output.
One
is
just
a
super
common
request
on
http
client.
Please
don't
send
headers
that
I
don't
want
you
to
send.
E
D
I
K
A
Turn
around
empty
from
fields
and
over
or
make
all
the
virtual
members
that
you
need
do
nothing.
E
E
D
D
E
Gives
me
that
control
yeah?
That's
basically,
my
question
like
do
you
like,
is
the
expectation
that
all
these
transports
are
offering
these
controls
or
is
the
expectation
that
text
mes
propagator
is
enlightened
for
some
ambient
kind
of
override
of
saying,
oh
disable,
that
or
like
you
know,
push
push
a
propagator
and
then
pop
one
or
something
that
effect,
because
right
now,
it's
also
process
wide
right.
Current
is
not
an
async
local
right.
D
I'm
not
speaking
for
everyone
here,
but
for
me
I
would
like
to
wait
and
see
what
people
would
needed
to
be
exposed
on
like
things
like
http
client,
for
I'm
not
yet
convinced.
We
need
it,
especially
because
like
if
you
want
to
do
something
crazy
now
you
have
the
carrier.
You
can
always
downcast
the
carrier
into
magic.
A
A
So
I
is
a
person
who's
using
http
client
can't
stop
it
from
calling
inject.
I,
as
a
person
using
a
library
that
uses
http
client,
definitely
can't
stall.
It
can't
stop
it
from
calling
inject,
even
though
I
don't
want
those
ids
to
be
sent
on
my
network
requests.
L
I
think
I
can
comment
a
bit
on
this,
so
first
of
all,
we
haven't
seen
any
requests
for
people
that
would
want
more
granular
control.
So
that's
why
we
didn't
decide
to
add
anything
in
e6
or
release.
We
can
always
come
back
to
and
add
something
on
http
client
or
a
custom
handler.
That
would
add
you
give
you
that
possibility
right,
but
if
even
if
we
see
one
or
two
requests
for
that
or
that
not
many
people
would
care
about
it
at
all.
I
A
As
long
as
the
library
doesn't
then
create
a
custom
propagator
which
again
would
go
back
to
the
if
you
tried
building
one
for
this
one
operation,
there's
no
way
to
get
it
into
the
http
client
library.
So.
E
E
A
E
E
A
B
A
We
added
propagator
setter
callback
right,
yeah,
which
I
went
with
the
obvious
name
for
we
renamed
the
outs
on
the
extract
that
produced
two
strings
when
we
gave
it
suffixes.
I
made
one
up.
If,
if
you
think
that's
wrong,
then
we
can
certainly
fix
it
here
and
then
extract
baggage
got
a
name
and
the
out
move
to
a
return.
H
E
A
Fair
enough,
I
was
going
like
I
don't
know
where
this
trace
context
was
supposed
to
live
in
a
future
version
and
what
kind
of
thing
it
would
be,
because
if
it
would
just
be
an
overload
of
trace
id,
then
we
do
that
if
we
say
trace
id
and
state,
we
can
move
the
outs
to
tuple
or
a
value
tuple
return.
I
don't
care.
E
H
D
E
H
H
E
Thanks
for
the
discussion-
and
I
wasn't
wrong
when
I
said
it
will
take
two
hours.
E
H
Maybe
but
I
don't
think
it
an
hour
and
a
half
but
yeah
I
mean
it
just
depends
so
we
didn't
get
to
the
config
stuff.
Can
we
do
an
overflow
or
something
we
have
40.
H
A
Propagator
got
marked
as
approved
yeah,
so
I
mean
the
thing
with
this.
Stefan
is.
I
have
no
idea
who
I
can't
think
of
a
better
way
to
say
who
would
care.
H
Like
so
eric
is
here,
but
I
mean
I
get
that
this
meeting
is
over.
I
could
invite
other
people
like
pablo
kremetz,
like
especially
if
you
have
an
overflow
session,
I'm
sure
he
would
be
interested
in
coming.
I
could
bring
in
some
people
from
the
asp.net
side
we're
already
shipping
this
since
preview
4..
This
is
we're
trying
to
get
it
moved
into
the
proper
assembly
and
name
space,
it's
being
shipped
as
part
of
some
asp.net
assemblies,
but
the
layering
is
kind
of
weird,
because
it's
a
config
api.
H
Yeah,
so
you
have
eye
configuration
and
configuration
root.
The
big
difference
is,
you
have
to
have
a
builder
today
that
you
call
build
on
that
returns.
An
eye
configuration
route
which
is
up
happens
to
be
our
public
configuration
route
type,
but
it's
immutable
and
for
the
new
asp.net
builder
called
web
application
builder,
we
have
you've
combined
kind
of
the
initialization
of
an
asp.net
host,
so
you
can
add
configuration
and
read
from
configuration
at
the
same
time
as
you're
like
setting
up
your
services
and
stuff.
H
So
instead
of
like
building
temporary
configuration
objects,
this
gives
you
a
live.
Look
at
your
configuration,
as
you
add,
and
remove
sources.
I
see
right
so
typically
people
don't
remove
sources
or
reorder
them
like
typically,
they
just
add
them,
and
it's
certainly
optimized
for
that
case,
but
yeah.
E
H
Oh
okay,
yeah
see
it
is
in
a
different
name
space
right
now.
The
alternative
proposal,
too,
is
to
update
configuration
builder
to
just
implement.
I
configuration
route
that
was
pavel's
idea,
which
I
thought
was
pretty
spicy
and
cool,
but
I
figured
it
might
be
harder
to
get
approved,
but
yeah
we
can
come
up
with
a
different
name
for
the
type
we
could
call
it.
I'm
open
to
suggestions.
A
Yeah,
I
mean
so,
to
my,
you
know:
who's
going
to
care,
it's
like
you're,
taking
a
thing
and
you're
making
it
sealed
instantiation
of
an
interface
okay.
So
I
I
don't
know
who
would
have
opposition
opinion
and
that
they
would
probably
be
a
good
person
to
have
in
the
next
meeting
whether
it
be
thursday
or
tuesday
yeah,
which.
A
H
E
I
think
that
to
me
the
honestly,
like,
I
think
the
scenario
makes
perfect
sense,
using
configuration
to
determine
what
other
things
to
load.
I
think
at
this
point
it's
just
naming
the
my
question
is:
which
namespace
did
you
currently
put
it
in.
H
Microsoft
extensions
configuration,
I
think,
is
definitely
the
right
name
space
for
it.
You
make
a
good
point
about
that,
not
being
a
legal
type
name,
so
I
will
have
to
come
up
with
something
better
yeah.
E
So
that's
the
problem
right
because
the
best
name
is
the
one
you
can't
use,
and
I
think
that's
probably
the
so
that's
maybe
why
I
think
pebble's
suggestion
is
not
horrible.
I
mean
I,
I
assume
that
you
know,
like
I
don't
know,
do
you
expect
us
to
be
an
advanced
center?
Do
you
expect
that
to
be
the
99
scenario
for
users
moving
forward.
H
I
expect
this
will
be
the
99
scenario.
People
really
like
this
new,
like
web
application
builder,
we're
trying
to
use
it
in
all
our
templates.
So
this
will
be
like
the
new
easy
way
to
you
know,
read
and
use
from
config
as
far
as
use
in
like
a
service,
you'll
still
take
in
like
an
eye
configuration
as
like
a
constructor
parameter
whatever,
but
this
concrete
type
wouldn't
be
like
registered
with
the
eye.
It
would
be
specifically
for
use
up
as
a
property
on
our
builder
yeah,
slash,
host.
A
E
H
So
I
configuration
root,
implements,
I
configuration
and
and
it's
what's
turn
returned
by.
I
configuration
builder
dot
build
and
it
adds
like
one
thing.
H
H
H
H
E
I
see
well
in
that
case
I
honestly
would
say
honestly.
Just
making
configuration
builder
implement
interface
seems
logical.
It's
a
bit
unfortunate
because
it's
not
the
best
name.
If
you
expect
that
everybody
writes
just
new
configuration
would
have
been
nicer,
but
you
use
the
singular
namespace,
contrary
to
our
recommendations.
So
that's
how
that
you
up
here
so.
H
So
I'll
submit
a
pr
that
updates
the
builder
and
start
some
discussion
there,
and
then
I
guess,
do
we
have
time
if
we
discuss
this
like
next
monday
to
get
this
in
preview.
Seven
like
that
would
be.
K
H
You
do
microsoft.asp.builder
right
now,
which
is
the
namespace
of
the
host
it's
a
property
on,
and
that
was
just
to.
I
see
to
get
it
charged.
We
test
it
out,
basically
yeah,
because
you
know
did
especially
because
this
was
the
first
in
preview
4
and
it
was
coming
in
hot,
so
like
trying
to
get
that
through
dependency
flow
and
stuff.
Was
it's
just
not
a
hassle?
We
wanted
to
deal
with
that
at
the
time.
E
H
E
Yeah
I
mean
I
mean
I
think
it
makes
sense.
I
think
we
all
have
context
now
like
we
can.
Maybe
just
do
it
over
email
now,
given
that
we
have
all
the
questions.
The
problem
with
email
reviews
is,
usually
we
don't
have
context,
and
so
the
first
10
emails
are
just
trying
to
establish
what
normally
takes
two
minutes
now
it
takes
like
four
days
like,
but
if
we
have
context,
if
it's
just
technical
decision
making,
I
think
that's
that's
easy
to
be
done
over
email.
E
So
if
it's
just
yeah
pick
a
name
pick
a
namespace,
I
think
it
should
be
in
configuration
extensions,
sorry
in
extensions
configuration
because
that's
where
all
the
rest
lives-
and
that
means
you
just
can't
use
the
name
configuration
I
mean-
I
mean
if
you
really
expect
it
to
be
the
number
one
thing
people
use
moving
forward.
Maybe
we
can
just
call
it
config
like
at
least
it's
a
different
name,
but
like
because
I
mean
it's
a
bit
weird
to
construct
a
builder
and
then
never
call
build
on
it
right.
H
Yeah,
because,
right
now,
because
it
does
implement-
I
configuration
builder
explicitly
so
that
is
the
difference
between
using
builder
and
not
is
in
this
scenario,
where
we
have
the
configuration
type
that
was
an
expanding
builder.
Most
of
the
builder
members
were
explicitly
implemented
because
you
end
up
adding
sources
with
extension
methods
anyway,
so
like
for
intel
sense.
It
is
nicer
just
to
like
focus
on
reading
the
config
and
the
extension
methods.
Yeah.
L
H
Builder
could
be
more
that,
like
there'd,
be
basically
more
stuff
in
intellisense,
but
I
think
that's
fine,
yeah
and
bill
just
returns
this
right,
since
it's
automatically
like
you
know,
updating
all
the
time,
but.
E
E
That's
fair
yeah
like
this,
but
that's
kind
of
why
I
was
saying
like
if
you
expect
that
you
know
moving
forward.
That's
what
you
would
expect
sample
code
to
do
it.
It
would
be
worthwhile
optimizing
for
that
right
and
make
it
not
like
this
thing
that
is
bolted
onto
the
side
which,
if
you
use
the
builder
one
it
kind
of,
is
like
that
it
might
not
be
the
worst.
But
that's
why
I
said
like.
Maybe
you
want
to
call
it
config
and
then
just
have
it.
E
E
I
mean
my
opinion
is,
if
you
think
this
is
a
an
optimization
to
avoid
intermediary
builders
that
is
used
by
a
few
parts
in
the
system.
Then
I
think
doing
it
on
the
builder
seems
fine.
If
you
expect
sample
code
like
especially
like
the
way
you
have
written
here.
So
it
looks
like
this.
Like
you
know,
super
lean.
Everything
is
in
one
file
kind
of
sample
code
that
you
want
to
to
give
people
moving
forward.
Then
I
think
optimizing
for
a
shorter
name
and
and
something
that
looks
a
bit
cleaner
might
make
more
sense.
H
I'll
say
that
the
way
we're
using
it
right
now
most
people
probably
won't
see
the
type
name,
because
it's
going
to
be
used
on
a
property.
Unlike
the
builder
and
the
web
application.
Now
you
can
use
it
directly
and
we
think
that
should
be
possible
and
that's
what
I
demonstrate
you
can
use
it
without
hosting,
but
I
think
that
would
be
less
common.
E
H
Okay,
but
it
was
designed,
it
was
part
of
like
this
new
web
application
builder.
It
was
originally
feather
if
you've
heard
of
that,
but
it's
just
the
simplified
host.
A
Yeah,
I
mean
so
for
me
if
it
can
be
added
to
the
configuration
builder
class
that
you
already
have
in
a
way
that
works,
keeping
in
mind
that
the
I
guess
I
don't
nothing
on
it
is
it's
unsealed,
but
nothing's
virtual,
so
it
should
be
able
to
be
written
sensibly.
So
as
long
as
you
can
add
the
new
functionality
on
the
existing
type,
that's
probably
better.
H
The
one
thing
is
the
builder
isn't
currently
disposable.
H
To
dispose
the
providers
that
are
like
reading
like
that,
have
like
jason
change,
notifications
and
things
like
that.
Yeah.
H
A
A
A
H
A
B
H
H
A
Config
is
what
emo
proposed
before
he
left
so
yeah
I'll.
Let
you
know
you,
you
config
guys
work
that
out
on
email,
emo's,
the
one
who's
in
charge
of
when
we
have
more
sessions,
and
he
left.
So
I
don't
know
if,
if
we're
having
a
thursday
session
to
get
rid
of
the
last
blockers
or
or
not
so,
email.
A
A
Which
is,
I
think,
our
usual
response,
so
all
right,
we
have
definitely.