►
From YouTube: 2021-08-26 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).
A
A
A
Yes
yeah,
so
I
I
think
currently
we
have,
we
have
two
pr's
one
is
the
the
exemplar
pr
from
josh
I'll
I'll,
find
a
link
here,
another
pr
something
I
sent
yesterday
on
the
metric
reader.
A
So
in
practice
it
is
working.
Although
there's
some
like
potential
improvement,
we
can
make.
So
please
take
a
look
and-
and-
and
I
have
a
another
specific
thing
I
want-
I
want
to
talk
about-
I
put
a
comment
here,
so
the
the
current
pr
I
haven't
covered.
A
How
can
we
support
the
collection
cycle
to
be
different
than
the
exporting
cycle,
but
there's
a
an
issue
like
open
almost
a
year
ago
asking
for
it-
and
I
I
think
many
folks
need
that
feature.
So
I
have
a
proposal
here.
My
question
is:
do
you
think
this
is
something
we
should
address
in
the
initial
version
or
we
we
can
revisit
that
later?
A
I
believe
we
can
add
that
later
without
having
to
break
any
existing
thing,
but
I
also
think
adding
that
now
shouldn't
introduce
too
much
problem,
so
just
want
to
get
some
feedback
here
and
please
reply
back.
A
And-
and
once
you
you
finish
looking
at
the
pr,
please
also,
let
me
know
if
you
think
we
should,
we
should
keep
the
current
scope
and
focus
on
getting
the
pr
merged,
or
you
want
me
to
update
the
exporter
part
by
default.
I,
I
would
tend
not
to
add
more
things
to
this
pr,
because
I've
made
several
mistakes
before
that
I
start
to
send
the
sdk
pr
is
becoming
big,
and
then
I
have
to
scope
down.
So
in
this
way,
like
I
scope
down
initially,
I
hope
that
would
help
us
to
move
faster.
B
Yeah,
so
this
is
something
that
just
cropped
up
this
morning,
it
was
triggered
by
release
of
the
kind
of
the
first
metric
instrumentation
in
the
java
instrumentation
repository
that
had
a
cardinality
explosion
in
it
and
caused
a
memory
leak
in
the
sdk
and
there's
there's
like
a
few.
B
So,
as
you
know,
as
josh,
just
something
pasted
in
there
memory
leak
at
the
pull
exporter
never
gets
called
or
if
there's
no
push
exporter
actually
defined,
but
the
sdk
is
running,
but
there
I
mean,
I
think
so.
B
We
need
to
figure
out
some
sort
of
standard
way
or
standard
specification
for
how
the
circuit
breaker
should
happen.
If
an
instrument
starts
reporting,
exploded,
cardinality,
metrics
or
recordings,
this
will
partially
get
addressed
when
we
have
a
hint
api,
but
instrumentation
can
still
be
bad
and
can
still,
you
know,
put
in
a
hint
that
has
cardinality
explosion
in
it.
A
Yeah,
I
I
know
sigil
has
done
something
in
donna
in
his
prototype
and
I
I
believe
the
current
thinking
is.
We
will
have
some
limitation
and
once
you
reach
that
cardinality
limitation,
we'll
just
stop
the
events
by
giving
some
internal
login.
So
you
won't
be
able
to
know
that,
but
we
don't
yet
think
it's
ready
to
expose
some
configuration.
A
I
mean,
of
course,
if
we
have
that
limitation
thing
we
can
expose
something.
My
worry
is
that
limitation
might
might
be
more
complex
than
we
think
I
I
can
share
one
scenario
like
in
microsoft,
we're
saying
there
are
different
dimensions.
Some
folks
think
this
is
the
dimension
that
might
be
coming
from
the
user.
We
don't
have
full
control
in
this
case.
A
B
B
A
C
Yeah
no,
I
can.
I
can
also
cover
that
one,
okay,
so
implementing
the
view
api
in
java
and
we
ran
into
a
fun
kind
of
a
fun
one.
So
in
the
specification
right
now
for
aggregators,
it
allows
you
to
specify
monotonicity
for
histograms
and
for
sums
right.
So
the
tl
dr,
is
so
far.
We've
been
treating
counter
instruments
as
inherently
monotonic
and
not
allowing
negative
measurements,
and
that's
documented
gauge,
histogram,
sorry
gauge
and
up
down
counter
allow
non-monotonic
sums
because
they
allow
negative
measurements.
Okay.
C
C
So
how
do
we
let
the
user
know
that
that
happened?
Do
we
drop
the
negative
measurement,
because
I
I
think
that's
what
the
specification
is
implying,
but
then
it
seems
kind
of
disingenuous
to
kind
of
allow
that
to
happen
right.
So
if
we
drop
the
measurement,
do
we
log
it
as
an
error
like?
What's
what
what
behavior
do?
We
want
to
see
here.
D
C
Okay,
are
you
what
are
you
doing
if
so,
from
a
practical
standpoint
in
your
counter
instruments,
if
someone
sends
you
a
negative
count,
because
that's
possible,
if
you're
using
like
doubles
or
integers
right,
what
are
you
doing
there?
Are
you
throwing
exceptions
or
are
you
logging.
C
E
So
let
me
can
I
bring
up
a
scenario,
a
question
on
how
we
would
want
to
deal
with
that.
So
if
we
were
using,
let's
say
a
gauge
which
allows
the
instrumenter
to
insert
both
positive
and
negative
values,
my
understanding
is,
the
view
is
where
you
could
alter
the
default
aggregation
for
that
gauge.
So
is
it
possible,
then
to
say
hey.
I
know
that
my
gauge
is
collecting
positive
and
negative,
but
I
want
to
change
the
aggregation
to
only
be
monotonic.
C
That's
that's
basically,
my
question
here
so
like
java
didn't
allow
that
previously,
so
I'm
gonna
be
exposing
it,
but
I
wanted
to
check
and
see
if
we
think
this
is
going
to
be
confusing
to
users
like
I'm
of
two
minds
here.
One
is,
I
think,
it's
useful
for
a
user
to
say
you
know
what
I
know
that
this
was
instrumented
as
a
gauge,
but
it's
really
a
monotonic
sum
and
I
know
better
than
the
instrumentation,
because
I'm
the
user
and
I
see
what
these
values
are.
F
C
C
Yeah,
so
I
think
the
simple
thing
to
do
if
we
don't
want
to
invest
in
this
use
case,
is
we
actually
just
drop,
providing
monotonicity
as
a
config
parameter
from
any
of
the
aggregators,
and
then
they
just
pull
in
the
default
monotonicity
based
on
the
instrument,
and
then
we
don't
have
to.
I
think.
G
I
think
that's
the
most
reasonable
for
a
v1
and-
and
I
I'm
pretty
confident
that
we
can
do
it
in
a
in
a
backwards
compatible
way
to
add.
A
Yeah,
so
I
have
a
question
like
whether
we
do
it
now
or
later.
If
we
ever
want
to
allow
such
thing,
we
will
always
see
the
issue
that
people
give
us
some
value.
That
was
not
anticipated,
and
I
just
want
one
to
explain
the
challenge.
I've
seen
down
that,
I
think.
Currently,
we
have
a
philosophy
that
instrumentation
should
not
throw
exception,
because
we
don't
want
people
to
always
use,
try
cache
for
every
single
instrumentation
and
for
logging.
A
I
think
currently
we
put
it
to
do
instead
of
making
actual
log
is
because
we
believe
matrix
could
be
called
much
higher
frequency
than
the
logging
system
could
handle
like.
If
you
call
the
matrix
one
million
times
and
the
system
got,
some
illegal
value
are
going
to
log
everything
I
I
think
that
would
blow
the
system
away.
G
C
I
I
think,
I'm
going
to
say
what
bachmann's
saying,
but
in
java
we
have
a
throttling
based
logger,
where
there
needs
to
be
a
way
to
limit
the
number
of
times.
An
error
is
reported
to
the
logging
system.
To
be
basically
useful,
I
mean
that's.
This
is
like
a
common
thing
of
basically,
you
know
I
can
report
an
error
message,
but
if
I'm
recording
the
same
error
message
a
thousand
times
within
you
know
a
couple
milliseconds,
it's
not
useful.
C
So
the
idea
behind
the
throttle
and
logger
is:
it
only
allows
error
messages
from
a
particular
component
to
come
out
once
every
n
seconds
or
once
every
you
know
and
minutes,
depending
on
how
you
configure
it.
So
that
would
be
my
suggestion
here
around
these
negative
values
is
we
we
need
to
make
sure
users
get
it,
but
we
also
don't
want
to
overload
them
with
log
messages,
so
you
should
definitely
not
log
every
event
if
it's
possible
for
us
to
log
the
first
event,
maybe
that's
useful
too,
but
the
key.
C
Yeah
anyway,
so
the
java
sdk
has
a
throttling
logger.
We
can
just
pull
in
for
this
use
case.
If
dot
net
doesn't
I'd,
recommend
adding
it.
G
So
that's
an
option
josh,
but
I
think
there
was
another
concept
that
we
defined
for
tracing,
which
we
may
want
to
use
in
metrics,
which
is
the
error
handling
thing.
So
I
think
there
was
a
in
the
specification
for
trace.
There
is
a
error
handler
definition
that
we
can
have
and
allow
users
to
do
whatever
they
want,
with
the
errors.
C
All
right,
so,
let's
defer
that
question,
because
I
think
that
question
might
be
bigger.
Let's
split
this
into
two.
So,
first
off,
do
we
want
to
allow
monotonicity
in
v1
bogdan
proposed
that
it's
not
needed
for
v1?
We
can
add
it
in
v2,
and
we
know
that
there's
this
weird
issue.
If
we
do
allow
it
do
we
want
to
just
remove
it
from
v1
or
do
we
want
to
keep
it
yeah
or
nay,
yeah.
H
A
So
my
vote
would
be
yes,
I
think.
Even
if
we
don't
solve
the
problem
today
tomorrow,
it
will
be
the
same
problem.
It
won't
get
simpler
and.
D
C
D
C
D
A
A
G
So
I
think
that's
that's
a
very
bad
decision,
because
the
reason
is
if
we
don't
define
the
behavior,
every
sdk
will
do
their
own
behavior
and
changing
that
behavior
will
be
a
backwards
and
compatible
change.
A
G
G
A
C
C
So
it
depends,
I
actually
don't
see
it
as
being
something
we
will
need
right
now.
C
The
only
thing
that
has
me
nervous
about
this
is
the
duration,
so,
but
I
think
we're
okay,
so
here's
here's
here's,
my
thinking,
the
histogram
instrument
is
monotonic,
the
counter
instrument
is
monotonic
up
down,
counter
is
non-monotonic
and
gauge
is
non-monotonic
right
and
sorry.
Oh
I'm
also.
Some
observer
is
monotonic
and
up
down
some
servers
non-monotonic.
C
So
we
have
a
bit
of
a
weird
display
there,
but
I
actually
think
that
this
is
okay.
So,
for
two
reasons,
one
it's
easy
for
users,
I
think
to
pick
the
instrument
that
leaves
the
monotonicity
they
want
in
instrumentation.
C
So
we
only
are
worried
about
instrumentation
authors,
picking
the
wrong
thing
where
I
think
people
are
having
trouble
today
is
picking
up
down
counter
versus
gauge,
not
picking
counter
verses
or
counter
or
histogram
versus
up
down
counter.
If
that
makes
sense,
so
the
likelihood
that
we
see
the
problem,
I
think,
is
a
little
bit
low
because
most
of
the
things
that
we're
doing
right
now
are
monotonic,
so
it's
not
a
big
deal.
C
The
second
thing
is
a
lot
of
times
when
users
do
that
override
they're,
actually
doing
so
in
their
queries
in
the
back
end,
so
they'll
query
a
set
of
metric
data
and
and
in
the
query,
they're
implicitly
saying
how
to
interpret
some
of
the
results
of
the
things
that
pull
in.
C
So
that's,
basically,
why
I'm
kind
of
comfortable
not
supporting
the
use
case
directly
in
the
sdk,
because
the
odds
that
the
user
needs
to
deal
with
in
the
sdk
are
quite
low.
I
think,
and
if
we
have
trouble
with
instrumentation
authors,
picking
the
wrong
instrument,
we
have
a
different.
We
need
to
also
solve
that
problem.
A
C
You
won't
yes.
What
I'm
suggesting,
though,
is
that,
even
if
you
have
a
valid
workaround
now
we
still
want
the
user
to
open
a
bug
against
instrumentation
author
and
get
it
fixed
upstream.
C
The
instrumentation
is
getting
built
out
now,
so
the
odds
that
the
instrumentation
author
gets
it
wrong,
that
you
can't
fix
it
with
queries
and
that
you
have
to
do
in
the
sdk,
I
think,
are
rather
low.
That's
all
it's
not!
This
is
about
a
prioritization
thing.
It's
not
that
I
don't
think
this
is
valuable.
I
just
think
it's
way
low
on
my
list
of
use
cases
to
support
right
now.
Let's
see.
A
A
G
It
so
so
let
me
explain
so
the
the
biggest
difference
between
monotonic,
sound
versus
non-monotonic
sound
for
for
some
of
the
backends
is
the
fact
that
you
can
see
the
rate
of
increase,
and
in
this
case
in
this
case,
you
will
never
want
to
see
a
rate
of
increase
of
temperature,
because
temperature
will
still
go
up
and
down
no
matter
what
it
will
never
go
only
up,
so
so
even
for
gauge,
so
so
for,
for
a
gauge,
for
example,
think
about
a
gauge.
G
G
This
this
at
most
can
be
a
sum
instead
of
of
of
a
gauge,
if
I
know
that
it's
calculated
with
as
a
sum,
but
there
is
no
easy
way
to
know
that
it's
always
going
up
in
this
case,
because
because
in
case
of
a
gauge
which
is
an
which
is
an
async
instrument,
you
need
to
have
to
report
only
monotonically
increasing,
not
only
positive,
but
only
monotonically,
increasing
values.
For
that
it's
going
to
be
super
hard
to
have
that
piece.
A
Yeah
yeah,
I
see
a
point.
You
actually
bring
something
interesting
to
me.
I
I
think,
can
I
like
flip
the
conversation
say
if
we
allow
people
to
configure
that,
then
we
probably
would
even
encourage
bad
behavior
that
some
library
developers
say
like
it's
hard
to
pick
this
instrument
I'll
just
pick
everything
as
gauge,
and
you
guys
configure
what
you
want
and
that
that
worried
me.
A
Okay,
so
it
seems
like
like
here
like
bogdan
josh.
Our
consensus
is
that
we
should
not
allow
that
in
the
initial
version.
E
E
E
G
E
Yes,
I
understand
for
temperature,
it
doesn't
quite
make
sense,
I'm
just
thinking
and
I'm
just
making
this
up,
but
if
you
wanted
to
do
like
a
cumulative
some
like
a
integral
of
what
you
just
constantly
add
yeah,
I
don't
know
if
that
makes
sense,
but
but
my
general
question
is
outside
of
that.
The
question
general
in
the
abstract
is,
if
you
had
an
instrument
that
was
non-monotonic
and
you
convert
it
to
an
aggregation
that
is
purely
monotonic,
then
I
assume
the
default
would
be
just
to
drop
the
non-monotonic
value.
C
So
I
think
it'd
be
better.
I
I
think
maybe
we
we've
beaten
this
to
death
just
as
an
fyi,
so
I'd
like
to
table
this
discussion
now,
so
that
we
can
move
on
to
the
next
two
things.
But
to
answer
your
question:
let's
come
at
it
with
specific
examples
like
when
you
try
to
think
of
this
abstractly,
it's
very
very,
very
hard.
C
So
if
you
think
about
actually
using
sums
in
in
a
metric
database
and
like
how
you
would
query
them
and
look
at
it
end
to
end,
I
think
that
will
help
answer
that
question
until
we
really
have
a
reason
to
convert
from
an
instrument
that
is
inherently
not
monotonic
to
a
monotonic
aggregation
until
we
have
a
really
good
use
case.
For
that,
I
think
we
should
just
table
it
effectively
like.
I
don't
think
it's
necessarily
going
to
give.
C
J
J
J
So
I
think
that's
the
real
world
example,
but
victor
you
just
asked
the
question
that
you
said
I
don't
know
if
it
makes
sense,
I
think
it
doesn't
make
sense
unless
you
do
a
time
weighted
computation
there.
So
supposing
you
have
a
gauge
which
is
current
power
usage,
you
should
be
able
to
sum
that
into
something
cumulative
but
you're
going
to
have
to
average
take
the
average
difference
since
your
last
measurement
and
kind
of
do
some
math
to
compute
your
cumulative.
J
G
But
but
the
usage,
then,
why
is
not
that
the
sun.
J
But
instead,
what
we're
going
to
do
is
we're
going
to
sample
the
gage
value
once
per
second
and
we're
going
to
multiply
one
percent,
one
second
of
usage
and
sum
it
up.
But
in
reality
you're
going
to
take
the
measurement.
You
know
every
30
seconds
and
so
you're
going
to
multiply
30
times
the
current
value
and
then
the
next
30
seconds
you're
going
to
measure
30
times
current
value
and
that's
what
you're
summing.
G
J
Right
and
that's
and
that's
actually
what
we
said
on
tuesday,
the
same
things
came
up
like
this
is
a
query.
If
you
want
to
convert
a
gauge
into
accumulative,
do
do
a
query
take
time
into
account
because
it's
important
and
don't
do
it
in
the
sdk.
I'm
sorry.
I
was
trying
to
say.
C
C
What
I'm
suggesting
is,
if
I
were
to
say
sum
if
I
were
to
say
aggregator
equals
sum
with
monotonicity
of
of
monotonic
right,
then
I
actually
get
the
wrong
value.
I
would
actually
have
to
customize
my
aggregator
to
get
the
correct
value
in
that
use
case.
So
even
then
we
don't
have
a
use
case
for
taking
the
gauge
and
turning
it
into
a
sum
without
some
custom
aggregation
going
on.
Okay,.
E
So
then
my
ask
is
that
it
sounds
like
there's
a
in
the
view,
api
or
aggregation
one
or
the
other.
There
are
limits
in
terms
of
what
people
could
configure
the
view
on
based
on
your
instrument
type.
Should
we
put
a
table
up
that
says
if
your
instrument
is
this,
these
are
the
available
aggregation
and
such.
C
E
C
You
get
yeah,
you
would
get
a
non-monotonic
sum
right
or
an
up
down
sum
right.
Like
that's,
that's
fine,
so
you
can
still
use
sum
as
an
aggregator.
You
just
get
a
non-monotonic
sum
as
opposed
to
a
monotonic
sound.
A
C
Yeah,
since
I
ran
into
it
with
the
the
most
recent
java
pr
to
implement
views
I'll
I'll,
attach
it
to
the
java
pr
to
say,
like
we
don't
support
this,
can
we
remove
from
the
spec
and
open
a
bug
or
open
a
pr
against
the
spec.
A
C
Yeah,
so
the
status
on
my
end
is:
it
needs
more
reviewers.
I
think
there's
some
good
comments
and
there's
a
bunch
of
spelling,
I'm
embarrassed
by
never
spelling
mistakes.
I
need
to
go
fix
all
those
and
get
it
refreshed.
I
think
there
was
one
there
was
one
comment
that
needs
a
little
bit
of
thought
that
I'll
try
to
get
to
later
today
and
have
that
up
to
date,
so
friday
should
be.
It
should
be
in
final
form
to
either
merge,
or
you
know,
comment
to
hell
one
to
two.
A
C
I'm
all
on
board
for
experimental
release
by
the
end
of
the
month
and
by
friday
I
think
exemplar.
The
only
comment
was,
I
think,
easy
to
resolve,
so
yeah.
Getting
it
in
by
friday
should
be
easy.
The
metric
reader
api
is
great.
Are
you
planning
to
do
a
multi-exporter
pr
that
talks
about
how
to
configure
multiple
exporters.
A
C
Okay,
and
so
experimental
doesn't
include,
if
experimental
doesn't
include
multiple.
I
think
it's
totally
reasonable
to
get
something
out
by
the
end
of
august.
I
really
really
really
really
want
a
fast
follow
with
multi-exporter
and
if
you
want
I'm
happy
to
try
to
write
that
specification
as
well.
While
I
wait
for
more
feedback
on
exemplar.
F
Can
I
have
a
quick
question
here?
What
do
you
mean
by
like
an
experimental
release
like
an
experimental
release
of
what
is
it
the
sdk,
the
sdk.
F
A
A
F
A
F
Improvements
will
make
it,
but
I
know
I
know
it's
in
feature
freeze
right
now.
My
question
is
that,
like
I,
as
far
as
I
remember
in
the
latest,
like
metrics
api
timeline
update,
there
was
a
goal
for
being
stable,
like
the
api
spec
being
stable
by
the
end
of
this
month.
A
A
A
Yeah,
so
on
tuesday,
I
plan
to
talk
about
this.
This
is
the
feedback
from
the
matrix
sig
and
we
want
to
shift
the
experimental
version
of
the
icky
and
we
also
want
to
see
if
we
should
mark
the
api
stable
or
we
should
just
give
some
more
time
because
it's
a
little
bit
like
we
haven't
done
this
before
it's
a
little
bit
rare
to
have
the
api
stable.
While
the
sdk
is
still
a
very
early
stage.
A
I
think,
like
people
probably
would
be
more
confident
if
you
say
the
sdk
is
feature
freeze
and
the
api
is
stable
but
I'll
cover
that
on
next
tuesday.
Thank
you
so
just
to
come
back.
I
I
think,
exemplary
pr.
Let's
try
to
solve
that
by
end
of
this
week
and
for
the
metric
reader
pr,
I
need
more
review
and
and
I'll
I'll
try
to
quickly
respond
to
any
questions
here
and,
let's
see
if
we
can
catch
the
august
release
flash
and
for
the
multi-exporters.
A
The
current
isdk
spec
mentioned
the
scenario
where
we
want
to
allow
multiple
exporters,
but
we
we
didn't
spec
out
how
multiple
exporters
should
be
supported,
and
I
guess
there's
a
something
we
might
want
to
do
in
ict.
Can
I
explain
how
we
can
allow
multiple
metric
reader,
but
regarding
how
each
language
should
implement
that?
I
I
think
this
is
out
of
scope,
so
I'll
try
to
find
some
balance,
but
the
message
here
is:
I
I
think
this
is
out
of
scope
for
the
experimental
release.
C
So,
in
terms
of
quick
process
check
on
stability
and
experimental,
and
all
that
kind
of
junk
was
one
of
the
one
of
the
things
we
want
to
do
with
the
specification
going
forward
before
we
mark
the
spec
is
stable.
C
C
A
good
example,
actually
is
the
discussion
we
just
had
around
monotonicity
in
the
specification,
but
we
added
it
in.
We
tried
to
implement
it
and
then
we're
removing
it
right.
So
another
way
to
rephrase
the
question
about
making
the
api
stable.
C
A
I've
been
watching
closely
on
the
donut
part
and
I
also
reviewed
multiple
pr's
on
the
python
part.
So
so
far,
that
part
seems
to
be
good
to
me.
I
took
a
bit
look
at
the
java
prs,
but
not
too
deep
into
that
and
for
go.
I
never
touched
that
part.
So
that's
my
update
and
based
on
what
I'm
saying,
I
think
my
understanding
is
like
donet
and
java
they're
very
similar.
So
if
donet
could
do
it,
then
by
default
I
assume
java
will
do
it.
A
A
C
I
I
think
I
will
at
least
raise
it
as
a
topic.
I
don't
know
if
joshua
didn't
have
more
specifics,.
G
Yeah,
I'm
happy
to
review
go
in
java
whenever
you
feel
it's
ready.
J
J
The
names
of
the
instruments
have
not
changed
from
the
old
prototype
and
we're
trying
to
not
make
a
like
drip
drop
of
changes
for
users
who
have
adopted
the
api
already
so
the
moment
I've
just
been
working
on
the
sdk.
My
belief
is,
and
I'd
like
someone
else
to
corroborate
or
just
verify,
is
that
the
sdk
basically
met
the
requirements
already
other
than
the
naming
of
the
instruments
and
what
I
really
want
the
go
go
sig
to
do
is
to
evaluate
that
api,
which
I
don't
think
we're
happy
with.
J
So
what
I'm
seeing
is
that
the
sdk
is
very
close
and
we've
been
working
on
that,
while
leaving
open
room
to
to
change
the
api,
and
my
work
has
been
focused
on
factoring
the
sdk
to
allow
that
there
is
a
draft
api
available,
and
I
think
that
we're
not
going
to
accept
the
old
prototype
api
even
with
renamings,
you
know
of
value
or
quarter
to
histogram.
J
L
No,
I
think
you
said
the
right
thing.
I
would
probably
say
the
same
about
the
current
state
of
metrics.
I
think
he
did
a
good
job.
The
tracing
site
is
still
a
work
in
progress.
Well,
it's
a
close
to
done
work
in
progress,
but
still
in
progress.
C
So
tyler
is
this
an
issue
where,
if
you
had
had
a
better
chance
to
get
feedback
on
the
spec,
the
work
could
have
progressed
quicker
onco
like
was
there
a
lot
of
post
post
1.0
feedback
that
you
wish?
You
had
gotten
in
just
curious.
C
The
questions
on
on
tracing
like
around
you
know
that,
like
there's
been
a
there's
been
a
time
that
that
goes
been
trying
to
come
up
to
speed
right
with
the
1.0,
and
I
know
that
the
split
of
tracing
and
metrics
hit
go
a
lot
harder
than
other
languages.
So
I
understand
that
what
I'm
asking
is,
do
you
feel,
like
you,
had
enough
feedback
prior
to
your
1.0
on
the
tracing
spec,
or
would
you
have
appreciated
like?
Did
you
need
more
time
to
to
open
issues
against
the
spec.
L
I
that's
a
good
question.
I
don't
think
so.
I
I
think
that
what
we
found
was
subtleties
and
details,
but
overall,
like
we
were
able
to
get
something
out.
I
mean
that
being
said.
L
There
are
certain
elements
of
the
tracing
api
and
sdk
that
are
not
really
idiomatic
of
the
language
and
there
may
be
better
like
design
choices
if
we
could
have
changed
some
language
in
the
spec.
But
I
it's
it's
honestly.
It's
so
much
more
subjective
at
that
point
as
to
like
what
people
actually
think
is
idiomatic.
So
I
don't
know
if
that's
really
a
point
to
you
know
land
on
as
a
definer.
L
I
do
know
that
we
did
find
a
bunch
of
small
bugs
in
in
some
parts
of
the
specification,
but
nothing
I
think
that
was
a
show.
Stopper,
I
think
was,
was
how
it
ever
serves
me.
A
Okay,
moving
to
the
next
one
bogdan.
So
what's
the
use
case
for
false
flash,
I
I
think,
regarding
the
name
is
trying
to
align
with
the
traiting
and
regarding
the
scenario,
imagine
you
have
an
application
and
you
have
some
asynchronous
instruments.
That's
trying
to
collect
information,
and
also
you
have
the
synchronous
instruments
to
report
the
request
thing
and
you
keep
reporting
the
data
to
the
back
end
every
one
minute
and
now
you
know
the
application
is
trying
to
shut
down,
and
you
want
to
report
something
before
you
exit.
A
Instead
of
saying
I
still
got
like
10
requests.
I
haven't
reported
I'll,
just
drop
the
data
so
force
flash.
Gives
you
a
chance
to
report
that,
through
the
push
expire
for
poor
exporter,
that
wouldn't
make
sense,
so
either
you
get
an
error
saying
false
flash
won't
work
for
you
or
it
will
just
be
no
off.
A
Yes,
I
agree,
so
that's
why
it's
confusing
I
see
so
my
thinking
is
clocked
is
the
api
on
the
metric
reader,
but
on
meter
provider
there
has
to
be
something
and
I'd
rather
call
it
force
flash,
because
it's
either
from
the
user
perspective
when
they,
when
the
c
matrix
traces
logs,
they
just
call
flash.
They
know,
like
all
the
previous
data
I
have
is
done
instead
of
they
have
to
mentally
distinguish.
Oh
for
traces,
I
have
used
flash
for
matrix,
I
have
to
use
collect.
A
I
totally
understand
that,
and
you
can
see
it's
a
little
bit
like
mix
match.
Another
thing,
I'm
thinking
is
the
clocked
function,
as
I
put
in
the
comment
it
might
solve.
Other
problems
like
give
you
the
option,
whether
you
want
to
just
trigger
the
collection
on
the
asynchronous
instruments
without
triggering
the
consumption
logic
or
you're.
Saying
just
give
me
everything,
including
the
asynchronous
callback
results
and
then
call
the
exporter
or
do
something
so
so
the
flow.
A
A
No,
no
reader
is
something
the
provider
allows
allows
developer
to
attach
to
so
it's
like
you
can
you
can
have
a
provider,
you
can
see,
add
meter
and
and
then
you
can
see,
add
view
and
then
you
can
see.
I
the
reader
and
once
the
reader
is
added,
the
provider
will
notify
the
reader
when
people
call
force
flash
or
shutdown
and
the
reader
will
will
give
clock,
so
people
can
call
reader
clock
and
they
will
like
two
of
them
would
interact
with
each
other.
G
So
and
how?
How
is
the
connection
happening
between
this
reader
collect
and
the
sdk,
because
it
seems
to
me
it
seems
to
me
that
collect
has
to
be
on
the
on
the
on
the
on
the
instance
that
owns
the
data.
So
so
here
is
maybe
maybe
maybe
some
some
example
code
in
some
of
my
comments
to
show
me
where
exactly
you
see
so
so,
if
I'm
calling
collect
okay
collect
is
a
thing
on
the,
inter
on
the
instance
on
the
meter,
a
metric
reader
instance.
G
A
G
Are
two
different
instances?
One
is
the
trace
provider
instance
and
the
other
one
is
the
metric
reader
instance.
There
are
two
objects,
two
instance
of
these
objects:
okay,
yeah,
when,
when
I
call
collect
on
one
of
the
object,
which
is
the
the
the
the
meter
provider
object,
the
data
are
in
the
trace
provider,
object.
How?
How
are
the
data
flowing.
A
A
A
A
A
A
G
A
A
I
see
your
point
so
you're
saying:
if
the
vendor
wants
to
implement
their
own
meeting
provider,
how
they're
going
to
do
that
right,
correct
yeah,
I
would
say
like
yeah,
so
my
answer
is
you
need
to
remember
the
reader
and
you
do
whatever
you
want.
Just
call
the
the
metric
readers
call
back,
providing
the
data,
how
you
store
the
data,
how
you
implement
the
callback
is
your
problem:
okay,.
K
Let's,
let's
take
it
offline,
yeah,
okay,
okay,
cool
bye,.