►
From YouTube: 2022-01-25 meeting
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).
B
Hello,
can
you
hear
me
yep,
I
I
I
didn't
hear
the
question
I
joined
the
meeting
and
it
put
like
put
the
audio
in
a
different
speaker.
B
B
A
A
Okay,
I
will
share
my
screen.
C
A
A
A
If
there
are
like
any
other
topics
which
are
not
covered
here,
maybe
you
can
add
them
now.
A
So,
let's
start
with
the
first
item
in
the
agenda,
so
this
is
something
which
christian
traced.
Like
a
couple
of
weeks
back,
I
bought
the
c-sharp
language
version
which
the
entire
repo
is
using,
which
is
now
10.
It
was
previously
like
9,
but
we
are
now
in
the
10,
but
from
the
official
documentation
we
should
be
like
picking
the
version
which
matches
the
target
framework
we
are
targeting.
And
since
you
are
targeting
next
standard
and
at
461
we
should
ideally
be
only
using
7.3
and
not
the
latest.
A
So
that
was
a
topic
and
I
had
a
chance
to
like
ask
the
team
about
this
one
in
a
slightly
different
context,
but
very
much
related.
So
we
have
added
something
in
the
dogs
about
source
generation,
and
this
is
a
feature
which
claims
to
require
dotnet,
nine,
sorry
c9,
but
we
do
have
these
projects
compelled
all
the
way
from
dot-net
framework,
four
six
one
and
it's
working
without
issue.
So
it's
it
says.
A
If
we
have
like
tests
covering
all
the
target
frameworks,
we
should
be
safe
to
do
so
and
it's
already
something
which
is
done
by
the
language
runtime
itself.
So
if
you
go
to
the
github
repo
for
the
diagnostic
source
package
itself,
the
endear
repo
is
already
always
on
the
latest
version
of
c,
even
though
the
libraries
themselves
target
older
version.
So
it's
like
very
similar
to
our
setup,
and
if
you
have
a
good
test
coverage
covering
all
the
target
frameworks,
then
we
should
be
safe.
A
That
was
what
I
learned
from
the
dotnet
team,
but
it
still
a
little
bit
confusing
because
the
dog
says
slightly
different
thing.
So
unless
I
mean
we
haven't
found
any
issues
so
far
and
we
do
have
test
coverage
which
test
all
the
metrics
like
dotnet,
four
six
one
and
higher.
In
fact,
we
were
testing.452
a
couple
of
months
back.
D
I
do
have
some
perspective
on
this
yeah
go
ahead,
there's
a
difference
between
the
compiler
and
the
runtime
right.
The
compiler
is
emitting
msil
that
the
runtime
executes
so
you're
safe
to
compile
against
newer
versions.
However,
there
are
things
in
the
c
sharp
language
like
the
range
operator.
D
A
That's
exactly
the
message
I
got
from
yeah
so
michael.
This
excite
example
was
used
by
nova
and
tara,
both
from
dotnet
team
to
explain
that
we
should
be
safe,
because
that
should
result
in
error
and
our
discoverage
or
ca
would
basically
capture
it.
B
A
D
A
E
C
A
Else
ellen,
like
you,
go
ahead.
C
So
yeah,
I
totally
agree.
I
would
I
mean
I
think
it
would
be
a
big
bummer
not
to
be
able
to
use
the
latest
language
features.
You
know,
obviously
the
ones
that
we
can't
use,
but
I
was
a
little
bit
taken
aback
by
the
documentation
in
that
you
know
I've.
A
Problems,
it's
interesting,
maybe
like
we
could
file
a
doc
issue
against
this
page
see
if
it
was
like
intentionally
added,
because
if
you
look
at
the
actual,
like
the
runtime
repo,
like,
for
example
like
diagnostic
source,
they
do
always
upgrade
to
the
c
sharp
latest
and
they.
D
Still
does
in
my
own
production
code,
that's
running
on
that
framework,
we're
using
c
sharp
latest
and
in
the
case
of
like
range
and
index
and
stuff
that
are
missing,
we've
just
kind
of
shimmed
in
those
runtime,
you
know
missing
little
objects
and
it
all
works
great.
So
I
haven't
run
into
any
problems
in
my
own
experience
for
whatever
that's.
A
Worth
yeah,
I
mean
it's
always
good
to
know
if,
at
all
like,
we
find
an
issue
that
would
be
really
interesting
to
like
discuss
that
so
far.
The
consensus
is
we
stick
with
the
latest
version
and
we
do
have
like
cas
covering
all
the
frameworks
which
we
are
expected
to
support,
and
we
also
have
like
some
precedence,
the
runtime
report,
selfies
doing
it
and
maybe
like
I-
can
create
and
dock
issue
to
see
whether
it
is
like
whether
there
was
any
reason
why
that
warning
was
put
in
the
dock.
A
A
Whatever
we
promised
for
1.2-
and
it's
still,
the
specification
is
still
not
there
and
based
on
the
meeting
from
today
morning,
like
riley,
would
be
resurrecting
this
pr
to
mark
spekas
table
and
give
it
one
more
week
for
folks
to
comment
if
there
is
any
reason
why
it
should
not
be
marked
as
stable
so
which
basically
means
by
next
segmenting.
We
should
have
an
update
whether
people
has
any
have
any
more
concerns
about
marking
the
sdk
speakers
table
and
based
on
that,
we
should
be
able
to.
A
A
It
was
generally
agreed
that
those
are
like
dealing
with
like
specific
core
cases
and
which
can
be
like
added
even
after
the
fact.
Even
after
we
do
the
initial
stable
release,
because
right
mo
some
of
the
things
which
there
is
activity,
they
are
already
touching.
The
api
spec
and
the
ap
is
already
stable
for
like
over
two
months
now.
A
So
if
we
can
make
changes
to
the
ap
spec,
even
after
it's
stable
you,
usually
that
applies
to
the
sdk
as
well
as
long
as
it's
not
breaking
so
I'm
reading
it
as
like
in
the
next
week.
We
would
get
a
like
firm
date
on
when
the
spec
would
be
market
stable,
and
then
we
would
be
like
unblock
from
that
perspective.
A
In
case
someone
is
like
asking
why
we
are
after
that
date,
because
the
1.0
release
is
not
just
adding
the
metrics,
because
we
had
like
some
upper
bound
limits
on
thing
diagnostic
source
and
microsoft
extension
slogging,
so
that
basically
prevents
people
from
using
our
sdk
internet
6
unless
we
ship
1.2.
A
So
some
people
were
asking,
can
we
do
a
hotfix
to
the
previous
one?
But
I
was
basically
funding
that
with
the
hope
that
we
should
be
able
to
get
to
1.2
very
soon,
so
yeah
give
an
update
next
tuesday,
because
next
tuesday
is
the
next
spec
meeting
as
well.
So
I'll
get
a
more
firmer
answer
by
before
the
beginning
of
our
dot
net
segment.
A
Yeah
next
we
will
go
to
matrix.
We
are
in
the
concrete
repo,
so
this
one
and
any
like.
Maybe
you
can
walk
us
through
like
this
pr,
like
the
original
intent
is
we
want
to
like
offer
some
mechanism
for
users
who
are
previously
used
to
using
the
event
counter
feature,
and
we
want
to
use
upper
telemetry
to
subscribe
to
those
events.
A
So
this
is
the
pl
for
that
and,
as
we
discussed,
the
only
thing
which
we
discussed
was
it
will
be
in
the
contribute
and
we
won't
be
blocked
by
semantic
conventions,
because
this
does
not
add
like
instrumentation
in
the
typical
sense
of
instrumentation.
It's
just
converting
an
old
metric
api
into
the
numeric
api.
So
I
expect
like
once
we
are
all
satisfied
with
the
api
and
usage
we
should
be
unblocked
and
we
can
release
this
thing
yeah.
So
where
do
I
start
like?
Maybe
henry
you
can
do
you
want
to
share?
E
Yeah
we
can,
you
can
keep
sharing.
I
was
trying
to
pull
this
up
as
you
were
talking.
So,
as
you
saw
my
comment
like
initially,
I
started
looking
at
it
and
I
just
want
to
make
sure
if
we're
even
talking
about
the
right
thing
when
we
say
even
counters-
and
I
wasn't
missing
something
in
that
area,
so
I
just
gave
the
initial
kind
of
okay:
here's
how
we're
gonna
listen
into
the
event
counter
sin
process,
and
so
maybe
you
can
look
at
the
event
counter
inside
the
implementation.
A
A
E
Yeah,
so
if
you
go
down
to
the
the
example
usage
inside
the
main
right,
so
that's
a
example,
usage
of
using
it
like
so
tony
vince-
I
didn't
know
him
before,
but
once
I
started
working
on
it
he
jumped
on
and
he
kind
of
helped
with
a
lot
of
this.
And
basically
the
view
is
that
okay,
there
are
some
well-known
event
counters
like
in
the
event
counter
documentation
on
the
microsoft
docs.
There
are
some
well-known
counters
and
so
add
some
programmatic
use
of
those
ones.
E
But
of
course
there
are
going
to
be
other
event,
sources
that
either
customers
or
even
frame
microsoft
or
any
other
team
will
provide,
and
we
need
to
be
able
to
describe
them,
and
so
that's
the
second
example
on
line
52
and
how
you'd
add
event
source
and
describe
the
name
and
also
like
the
type
of
the
metric.
So
if
you
look
at
the
line
57
you
can
describe
what
the
type
would
be.
A
So
this
this
line-
if
I
were
to
understand
correctly,
this
is
instructing
that
there
is
even
source
with
this
name
it
contains.
I
mean
it
has
like
so
many
even
counters
within
that,
but
I'm
only
interested
in
the
ones
with
the
name
these
two
and
what
is
the
third
line
means.
So
that
is
what.
E
It's
getting
published
with
the
dot
net
six
api
or
the
open
telemetry.
A
So
one
q
question
here
like
there
are
like
two
counters.
So
how
would
they
map
to
a
connections
per
second
single
thing,
or
is
it
like.
A
Okay,
okay,
so
the
connections
per
second
you
encounter
will
be
transmitted
with
the
name
connections
per
second
and
it
will
be
a
treated
as
say
some
okay,
yeah
and
yeah
rusty
is
standard
yeah.
These
are
like
just
like
nice
to
have
helpers
right.
Yes,
yeah!
You
don't
really
need
this.
You
can
easily,
if
you
know
the
name.
You
can
add
this
yourself
right,
yeah,
okay,.
A
If
anyone
has
questions
on
usage
other
ways,
we
can
go
to
like
whatever
kind
of
safe
implementation.
Yes,
okay,
I
did
think
of
like
something
because
in
even
countries
I
think
there
are
like
this
notion
of
falling
and
incrementing
and
something
right.
So
how
would
you
distinguish
like?
Do
we
even
distinguish
that
or
do
we
let.
E
E
E
So
you,
this
is
kind
of
been
like
crypt
from
the
app
insights
implementation.
So
you
look
at
the
names
of
things
and
also
the
type
that
is
getting
published.
F
A
Look
at
the
name
other
things
from
here
and
the
actual
value
and
okay,
okay,
you
basically
have
to
figure
out
whether
it's
in
rate
metric.
E
Or
you
know.
A
Yeah,
okay,
based
on
that,
you
would
determine
whether
it
is
yeah
metric
type.
Okay,
I'm
a
bit
curious
about
this
usage.
But
let's
go
on
to
you.
Okay,
you
use
the
metadata
from
the
even
counter
itself
to
determine
whether
you
are
supposed
to
calculate
the
rate
yourself
or
it's
already
giving
you
the
rate
already
so.
Okay.
A
Interesting
yeah
because
I
never
assumed
that
these
types
would
be
useful
in
apa.
This
were
designed
for,
like
exporters
purposes
like
if
you're
writing
an
exporter,
you
want
to
know
what
kind
of
metric
you
are
getting,
so
you
would
use
a
like
something
like
a
e
files
ladder
or
a
switch
case
to
see,
but
you
are
using
it
here
and.
E
Then
what
would
happen
yeah?
I
guess
we
could
have
created
entirely
new
types
to
track
that,
but
you
need
to
track
it
and
it
seemed
to
fit,
and
it's
not.
I
guess
it
wasn't
designed
for
that
purpose,
but
it's
being
used
for
that
purpose,
but
I'm
open
to
feedback.
This
is
also
something
that
tony
contributed.
So
I'm
not
super
familiar
with
about
the
design
decision.
I
just
looked
at.
I
was
working
on
it
and
he
came
in
and
it
looked
good
to
me
so
we
just
went
with
it.
So
if
there
is.
A
E
A
This
part
is
like
little
bit
unclear
to
him,
because
we
cannot
really
assume
that
it's
a
long
right
the
sun
could
be
like
unless
that
it's
in
the
contract.
That
sum
is
always
in
teacher,
but
that
I
don't
but.
E
E
I
I'll
leave
some
comments,
but
okay
yeah
we
can.
We
can
like
parse
it
and
and
then
do
some
extra
work
there
in
for
the
type
right
like,
instead
of
depending
on
like
we're,
assuming
that
you
know,
which
is
what
we're
doing
here.
A
Yeah
and
how
there
is
another
thing
which
I
I
saw
on
the
maybe
read
me
like
something
about
the
time
interval
forget
like,
but.
E
Option
that
goes
and
on
the
event
counter
on
the
subscription
to
the
event
counter
or
even
source.
You
have
to
tell
it
what
the
interval
that
it
aggregates
that
the
event
counters
themselves
aggregate
so
the
event
counter
output
is
basically
an
event
source,
that's
aggregated
over
a
time
interval,
and
that
is
the
time
in
seconds
and.
E
The
whether
it's
an
increment
or
a
polling
that
determines
the
aggregation
that
even
the
event
counter
out
or
the
event
counter
output
determines,
but
this
is
the
same
interval
for
all.
I
believe
once
you
listen
to
it,
okay,
so
I
think.
A
Like
what
the
way
I
read,
it
is
like
even
counter
you
are
asking
even
counter
aggregate
everything
you
receive
for
55
seconds
in
memory.
Yes,
at
the
end
of
that,
give
me
a
like
payload,
which
all
the
information
you
have
aggregated
so
far,
and
I
will
in
turn
convert
that
into
a
like
some
metric
instrument
in
the
new
api.
A
Yeah.
Okay,
make
sense
so
far,
and
it
should
always
only
be
asynchronous
commander
or
a
synchronous
squeeze
like
that's
the
only
way
you
can
convert
something
like
a
yes
or
back
right,
so
I
guess
it
should
be
like
somewhere.
I
just
haven't
like
read
it
enough,
but
okay
and
then
like
once,
you
set
up
the
sdk
to
listen
to
that
particular
meter.
A
You
would
be
like
exporting,
as
which
the
data
which
can
be
coming
from
so
it
can
be
either
a
guide
or
an
asynchronous
counter,
yeah,
okay,
so
that
part,
okay,
I
think
I
I
need
a
little
bit
more
time
to
understand
like
how
do
we
determine
whether
it's
like
great
or
not?
Yeah,
probably
have
you
thought
about
like
letting
the
user
like
provide
it
completely
like
when
they
like,
say
that?
Okay,
this
is
the
metric
which
I
am
interested
in
and
by
the
way.
A
I
know
that
this
is
a
great,
so
treat
it
as
a
instead
of
like
b
being
trying
to
pass
it
and
determine
whether
it's
an
integer
or
not.
Is
that
something
which
you
thought
of.
E
So,
wouldn't
the
line
on
line
57
tell
that
it's
like
okay,
you
want
like
an
integer
type.
You
know,
isn't
that.
A
A
Can
only
allow
asynchronous
one
because
of
the
nature
of
even
counters,
so
we
can
either
say
treat
it
as
segues.
E
Yeah
yeah
yeah.
So
if
you
can
like.
A
C
C
I
actually
don't
have
a
whole
lot
of
experience
with
event
counters.
I'm
excited
to
play
with
this,
though,.
A
This
is
it's
a
very
special
thing
because
when
just
some
background,
so
in
2019,
when
we
were
building
open
elementary
in
the
first
place
and
we
were
building
the
upper
elementary
ap,
we
were
considering
using
even
counter
from
the
net
runtime
as
our
api
just
like
activity,
but
like
took
like
only
few
minutes
to
realize
that
it's
not
capable
because
it
does
not
really
have
the
notion
of
dimensions
or
like
attributes,
and
it
already
it
has
a
like
a
predetermined
way
of
aggregating.
A
So
you,
you
cannot
like
change
the
aggregator
to
something
else,
so
it
has
like
prefixed
or
predetermined
aggregates
it's,
and
you
only
have
like
two
kind
of
instruments:
it's
either
a
incrementing
thing
like
which
it's
very
similar
to
some
or
just
a
number
language.
A
So
because
of
that,
we
at
that
time
decide.
Okay,
we
cannot
use
even
counter.
So
if
we
were
to
use
something
from
the
dotnet
as
the
open
elementary
matrix
api,
we
have
to
like
design
from
the
ground
up
and
that's
what
resulted
in
the
new
metrics
api.
So
this
br
is
like
trying
to
patch
the
even
counter
and
or
adapt
even
counter
and
save
it
to
as
a
new
api
yeah.
So
that's
just
some
background
for
folks
who
are
not
familiar
yeah.
A
I
think,
since
not
many
people
are
like
very
familiar
with
encounter
itself,
we
can
leave
it
up
to
the
pr
comments
to
discuss
more
on
this.
I
would
be
taking
a
look
at
it
like
one
quick
feedback
which
I
want
to
give
is.
We
would
want
to
keep
it
very
small.
A
It's
very
easy
to
review,
because
if
you
have
like
pr
with
50
files,
it's
usually
less
easy
to
catch
issues,
so
you
likely
miss
something
so
maybe
like
you
can
split
that
into
like
something
which
just
builds
a
manual
one,
and
these
things
really
are
optional.
We
can
always
add
it
on
top.
A
Maybe
we
could
make
it
as
a
separate
package
if
you
want,
but
those
are
things
which
we
can
disclaim
later,
but
I
would
say
the
basic
thing
is
you
have
the
ability
to
specify
which
counter
you
want
from
this
given
source?
And
how
do
you
want
it?
How
do
you
want
to
treat
it?
Is
it
rage
or
counter,
and
probably
like
other
things
like
description?
A
There
are
a
few
other
things
which
the
api
allows.
Then
we
can
maybe,
like
optionally,
include
these
things,
because
this
is
just
like
a
wrapper
around
I
mean
just
yeah
yeah
yeah.
It
has
the
knowledge
about
the
well-known
names.
So
maybe
we
can
remove
that
knowledge
from
the
this
project,
because
this
is
like
the
bare
minimum.
Even
counter
thing,
you
can
build
anything
on
top
of
it
and
spin
it
or
grpc
could
be
like
optional
add-ons
on
top
of
it.
A
That
way,
we
can
like
reduce
the
overall
hope
it
would
make
it
slightly
easier
to
be
useful.
Yeah.
Do
you
like?
Do
you
have
other
questions
which
we
want
you
want
to
like
here?
I
left
some
commentary,
but
it
looks
like
it
has
been
yeah,
it's
waited
since
then,
so
I.
E
E
Yeah,
so
I
didn't
resolve
it,
but
I
do
have
a
question
like
the
samples
you
know.
The
build
is
like
using
net
five,
and
so
we
had
a
dot
net
example.
It
was
failing
so
rather
than
update
the
bill
to
use
dot
net
six,
I
just
reverted
our
example
to
dot
net
five.
Do
you
have
any
opinion
on
that?
Yeah.
E
A
B
A
Cas
to
use
six
also,
so
we
should
be
able
to
just
steal
from
that,
but
if
you
can
just
include
that
in
a
separate
year,
okay.
A
Yeah-
and
I
don't
know
what
whether
anyone
else
have
opinion
about
examples,
unless
it's
really
needed,
I
would
avoid
adding
like
more
examples
here,
because
it
should
be
like
very
straightforward
from
the
read
me:
okay,
I'll
I'll,
just
take
that
I'll
just
take.
A
Yeah,
so
one
unfortunate
thing
is
our:
we
do
have
examples
in
the
main
repo,
but
they
currently
do
not
have
a
way
to
like
refer
to
things
from
the
country
repo.
So
maybe
you
need
to
like
follow
what
like
other
languages
are
doing.
I
think
java
decided
to
host
examples
away
from
both
the
main
repo
and
contribute,
so
they
can
like
equally
refer
refer
to
the
packages,
but
that's
a
separate
discussion
but
yeah,
I
think,
like
we
should
be
able
to
get
rid
of
the
examples
from
this
report.
For
now.
A
We
have
like
someone
has
free
time,
that's
something
which
we
should
be
doing.
It's
just
that
I
never
had
the
time
to
actually
do
that.
We
discussed
it
like
maybe
like
one
year
back,
but
we
are
like
really
busy
with
metric
stuff.
So
it's
something
which
we
would
be.
We
should
be
doing
so
and
the
main
reason
it's
not
like
a
like
p1
is
because
whatever
we
do
here,
it's
still
like
not
stable
because
of
the
semantic
convention
thing.
A
So
it's
still
like
several
months
away
before
we
can
actually
do
an
actual,
stable
release.
So
we
just
need
to
make
sure
we
don't
release
something
as
stable
before
we
have
the
names
finalized.
So
that's
the
only
reason
why
I
don't.
I
never
treated
this
as
a
key
one
thing.
If
anyone
has
like
free
cycles,
that
would
be
a
very
nice.
Maybe
do
have
issues
open
for
that
or
probably.
G
A
See
the
let
me
see
if
I
can
go
to
a
nuget
package,
so
the
nuget
package
will
not
have
the
name
contribute.
The
repo
will
still
be
the
same.
The
package.
Oh
so
basically
we
are
going
to
do
remove
the
name
contrib
from
here,
so
it
will
be
yeah.
It
will
be
open.
Elementary.Extensions.Iw6A.
A
A
Okay,
maybe
it's
easier
to
go
this
way.
We
can
find
all
the
packages
from
a
tree.
So
let's
find
something
yeah,
so
this
rx
numbers
it
goes
to
the
same.
Nougat
say
everything
is
same,
except
that
now
we
want
to
rename
it
to
open
elementary
dot,
instrumentation
dot
mass
transit,
pretty
much
like
the
instrumentation
dots
dot
sql.
This
is
coming
from
the
main
group,
but
that
is
visible
from
the
source
repository
here
this
field,
so
that
would
have
to
distinguish
between
where
the
source
is
and
also
like.
A
The
nuget
has
enough
metadata
to
even
point
to
the
exact
commit,
so
we
don't
need
to
include
the
name
control
here.
I
don't
think
like
any
other
language
is
done.
It
just
said
we
started
it
that
way
and
we
never
like
spend
enough
time
to
like
remove
it.
Like
I
said,
the
main
lack
of
motivation
is
whatever
we
do
here.
It's
still
going
to
be
like
not
stable
for
unknown
amount
of
time.
A
C
A
Yeah,
I
think
that
would
be
the
best
answer
for
now,
because
if
you
look
at
the
runtime
issue,
I
don't
think
dot
net
is
planning
to
add
or
replace
the
existing
counters
with
the
new
metric
api,
at
least
in
the
dot
net.
Seven
time
frame.
A
So
it's
very
typical,
but
let
me
see
if
I
can
find
it
still
an
item
which
says
investigate
what
matrix
needs
to
be
added
to
the
runtime:
it's
not
clear
whether
they
are
going
to
add
more
and
more
even
counters
or
whether
they
are
going
to
use
a
new
matrix
api.
So
if
the
answer
is,
if
runtime
picks
up
new
matrix
api
for
everything,
then
we
don't
need
that
even
counter,
except
for
people
in
the
order
framework,
but
that
it's
it's
just
an
investigation.
So
we
need
to
wait
for
that.
A
But
I
believe,
since
when
counter
is
already
like
fairly
extensively
producing
metrics
for
all
the
runtime
things,
it
should
be
like
extremely
valuable
for
us
right
away
because
it
produces
things
like
gc
stats,
memory,
cpu
and
then
a
lot
of
things
from
the
kestrel
as
well
like
about
queueing
time
and
all
those
things.
So
it's
probably
documented
in
that
well-known
encounters
page,
so
it
I
I
would
be
like
surprised
if
everything
off
all
of
this
get
eventually
moved.
A
A
Yeah,
so
when
I
I
mean
the
same
issue
which
I
asked
like
there
are
like
several
mentions
about
open
elementary
things
and
the
general
feeling
is
or
general
agreement
within.net
from
what
I
found
is
unless
it's
super
stable,
they
won't
even
consider
taking
it
because
it's
basically
like
semantic
inventions
have
like
very
low,
probably
like
three
year
of
backward,
combat
guarantee
but.net.
If
they
incorporate
something
into
the
runtime,
they
expect
it
to
be
like
forever.
A
A
So
for
a
visible
like
several
years,
I
don't
think
dot
net
would
magically
do
the
what
the
upper
elementary
semantic
conventions
would
do,
but
long
time.
Yes,
I
expect
there
would
be
built-in
things
from
the
dot
net
directly
matching
the
semantic
conventions.
C
A
C
A
A
This
could
be
like
mapped
into
something
else
roughly
because
there
is
many
conventions
for
http,
so
we
should
be
able
to
buy
probably
for
these
as
well
yeah,
and
then
there
are,
it
looks
like
at
least
half
of
them
are
like
really
neutral,
like
it's
very
much
applicable
to
every
other
language.
A
So
maybe
we
are
just
better
off
like
waiting,
but
there
are
like
specific
things.
Yeah
like
is
there
like
any
anyone
asking
for
it?
Alan
or
you?
You
are
just
curious
because
I
haven't
seen
like
much
effort
happening
in
the
semantic
conventions
for
metrics.
C
I
mean
I'm
mainly
thinking
about
the
runtime
stuff,
so
like
all
the
asp.net
core
stuff
and
all
that
I
agree
would
fall
underneath
like
the
http
semantic
conventions
and
so
on.
But
I
do
know
that
there's
a
java
working
group,
that's
just
spun
up
to
really
hone
in
on
java
specific
runtime
semantic
conventions.
C
A
Yeah,
I
agree
with
that.
I
think
like
we
need
to
like
first
find
enough
foreign
days
to
drive
that
it's
usually
like.
If
you
look
at
all
the
semantic
conventions,
there
is
generally
a
lack
of
like
volunteers.
People
are
like
literally
begging
in
every
spec
meeting.
Hey,
we
need
reviewers,
we
need
reviewers,
and
I
mean
if
you
look
at
the
attendees
list,
it's
like
very
short
for
in
general
semantic
convention.
So
I
I
usually
assume
that
people
are
just
waiting
for
like
matrix
and
traces
equally
be
stable
before
they
jump
into
that's
just
my
feel.
A
I
just
don't
know
how
true
that
is,
but
yeah,
that's
it.
Okay,
yeah!
Maybe
we
can
ask
in
the
next
spec
meeting
whether
how
do
we
go
about
like
creating
a
specific
one
and
see
if
there
is
enough
interest
for
having
a
separate
like
discussion,
around
dot
net,
specific
semantic
dimensions.
A
Spec
meeting
and
we
can,
we
can
discuss
that
yeah
and
do
you
know
like
who
is
driving
the
java?
Is
it
like
the
same
folks
who
drive
the
java
repository
or
is
it
like
a
separate
group.
C
A
Yeah
I'll
see
whether,
like
someone
from
the
dotner
team
itself,
who
would
be
interested
because,
like
one
of
the
issues
which
dot
team
is
considering,
4.7
is
like
figure
out
the
gaps
in
the
counter
which
they
have
so
maybe
I'll
ask
like
if
they
have
any
appetite
for
driving
this
sick,
I
mean
not
driving
at
least
joining
and
offering
some
suggestions.
A
E
Yes,
I
have
a
quick
question,
hopefully
that
since
we're
all
here
when
you
use
open
or
net
6
api
to
instrument
a
dotnet
application,
I
saw
that
at
least
one
sample
somewhere
show
these
metrics
show
across
the
event
pipe
in
a
tool
like
I
believe.net
monitor.
Can
you
point
me
to
where
that
is
happening?
I
I.
B
Can't
it
could
be
maybe.
A
Diagnostics
matrix
and
it
should
contain
something
called
like
cricketer
store
instruments.
Yeah
all
anything
which
is
not
public
here
is
used
by
that
tool.
A
I
don't
get
the
question
so
maybe
if
you
can
replace
it,
no.
A
Yeah,
the
pr
which
added
the
net
tooling
support
for
the
metrics,
which,
basically,
even
if
you
don't
use
any
open
elementary
sdk,
but
you
still
have
like
metrics,
which
are
emitted
using
the
new
api.
You
can
use
the
dotnet
counter
or
dotnet
monitor
tool.
Oh
actually,
why.
A
If
you
search
for
it,
you
should
find
the
dotnet
counters
tool
and
then
it
talks
about
how
do
you
listen
to
this
metrics
and
I'll
share
the
pr.
A
A
Okay:
let's
look
at
the
last
two
topics,
so
this
is
something
which
we
were
like
having
open
for
quite
some
time.
Okay
come
on,
this
is
basically
about
deciding.
How
do
we
refactor
or
rearrange
the
exporter
configuration
options
in
uaf,
like
several
I
mean
we
had
like.
Maybe
three
proposals
like
ellen
had
like
a
couple
of
them
and
then
michael
added,
like
a
alternate
proposal,
so
I
mean
I
had
like
very
minimal
time
to
look
at.
B
A
I
had
a
call
with
alain
alone,
just
to
walk
me
through
all
the
options,
so
I
want
to
see
like
if
it's
a
good
time
to
discuss
this,
maybe
like
since
michael,
is
also
here
yeah.
A
Most
folks
are
here
so
just
to
summarize,
I
think
the
issue
is
like
very
well
summarized
in
both
the
like
pr
description
come
on
yeah,
so
we
do
have
the
we
do
have
like
several
problems
like
one
is.
A
We
were
having
an
issue
where
the
exporter
has
exporter
options,
class
and
that
options
class
contain
things
which
are
applicable
to
that
exporter,
and
it
also
had
things
which
really
control
the
overall
pipeline,
as
in
which
processor
to
use
and
for
metrics
it
would
be
like
which
kind
of
metric
aggregation
to
use
and
what
interval
to
use.
So
these
are
like
different
attempts
to
like
split
them
out
to
make
it
like
relatively
easy
for
users
to
know
like
what
exactly
are
they
configuring?
A
So
this
is
a
pr
which
align
has
and
it's
relatively
easy
to
follow,
because
it's
not
doing
a
lot.
It's
just
extracting
or
removing
things
from
the
exporter
class,
the
exporter
options,
plus
anything
which
is
not
applicable
to
the
exporter
itself,
so
the
endpoint
is
applicable,
timeout
headers
protocol,
it's
all
applicable,
but
anything
which
is
not
applicable
to
the
exporter
itself,
is
moved
out
and
this
in
this
pr
only
the
metric
specific
one
is
moved
out.
A
It's
purely
because
it's
a
public
epa
to
public
api,
breaking
change
to
move
the
tracing
one.
So
one
way
out
of
this
would
be
like
we'll
keep
it
like
this
for
matrix.
Since
we
never
g8,
we
can
afford
to
keep
changing
and
in
some
future
versions,
we'll
mark
it
as
duplicated
and
do
the
same
thing
as
what
we
did
for
matrix.
So
people
can
eventually
get
rid
of
not
using
this
and
move
to
the
one
and
the
nice
thing
about
this.
A
Is
it's
fairly
easy,
but
still
it
has
the
downside
of
having
to
mark
something
as
duplicated.
It's
not
like.
We
have
to
do
it
right
away,
but
at
some
point
in
the
future
we
will
have
to
do
it.
It
doesn't
really
address
a
lot
of
the
reusability
aspects,
but
from
what
I
hear
from
alan,
the
reusability
can
be
like
a
separate
concern
like
we.
We
can
like
make
some
static,
hilbert
methods
where
all
the
reasonable
code
can
be
put
and
they
can
be
used
from
here.
A
So
that's
what
I
understood
from
allen's
approach
and
since
we
are
going
to
just
do
a
q
comparison
so
alain
like.
Can
you
correct
me
if
anything
is
misrepresented,
or
maybe
I'll
just
give
you
that?
I
should
just
ask
you
to
explain
sorry
for
not
doing
that,
but
is
there
anything
which
you
want
to
add
before
we
go
to
mike's
proposal
as
well.
C
A
C
A
Does
I
mean
you
mentioned
the
reusability
part
like
we
do
have
like
code,
which
are
kind
of
duplicated
within
otlp
exporter
for
metrics
and
traces,
and
also
for
http
versus
grpc,
but
you
said
it
should
not
be
like
solved
along
with
this.
It's
a
completely
separately
solvable
issue
right.
That's
your
opinion
right.
C
Yeah
correct
the
other-
I
guess
nice
thing
about
this-
is
that
the
extension
users
of
the
extension
method
are
the
only
ones
that
would
be
using
those
other
options
for
configuring
the
pipeline.
But
there
are,
you,
know
more
advanced
use
cases
where
someone
may
be
instantiating
the
exporter
by
hand
and
constructing
their
pipeline
without
the
extension
methods.
C
A
Yeah,
so
just
to
rephrase
what
you
said
like
you're,
basically
saying
if
the
user
is
not
using
the
like
extension
methods,
they
are
constructing
the
pipeline
by
hand.
So
in
that
case
they
would
only
need
to
supply
the
otlp
exporter
options
to
the
exporter
itself,
and
that
would
only
contain
things
which
are
pertaining
to
that
exporter
like
which
I'm
going
to
use
and
all,
and
since
they
are
constructing
the
pipeline
by
hand,
they
don't
need
to
like
tell
anyone.
They
just
create
the
pipeline
themselves
and
if
they
are
using
the
extension
methods.
A
So
now
they
would
be
providing
two
things.
One
is
just
to
applicable
to
the
exporter
itself,
which
is
what
we
currently
have,
and
we
would
also
have
another
one
which
allow
them
to
configure
the
pipeline
in
case
of
metric.
It's
basically
metallic
reader
for
tracer.
It
would
be
something
else
like
we
had
to
like
define
a
new
class
which
would
determine
whether
we
would
pick
the
matching
one
or
non-batching
one
and
based
on
that
some
other
parameters.
A
Okay,
let
me
quickly
open
the
one
from
michael.
So
michael,
do
you
have
a
few
minutes
just
to
like
quickly?
One
quick
thing
which
I
noticed
this
is
substantially
increasing
the
things
which
we
exposed
from
the
sdk.
I
think
you
already
put
a
comment
saying
that
we
should
be
able
to
like
extract
it
to
like
something
like
open
elementary
exporter
like
a
base
class
or
something
go
back
to
alan's
real
quick,
see
joe.
C
D
I
was
approaching
here
is
the
settings
for,
like
you
know,
temporality
and
the
period
those
aren't
really
the
concern
of
otlp.
Those
are
the
sdks
issue
right.
So
it's
we
have
these
sort
of
shared
concepts
in
the
sdk,
but
we've
pushed
it
down
into
the
exporter.
So
if
we
go
this
route,
what
you
see
on
this
pull
request
for
otlp,
we
will
also
need
in
prometheus.
We
will
need
an
any
tracing
exporter
or
metrics
export.
We're
gonna
have
to
duplicate
the
settings
and
the
extensions.
D
So
what
I
was
trying
to
do
is
put
something
in
sdk,
so
that
there's
sort
of
a
standard
way
where
those
settings
are
managed
and
the
extensions
go
and
then
all
the
exporters
in
the
core,
repo
or
anybody
else
making
their
own
could
also
utilize
kind
of
the
sdk
exporting
concepts
if
that
makes
sense
yeah.
So
basically,
you
are
saying
like
this.
D
D
D
C
A
while
ago,
I
think,
that's
good
feedback.
I
think
the
one
thing
that,
maybe
you
could
say
is
otlp
specific,
would
be
the
defaults
of
these
things.
You
know
you
put,
you
might
want
different
defaults
for
otlp
versus
prometheus,
but
yeah
and.
A
Not
just
before
that,
it
could
also
be
the
supported
thing
versus
unsupported,
like
prometheus,
would
only
support
cumulative.
So
those
are
things
I
think
we
can
handle
when
this
is
given
something
which
it
doesn't
support.
I
think
we
already
have
mechanism
to
throw
right
away.
So
that's
just
kind
of
the
the
ten.
D
Thousand
foot,
you
know
you
know
theoretical
or
what
what
I
was
trying
to
accomplish.
It
definitely
ended
up
a
lot
more.
You
know
it's
a
bigger
footprint,
there's
a
lot
of
interfaces
and
it's
a
little
bit
messier
than
I
would
have
hoped,
but
that's
what
I
was
trying
to
do
like
I'm.
A
stickler
for
like
dry.
Do
not
repeat
yourself.
So
if
I
see
the
same
class
going
like
you
know,
three
four
places
and
I'm
like:
oh,
how
can
we?
How
can
we
centralize
this
somehow.
A
D
A
Yeah,
so
one
concern,
I
think,
like
even
with
this
approach.
We
would
let
me
open
the
description,
because
I
I
was
trying
to
see
so
if
we
were
to
do
like
this
new
extension
method,
I
mean
which
takes
the
builder.
That
means
we
still
have
to
do
something
about
the
existing
ones.
It
should
be
that
we
well
no.
D
My
plan
there
was
everything
that
exists.
We
would
leave
alone,
so
in
each
exporter
assembly
it
still
has
an
options
class.
You
have
jager
options,
otlp
options
and
that
options
class
has
all
of
the
options
that
are
possible.
So
if
you
want
to
use
the
raw
apis
that
we
have
today,
you
can
continue
to
do
that.
You
can
just
new
up
the
options
and
set
whatever
you
want.
D
If
you
want
to
use
the
builder,
it's
basically
giving
you
a
little
cleaner
api,
that's
helping
you
configure
just
the
options
that
you're
interested
in,
but
at
the
end
of
the
day,
it's
still
setting
the
options
on
the
final
options
class,
so
we're
not
actually
changing
the
exporters,
we're
just
kind
of
putting
in
a
options
pipeline.
If
you
want
to
call
it
that
yeah.
A
And
I
think
alan
made
a
comment
here
about
that.
So
looks
like
we
still
have
to
solve
the
other
problem
pair.
That
options
should
not
technically
contain
anything
related
to
the
pipelines,
because
pipeline
is
a
like
higher
level
concept
than
the
exporter,
but
I
guess
it
should
be
possible
to
like
carry
it
out
from
the
current
because
it
looks
like
currently
you,
like
you
configure
the
pipeline.
A
Just
like
you
configure
the
exporter
itself,
which
is
something
like
we
want
to
like.
I
mean,
cannot
be
like
fully
avoided
because
for
tracing
it's
already
ga,
but
for
at
least
four
metrics
to
begin
with,
and
eventually
for
traces.
We
want
to
like
duplicate
that
mechanism,
saying
that
you
should
not
use
the
exporter
options
to
control
the
pipeline.
A
It
should
be
like
something
else,
so
I'm
still
trying
to
figure
out
like
how
we
can
curve
it
out
from
this
option,
because
this
at
least
does
not
in
the
current
shape,
does
not
attempt
to
like
split
that
out,
but
rather
it
allows
a
different
way
to
finally
get
the
options
by
using
the
builder
pattern.
Okay,
yeah,
I
think
both
have
six
merits
it.
A
It's
just
that,
like
we
have
to
like,
like
sometime
in
the
next
couple
of
weeks,
make
a
decision
to
move
on,
so
any
anything
else
like
which
you
want
to
share
like
which
might
help
folks
make
a
decision
on
it
like
there
are
like
some
comments.
I
saw
about
the
internal
variable
parsing,
but
I
think
those
are
like
relatively
minor
things.
We
should
be
able
to
make
that
happen,
irrespective
of
which
approach
we
take.
We
should
still
be
able
to
do
it
cleanly.
A
So
not
like
extremely
concerned
about
that.
Yet,
unless
someone
like
corrects
me
now.
A
And
my
only
thing,
I
think
there
are
a
lot
of
things
which
we
might
not
be
required
because
we
are
like
pretty
much
exposing
the
I
mean
increasing
the
sdk
surface.
A
Even
though
I
don't
really
know
whether,
like
these
things
is
useful
for
all
of
the
exporters
like
maybe
like,
some
of
them
might
use
it,
some
of
them
might
not
use
it,
so
it
will
still
be
like
leaving
us
with
some
of
the
original
problems
which
we
had
basically
like.
The
exporter
has
some
options
which
talks
about
batch
processing,
but
a
metric
processor
has
nothing
to
do
with
their
batch
processing,
so
we
still
have
like
unrequited
things
lying
around
which
might
potentially
confuse
folks.
A
So
we
don't
really
solve
that
problem
with
this
approach
either
mike.
Do
you
see
like
what
I
just
described?
A
With
a
co-worker
yeah
sorry,
so
I
was
just
saying
like
even
with
this
approach
like
we
still
have.
This
like
things,
for
example,
like
http
client,
is
like
exposed
directly
from
the
sdk.
Some
exporters
may
not
even
need
this
thing
so
how
it
looks
like.
D
It
will
be
like
remaining
there
yeah,
so
I
basically
distilled
like
the
three
common
settings
that
we
have
trace
settings
metric
settings,
http
settings,
so
those
became
interfaces
and
then,
if
you
look
in
like
go
to
jaeger,
what,
if
you
open
the
jager
options?
Does
it
implement
those
interfaces?
D
D
A
Okay
got
it
so
if,
if
I
were
to
look
at
the
otlp
exporter
options,
it's
rightly
implementing
all
three,
because
it
supports
trace
options,
metric
options
and
http
client
factory.
So
if
I
have
a
exporter
which
does
not
allow
http
client
customization,
so
it
will
simply
not
choose
to
extend
from
that
or
implement
that
yeah
yeah.
I
would
do
like
leave
some
comments
now
that
I
got
like
more
field
of
different
approaches.
I,
like
briefly
shared
some
comment
with
alan
when
I
spoke
to
him
offline.
A
But
let
me
leave
some
comments
and
I
interest
like
everyone
to
like
share
some
opinions.
If
you
consider
like
one
approach
here
or
like
one
approach,
has
some
advantages
which
we
are
probably
like
missing
out
or
something
so
we'll
do
this
thing
like
next
tuesday
meeting
we'll
make
a
final
decision
like
which
approach
we
want
to
go
because
once
we
finally
found
the
approach,
we
still
need
like
some
time
to
like
actually
finish
coding
it
up,
because
both
are
like
having
a
lot
of
to-do's.
A
While
we
are
waiting
for
the
approach
before
we
spend
too
much
time.
So,
let's
put
a
timeline
by
next
tuesday
we'll
make
a
decision
in
this
call,
and
we
have
like
probably
like
another
week
to
implement
this
thing,
with
the
assumption
that
respect
would
be
like
stable
by
them.
So
we
wouldn't
be
blocked
by
the
spec
but
rather
be
blocked
by
our
own,
like
pending
peers.
A
A
Okay
yeah,
so
I
think
from
a
like,
apart
from
the
things
which
are
controlled
by
the
spec
repo,
the
only
thing
which
is
like
really
like
we
want
to
like
solve
before
we
shift
the
stabilize
these
two
pr's.
There
are
like
few
relatively
small
items
in
the
matrix
which
we
left
untouched
after
december.
A
I
would
retrieve
them
and
see
if
it
still
makes
sense
or
see
if
it
is
like
something
which
we
want
to
address,
or
we
can
address
post
stable
release.
A
There
are
some
incoming
spec
clarifications
as
well,
so
I'll
take
a
look
at
that
and
see
if
it
requires
us
to
do
anything
in
the
actualistic
implementation,
I
mean
unless
it's
a
critical
thing,
I
would
just
create
issues
saying
that
okay,
this
is
a
non-issue
you're
unlikely
to
hit
it,
because
all
those
spec
clarifications
are
about
like
really
corner
cases,
so
we
fix
it
in
the
post,
stabilities
yeah,
any
other
things
to
discuss.
If
not,
we
can
end
now
and
see
again
next
week.
A
Okay,
thanks.
Everyone,
please,
like
set
aside
some
time
to
review
these
two
approaches
and
also
to
look
at
the
even
counter
one.
So
like
this
is
only
instrumentation
which
we
can
ship
without
instrumentation
declaring
the
semantic
conventions
are
stable,
and
it
should
be
like
instant,
instant
value
to
a
lot
of
folks.
So
let's
try
to
spend
some
time
helping
to
ship
this
one
as
well.