►
From YouTube: 2020-09-08 .NET SIG
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
B
C
A
Okay,
I
think
we
can
start.
Interestingly,
we
don't
have
anything
agenda,
but
we
can
give
some
updates
and
probably
discuss
about
the
next
release
plans
as
well.
So
folks,
on
the
call,
please
make
sure
you
write
your
name
in
that
in
the
list
start
with
mine.
A
Yeah
before
we
go
into
the
release
plan,
is
there
any
topic
folks
wanted
to
discuss?
I
know
there
is
nothing
in
the
agenda,
but
just
asking
in
general
is
there
anything
which
we
want
discussed.
D
Hey
cj:
this
is
an
annual
from
where
yeah
I've
been
kind
of
out
of
the
loop
for
a
bit
because
my
focus
got
taken
elsewhere,
but
I
know
you
guys
are
releasing
or
you've
released
the
beta
with
the
preview
dependency
on
it,
five
diagnostics.
D
Now
does
that
mean
when
you
are
ga
it's
very
likely
that
you
require
open
telemetry
to
have.net
5,
or
can
it
work
with
3.1
lts
as
well?
I'm
not
too
sure
I
hope,
yeah.
A
I
mean
it
works
with
all
documents.
Instead,
you
need
to
use
the
diagnostic
source
5.0
version,
that's
the
only
requirement
and
that
that
dependency
will
be
brought
automatically
by
open
elementary
sdk
and
apa,
so
it
can
still
like
it.
Just
works
fine
with
any
dotnet
versions.
Even
today,
like
you,
can
take
it
to
2.1
or
3.1
app
instagram.
D
A
A
I
think
this
is
a
question
which
we
try
to
clarify
in
the
docs,
but
I
have
to
check
like
whether
it
is
like
really
visible
at
the
top
or
like
hidden
somewhere
down
like
deeper
into
one
of
the
topics.
E
E
I
I
think
I
had
the
question
initially
like
whether
we
should
clarify
which
version
we
support
in
the
home
page,
and
it
seems
like
the
general
approach
in
dotnet
is
to
refer
to
the
new
guide
version.
I
wonder
like
even
so
many
people
ask
the
same
question.
Should
we
put
something
just
before
getting
started
so
see
you
would
you?
Would
you
go
to
the
home
page?
Just
look
at
the
home
page
readme
file
yeah
this
one
yeah.
A
Yeah
that
would
make
sense.
I
think
this
is
the
same
thing
like
similar
comment
for
the
activity
topic
as
well.
We
briefly
discussed
it
in
one
of
the
segments.
A
We
should
write
the
fact
that
upon
elementary.net
is
built
on
top
of
activity
class
as
the
like
span
equivalent
and
the
same
thing,
which
we
just
did
the
version
support.
These
two
are
like
top
asked
questions
like
why,
so
probably
it
makes
sense
to
like
document
it
like
really
prominent
right
here,
yeah
just
before
getting
started,
and
then
like
detailed
documents,
can
give
more
insights
into
like
specifics.
E
A
So
my
take
is:
we
need
to
definitely
mention
that
activity
dot,
net
activity
represents
the
span,
the
open
elementary
span.
That
would
be.
That
could
be
like
a
one
sentence.
Thing
like
open,
telemetry
span
is
presented
in
dot
net
client
by
using
the
activity
class,
which
is
shipped
as
part
of
dotnetbc
or
dotnet
diagnostic
source
package,
and
then,
following
that,
the
next
statement
should
be.
This
library
supports
all
the
dotnet
versions,
officially
supported
by
microsoft
and
having
hyperlinks
directly
leading
to
microsoft's
support
page
for.
F
E
Activity
is
only
part
of
the
tracing
api
and
there
there
could
be
like
logging,
api
and
metrics
api.
I
don't
see
a
like
anything
special
about
like
why
do
we
want
to
make
tracing
a
like?
A
high
party
here,
like
sim
state,
has
actual
privilege,
so
I'm
not
convinced.
I
okay,
like
the
overall,
like
when
people
look
at
open
times
for
this
repo.
We
got
to
tell
them
like
either.
You
should
stay
here
or
just
go
away
by
telling
them,
which
version
we
support
and
anything
related
tracing
metrics.
E
A
So
feedback
from
the
others
yeah
yeah,
let's
see
if
there
are,
I
think
I
agree
like
we
can
like
since
the
activity
part,
is
specific
to
tracing.
We
can
put
that
under
like
somewhere
in
the
trace.
It
takes
trace
section,
maybe
in
the
getting
started,
but
version
if
or
agrees.
I
can
submit
apr
which
talks
about
version
support
here.
But
let's
see
if
the
thoughts
on
this.
E
Yeah
or
like
I
don't
know,
what's
the
general
feeling
like
like
when,
like
other
folks
look
at
this
republic,
do
we
think
it
would
be
great
to
mention
the
philosophy
of
open
telemetry.net?
Is
the
instrumentation
layer
should
be
covered
by
doughnut
as
much
as
possible?
It
is
something
we
want
to
mention,
or
it's
just
like
too
detailed.
A
I
really
think
we
should
mention
it,
but
I
don't
really
know
what
is
which
is
the
right
place
for
that
the
auto
instrumentation
repo
they
put
something
like
a
vision
document
and
have
the
readme
link
to
the
vision.
So
there
will
be
a
section
say
this
is
our
philosophy,
slash
long
term
vision
and
link
it
to
a
detailed
document
describing
what
that
is
that
something
which
we
should
consider
doing.
E
A
And
one
more
thought
on
this
version
part
the
reason
why
there
is
a
confusion
about
like,
like
riley,
mentioned,
most
dot
net
reports.
They
don't
really
explicitly
mention
the
version
here.
It
is
handled
in
the
new
video
itself,
but
the
reason
why
we
need
that
version
clarification
is
purely
because
folks
would
who
takes
a
look
at
the
repo.
They
see
that
we
are,
depending
on
a
preview
version
of
dot
net
5,
which
leads
to
the
which
confuses
people.
Okay,
are
we
now
supporting
only.net,
five
or
so?
A
So
that's
one
of
my
motivation
to
club
them
together
here,
but
then
it
it
may
be
possible
that
I
mean
it's
also
a
alternate
option:
let's
completely
ignore
about
versioning
here,
just
keep
it
liked
it.
A
So
there
is
no
requirement
on
any
version,
so
people
would
just
follow
whatever
they
follow
for
any
other
dotnet
library,
they'll,
just
look
at
new
gate
and
figure
out
which
libraries
are
supported,
and
then,
when
going
into
the
docs
for
tracers,
that's
where
we
specifically
say
we
depend
on
activity
which
is
diagnostic
source
and
then
make
it
explicit
that
this
is
supported
in
or
dot
net
version,
but
I
don't
have
preference
either
way.
It's
it's
just
a
special
thing
that
diagnostic
source
activity
is
released
along
with
network
there
is.
A
E
Yeah
and
and
related
to
version,
I
want
to
get
some
idea
like,
like
there'll,
be
a
scenario
where
people
use
this
sdk
for
like
client
story
like
mobile
device.
They
want
to
use
like
donut
micro
framework,
or
they
want
to
use
that
with
like
xamarin
or
like
some
of
the
3d
engines
and
like
currently.
The
message
from
this
report
is
not
very
clear.
Like
are
we
targeting
those
platforms
at
all
or
not.
E
Yeah,
I
I
think
open
telemetry
java
has
a
has
that
clarity,
so
it
has
the
part
that
works
for
android
and
I
think
probably
we
need
to
clarify
at
least
from
our
like
understanding.
We
need
to
know
whether
this
is
something
we
will
support,
or
we
should
support
or
something
low
priority
or
something
we.
We
would
never
do.
A
Okay,
if
that
is
the
case,
then
at
least
we
should
say
I
mean
we
should
at
least
state
that
we
either
support
it
or
we
don't
support
it
so
that
there
is
no
confusion.
Then
we
can
discuss
whether
we
want
to
support
it
in
the
future.
Yeah
yeah,
that's
something
which
I
can
submit
apr
and
then
we
can
get
some
comments
on
that
from
the
pr
itself.
G
Hey
guys,
sorry,
sorry
to
interrupt
on
that
client
thing.
We
would
be
interested
to
know
we
don't
have
a
mobile
client,
but
we
were
on
oldish
winforms
app
with
a
thick
client.
So
we
would
be
interested
to
know
like
how
well
or
like
what
what
are
the
best
practices
for
that.
Specifically,
if
I
want
to
send
traces
from
my
winforms
client,
am
I
running
the
collector
service
somewhere
in
my
data
center?
A
Okay
yeah,
so
let's
get
started
with
what
is
the
thing
which
works?
Yeah,
probably
that's
the
first
step,
and
then
we
can
take
the
next
step
and
say
if
you
are
in
a
client
device.
These
are
the
guidelines,
slash
recommendations.
We
have,
if
you
don't
have
anything
we'll
just
state
so
but
yeah
agree.
We
can
probably
like
win.
Forms
is
something
which
we
have
seen
in.
A
Like
assured
application
sites
experience,
people
who
are
asking
does
it
work
in
like
like
desktop
windows,
desktop
applications,
so
there
is
nothing
bending
one
from
using
it
right
now
like
even
today,
if
you
just
install
the
api
or
sdk
use
it
in
any
dot
net
application,
it
should
just
work.
It's
yes.
It.
G
Does
work,
but
I
guess
it
would
be
interesting
to
see
what
are
the
recommendations
around
if,
if
your
clients
are,
I
guess
over,
the
internet
is
the
idea
that
the
preferred
way
to
have
them
all
directly
sent
from
client
to
the
collector,
or
should
I
have
my
own
service
proxy,
the
collector
or
things
like
that.
A
Not
yet
sure
whether
we
like
this
report
should
provide
best
practices
on
those,
because
it
I
mean
it's
not
specific
to
dotnet
anyway,
like
it's
the
same
for
every
our
stroke
right,
it's
same
for
like
everything
like,
even
if
you're
a
javascript
customer
like
you,
have
a
javascript
running
in
your
browser.
So
we
should
not
document
or
provide
best
practice
about
how
how
that
telemetry
should
flow
to
your
final.
A
Okay,
but
at
least
the
basic
thing
is
here,
we
should
clearly
feel
like
whether
we
at
least
work
in
client
side
and
then
put
a
placeholder
and
see
if
we
have
more
interest
in
the
topic
and
based
on
that,
we
can
write
some
best
practices,
not
necessarily
about
where
to
run
the
collector
or
directly
sent
from
the
client
side
app
to
the
back
end
of
your
choice,
or
probably
other
things
like
what
is
the
best
practice
on
like
disposing,
because
in
server
it's
fairly
clear,
you
start
open
telemetry
in
app
startup
and
you
dispose
the
provider
at
the
end
of
your
application.
A
That
life
cycle
is
more
clear,
but
in
case
of
client
side,
it's
not
clear
and
what
are
the
implication
if
you
don't
dispose
your
provider,
so
those
are
the
things
I
think
we
could
get
started
with
about
client
side.
If
you
want
to
document
that,
but
then
I
try
it
on
like
based
on
interest
from
other
folks,
we
can
try
to
iterate
that
and
make
a
separate
section
for
client
cell.
A
Instrumentation,
okay
yeah,
like
does
it
cover
like
everything
which
we
wanted
to
cover
about,
the
questioning
and
the
overall
readme
dog.
A
Change,
I
think
yes,
okay,
let's
move
on
to
the
next
one,
so
I
think
we
got
an
update
last
week
that
we
released
the
second
beta
last
week
and
the
next
beta,
which
would
be
beta
3,
was
origin.
A
I
think
I
put
this
as
september
30
just
to
give
us
like
one
month
of
working,
but
there
was
a
request
last
during
the
last
weeks
to
make
it
happen
even
before
I
think
sega
put
the
request
so
that,
like
the
some
of
the
metric,
changes
can
be
violated
by
some
customers
earlier,
and
I
think
we
should
be
able
to
do
that.
The
only
requirement
is
like
rc1
package
for
diagnostics
should
be
available,
which
is
expected
around
15th
or
16th
of
september.
A
A
But
it's
like,
I
don't
really
have
any
like
naming
opinions
or
anything.
There
is
nothing
preventing
us
from
releasing
as
long
as
the
dependent
packages
are
already
in
the
nuget.
A
So
so
far,
I'm
only
hearing
sergey
mentioned
their
request
last
week
that
we
want
to
do
a
release
earlier,
but
that
I
said
we'll
just
stick
with
this
schedule.
A
I
I'd
like
to
spend
some
time
on
metrics
real
quick,
because
we
like,
if
you
look
at
the
things
which
we
planned
for
which
are
applying
for
the
next
beta
metrics,
are
not
there.
We
already
know
these
are
the
things
which
we
are
committing
for
the
next
release.
A
Metrics
are
still
not
there,
so,
which
means
the
earliest
when
we
would
have
some
matrix
is
like
towards
beta4.
Are
there
any
concerns
with
this
approach,
or
the
primary
reason
is
matrix?
Text
would
be
like
will
not
be
like
fully
ready
until
after
the
tracing
spec
is
ready,
and
there
is
some
commitment
from
the
specification
committee
that
tracing
would
take
priority
and
that
should
happen
around
this
month.
A
A
Yeah,
I
don't
hear
objection,
so
I
think
that
should
be
fine.
So
really
do
you
want
to
like
discuss
on
the
possibility
of
like
considering
that
when
we
release
the
actual
ga
release,
do
we
intend
to
call
matrix
as
ga
or
do
we
intend
to
call
the
matrix
for
like
tracing
and
login
sda
and
or
tracing
as
ga
and
matrix
us
like
something
else?
E
So
we
need
to
observe
what's
the
progress
on
the
back
side.
Currently,
I'm
not
optimistic,
and
I
think
that's
the
general
understanding
from
other
community
folks,
so
the
the
idea
is
if
at
november
we
know
that
the
tracing
part
is
stable,
we're
going
to
ga
the
sdk
but
matrix
part
we're
not
yet
confident.
We
need
to
make
a
special
note.
We're
saying
this
sdk
is
ga
and
the
matrix
part
is
is
not
like
locked
down
yet.
A
Okay,
that
makes
sense,
so
some
of
the
folks
were
earlier
asking
about
metrics,
specifically
so
like
they
think
ellen.
You
probably
asked-
and
hannah
lee
also
asked
about
this,
so
the
current
state,
we
don't
have
any
change
in
the
last
two
or
three
months
on
matrix
and
we'll
be
just
following
the
spec
change.
A
So
if
specs
become
stable
in
time
four
and-
and
we
also
have
like
some
cycles
to
finish
the
work
before
the
g8,
we'll
call
it
matrix
as
a
ga
version,
otherwise
we'll
call
it
matrix
and
non-gi
quality
like
preview
or
beta.
E
Yeah
and
my
definition
of
ga
versus
not
ga
is
the
confidence
of
whether
we'll
have
breaking
changes
and
for
metrics.
I
think,
given
it's
already
september
and
we're
going
to
release
on
november
and
the
matrix
spec
is
still
having
a
lot
of
issues
and
there
will
be
several
breaking
changes
and
yet
we
don't
see
where's
the
end
of
the
matrix
api.
So
I
think
it's
unlikely
that
we
can
lock
down
the
metrics
api
at
the
ga
bar
okay,
make
sense,
yeah.
D
Is
fine,
it
just
communicates
that
it
may
be
breaking
changes
in
the
api,
but
is
it
usable
like
so
does
it
work?
You
know
when
we
have
the
samples
hooked
up
together
and
exported
prometheus,
and
when
I
I
kind
of
looked
at
it
and
gave
made
some
changes
to
the
prometheus
exporter,
we
kind
of
integrated
with
the
prometheus
system
and
make
sure
the
metrics
are
coming
out
right,
but
there
seemed
to
be
some
kind
of
bugs
in
it,
and
I
don't
know
so.
D
A
Yeah
my
take
is,
it
would
be
like
more
better
if
you
wait
for
the
specs
to
be
more
stable
to
avoid
rework,
but
it
doesn't
prevent
anyone
from
submitting
pull
requests
to
make
the
apa
better
like
or
the
current
implementation
better.
We
got
like
several
tiers,
like
in
last
few
months,
like
addressing
it
a
little
bit
little
bit,
but
my
when,
when
I
said
like
I'm,
not
trying
to
put
it
in
the
next
video,
but
I
was
mostly
referring
to.
A
A
I
mean
if
you
look
at
those
x4
matrix.
The
sdk
spec
has
made
some
progress
in
the
last
few
weeks,
but
it's
it's
still
like
you
can
see.
It's
totally
debated
like
what
should
what
should
be
the
spec,
so
it
it
is
supposed
like
if
there
are
folks
who
are
interested
in
making
it
happen,
it's
not
going
to
prevent
us
from
making
that
change,
but
just
be
aware
that
it's
likely
be
throwaway
work
once
the
actual
spec
arrives.
A
Is
already
there
in
java
sdk,
because
java
already
implemented
the
matrix
almost
end
to
end,
including
all
the
exporters,
but
now
that
the
spec
is
officially
coming,
it's
not
looking
similar
to
what
java
already
has
or
it's
looking
more
closely
to
what
go
already
has.
So
there
are
some
decisions
found
like
what
should
the
metric
sdk
spec
even
contain
so
because
of
that,
it
probably
makes
sense
for
us
to
give
it
a
little
more
time
to
avoid
the
same
tension
as
java
folks
have
now.
A
Yeah,
but
if
there
are
like
interest
in
making
like
like
we
don't,
for
instance,
we
don't
have
a
accumulator
which
can
do
percentiles
or
histogram.
If
there
is
anyone
who
has
the
cycles
to
do
that.
Yes,
we
can
definitely
take
it,
and
that
would
give
like
the
early
adopters
some
taste
of
how
the
sdk
is
going
to
look
like,
but
just
be
fully
aware
that
we
might
just
throw
it
away
after
some
time.
But
it's
quite
I
mean
we
are
not
going
to
refuse
any
pr
which
adds
like
any
changes
to
matrix
forma.
D
Okay,
yeah,
I
might
make
a
small
one.
I
and
I
don't.
I
haven't,
looked
at
the
repo
at
all
and
see
if
there's
integrations
with
other
systems
like
you
know,
wavefront
from
vmware.
You
know
there
might
be
a
small
fix
to
fix
some
of
the
things,
and
I
don't
know
if
I
have
time
to
make
net
new
things
like
new
accumulator
or
something
but
a
small
fix.
We
can
make
it
happy
to
take
that
yeah.
F
C
I
I've
taken
a
look
a
little
bit
at
the
at
the
go
sdk
because
I
know
josh
is
kind
of
one
of
the
points
on
the
metric
sdk
spec.
And
do
you
so
first
question?
Do
you
think
that
there's
any
value
in
studying
that
and
maybe
coming
up
with
kind
of
a
high
level
plan
for
what
our
work
would
look
like
on
the
dotnet
sdk
and
then
second
question
is,
as
we
approached
net
six.
A
So
so
riley
do
you
have
anything
to
add
about
the
dot
net
side,
where
dot
net
is
planning
to
expose
a
matrix
api
which
which
enables
open
telemetry
scenarios
yeah
similar
to
activity?
Can
you
share,
like
your
updates
on
that.
E
Yeah,
so
so
the
metrics
api
will
be
added
in
dotnet
six
and
normally
the
the
actual
prototype
work
will
happen
on
like
january
february
next
year
and
the
initial
brainstorming.
Some
of
the
design
discussion
would
happen
right
now
till
the
end
of
this
year.
So
I'm
I'm
like
following
up
with
donald
fox,
to
get
the
initial
like
brainstorm
on
the
metrics
api.
A
And
as
soon
as
we
have
something
we'll
do
the
prn.net
design
repo
just
like
we
did
for
activity,
so
all
the
changes
should
be
like
publicly
missing.
Whatever
is
happening
in
dot
net
metric
side
should
be
publicly
visible.
Just
like
everything
else,
so
I
mean
we
don't
have
anything
solid.
Yet
is
what
really
is
saying
yeah,
okay,
so
alan?
Does
that
answer
your
question.
A
The
go
part
yeah,
I'm
not
yet
sure
whether
the
spec
is
going
to
strictly
photo
go
as
or
it
could
follow
like
java,
because
java
has
slightly
different
thing
or
it
could
follow
something
neutral.
So,
okay,
it's
not
clear
to
me.
What's
going
to
be
the
final
spec
for
sdk
like
there
are
questions
about,
should
it
actually
even
describe
the
names
of
the
components?
Also
just
say
these
are
the
things
every
sdk
should
implement.
You
can
call
it
whatever
you
want,
so
there
are
different
thoughts
on
that.
A
So
until
that
is
figured
out,
I
don't
know
whether
it
is
a
good
use
of
time
to
follow
the
go
approach,
because
in
the
end,
if
go
approach
is
not
what
end
up
being
in
the
spec,
then
we'll
be
just
throwing
away
whatever
what
we
have
done.
So
it's
a
same
answer
as
I
gave
a
little
bit
earlier
it
we
can
still
make
it
work,
but
then
be
aware
that
we
would
be
like
throwing
away
some
of
the
work
which
we
have
done.
C
Yeah
sure
that's
fair
yeah,
one
last
question
about
the
dot
outside.
Do
we
anticipate
that
there
may
be
a
similar
thing
that
occurred
with
traces
where
we
implement
the
sdk?
You
know
once
the
spec
lands
and
then,
as
we
approach.net
six,
that
we
ultimately
morph
that
into
like
a
more
of
a
shim
type
of
thing
like
we
did
with
the
yeah.
A
Probably
I'm
not
yet
sure
of
the
timings,
because
if
we
get
like
something
from
dotnet
or
like
early
jan-
and
we
want
to
do
something
for
metrics
before
that,
then
we'll
have
to
follow
the
same
strategy
as
tracing.
A
A
But
I
think
in
the
next
couple
of
months
we'll
have
more
clarity
on
like
the
timelines,
and
then
we
can
discuss.
Should
we
start
from
the
scratch
with
the
matrix
api
which
dot
net
is
going
to
expose,
or
should
we
start
from
whatever
open
elementary
specs
will
have
at
the
end
of
the
year
and
then
reor?
A
Rework
it
on
top
of
the
dotnet
six
metric
api,
okay
yeah,
that
all
makes
sense
yeah
and
it's
very
good
opportunity
right
now
for
anyone
to
like
take
part
in
their
discussions
like
in
talking
at
runtime
like
as
soon
as
we
kick
off
that
discussion.
A
A
Okay,
yeah,
I
don't
have
any
other
updates
and
there
was
nothing
in
the
agenda
as
well.
So
I'll
like
update
the
meeting
notes
with
what
we
discussed
today.
Is
there
anything
else
we
want
to
discuss?
If
not,
I
would
like
to
ask
if
there
is
any
new
member,
please
use
this
opportunity
to
say
hi.
G
Well,
hey
hi!
I
I
have
a
general
question
if
you
guys
don't
mind
so
we
we're,
like,
I
said,
a
winforms
client
and
we
use
that
net
remoting
to
talk
to
to
our
app
server,
don't
judge,
but
that
is
what
it
is.
I
wrote
kind
of
an
instrumentation
for
that
net,
remoting
just
to
try
it
out.
Okay
and
it
seemed
it
seemed
like
it
worked.
There
might
be
a
better
way.
I'm
just
gonna
still
need
to
clean
it
up.
G
I
try
to
follow
how
the
the
http
client
instrumentation
was
done,
and
I
couldn't
fully
understand
exactly
how
it
hooks
up
into
the
frameworks
kind
of
events
that
are
around
system.http.
Is
there
just
a
place
where
to
read
more
about
it?.
A
I
don't
think
there
is
any
doc
specific
to
that,
but
like
when
you
said
you
modeled
the
http
client
approach,
the
http
client
for
dotnet
framework
and
dotnet
core.
They
are
completely
like
different,
so
in
case
of
dotnet
framework,
there
is
no
built-in
instrumentation,
so
we
kind
of
like
use
some
reflection
hack
into
the
dotnet
framework
code
to
make
that
happen
in
case
of
dotnet
core.
A
The
http
client
has
a
built-in
handler
which
emits
diagnostic
source
events,
so
our
instrumentation
is
more
about
just
subscribe
to
those
diagnostic
source
events
and
convert
them
into
open,
telemetry
or
activity
which
we
want,
but,
depending
on
like
the
instrumentation
you
use
for
the
dotnet
remoting,
you
could
use
one
of
the
approach
either
user.net
frameworks
approach.
If
it
has
no
instrumentation
at
all,
or
if
it
has
some
diagnostic
source
events,
then
we
can
use
the
approach
which
is
used
for
net
core.
There
are
no
dogs.
The
best
bet
is
to
look
at
the
instrumentation.
A
A
C
C
A
G
Yeah
that
would
be
it'll
be
super
useful.
We
we
are,
we
specifically
are
in
a
net
framework
land,
so
I
was
looking
at
that
reflection
things,
but
I
wasn't
really
sure
like
there
would
be
no
way
to
really
write
this
without
knowing
the
kind
of
internals
of
the
framework
code
itself
and
kind
of
looking
it
up
and
what
it
does
right.
A
Be
correct
right
I
mean
so
michael
is
already
here.
Do
you
have
any
more
insights
on
like
how
do
we
did
the
dotnet
framework
hack
for
http
client.
F
F
It
is
public,
there's
reference
source
available,
there's
like
the
dedicated
reference
source
and
then
there's
also
a
github
that
has
it
so.
It
literally
was
a
task
of
just
reading
every
line
of
that
code
and
trying
to
find
places
where
we
could
like
monkey
patch
with
reflection
at
the
right
time
so
like
when
a
request
is
starting
or
a
request,
is
ending.
F
There
is
an
existing
version
that
I
started
from:
that's
actually
part
of
system.diagnostic,
but
it
was
hooking
in
like
the
connection
point
manager,
which
was
a
little
problematic
because
there's
some
stuff
that
happens
after
that,
like
requests,
can
be
resubmitted
or
exceptions
can
throw.
So
I
kind
of
figured
out
that
there's
some
async,
like
the
old
style,
iasync
stuff.
F
I
hook
into
that
because
it
was
like
the
perfect
last
spot
in
the
execution
chain
where
things
are
firing
and
you
have
the
final
response
that
was
really
just
lucky
like
it
just
happened
to
be
there
and
it
worked
out,
but
it
was
like
weeks
of
like
just
trying
things
and
reading
the
code.
I
don't
know
about
remoting
if
it's
even
available,
I
don't
know
if
that's
a
technology
that
microsoft
retroactively,
open
source
we'd
have
to
kind
of
figure
that
out
and
look
at
it
and
see.
If
there's
there's
some
spot,
we
can
hook
into.
G
The
they
they
do
have
like
a
concept
of
these
sinks
that
do
things
in
chain
and,
like
I
managed
to
do
it
through
that
by
like
inserting
a
custom
sync
that
does
telemetry
into
that,
but
I'm
not
sure
if
there
was
if
there
was
a
better
way,
if
like
it,
does
emit
any
diagnostics,
maybe
internally
you
could
do
reflection
on.
I
was
just
wondering
how
that
was
done
on
the
on
the
web
client
to
kind
of
try
to
do
it.
The
same
way.
F
A
I
think
the
doubt
the
to
be
written
doc
for
instrumentation,
like
writing
on
instrumentation
library.
It
will
just
talk
about
like
how
to
I
mean
it
won't
definitely
talk
about
like
like
hacking
into
an
existing
library,
just
say
like
best
practices.
This
is
how
we
would
emit
an
activity,
or
this
is
how
we
would
start
an
activity,
and
this
is
how
you
make
sure
the
activity
is
stumbled
in
before
you
spend
too
much
time
in
reaching
it.
A
So
those
kind
of
things
are
what
will
happen
in
this
place
based
on,
I
think,
the
to
be
merged
pr
from
line,
but
anything
other
than
that
yeah.
I
mean,
let's
just
like
chat,
offline
and
figure
out
what
is
the
best
place
to
hook
it
hook
it
into,
but
for
any
general
library
for
which
you
want
to
write
an
instrumentation
here,
there
would
be
a
dog
and
you
should
be
able
to
borrow
best
practices
from
that
like,
for
instance
like
when,
do
you
start
the
activity?
A
When
do
you
stop
it,
and
when
do
you
set
a
display,
name
or
extra
property,
so
those
things
would
cover
from
the
official
door,
everything
else
yeah.
It's
on
a
case
case
basis,
you'll
have
to
figure
out
and
yeah.
You
can
just
leverage
some
of
the
resources
we
have
here,
but
yeah.
That's
pretty
much
it
thank
you
and
did
you
intend
to
like
submit
it
as
part
of
the
community
or
the
contribution
report?
A
A
Maybe
like
you
can
start
with
a
draft
pier
in
the
community
repo,
so
people
can
actually
look
at
it
while
they
are
developing
and
like
pick
out
any
like
issues
much
earlier
than
waiting
for
everything
to
work
all
the
way.
Okay,
all
right
cool.
I
will
do
that.
Thank
you.
Yeah
michael,
is
like
an
expert
for
this
place,
so
I
would
use
his
expertise
to
like
develop
anything
like
that,
because
he
has
done
it
for
http
client
and
if
there
are,
I
mean
if
there
are
no
hooks,
we
can
follow
the
http
client
approach.
A
But
if
there
are
some
place
to
put
things,
then
we
can
it's
much
more
easier,
but
either
way
we
can
discuss
it
in
a
draft
year
if
it's
not
fully
ready
cool.
We'll
do.
Thank
you,
I
think.
Like
last
week
there
was
some
discussion
before
and
you
know
I
still
have
to
read
the
notes,
but
it
looks
like
we
decided
to
keep
the
repo
and
the
ca
and
cd
is
already
ready,
so
you
should
be
able
to
submit
put
request
and
it
should
kick
off
all
the
cis.
A
Yep
all
right,
so
I
don't
have
any
other
topics.
If
no
other
things
we
can
end
early.
B
A
Yeah,
you
just
happened
all
right:
okay,
thank
you,
but
yeah.
Once
once
we
like
make
it
like
more
formal.
I
think
we
can
put
a
link
from
the
main
report
here
as
well,
we'll
see
what
other
languages
are
doing
and
then
we
can
follow
something.