►
From YouTube: 2022-04-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).
A
Yeah,
hey,
I
had
to
jump
out
myself
from
being
I
love
when
organizers
go
over
and
they're
just
like,
we
can
stay
for
an
extra
10
minutes
like
oh,
I
can't
you
can
yeah.
A
I
know
okay,
well,
cool
yeah
thanks
for
joining.
I
guess
you
guys
also
saw
that
anthony
can't
make
it
until
the
back
half.
I
don't
know
if
we'll
be
here
that
long,
I
hope
not.
I
hope
it
takes
five
minutes
and
we
all
have
a
really
good
idea
of
what
we
want
to
do,
but
I
don't
anticipate
that
happening,
but
yeah
so
josh
just
to
kind
of
bring
it
up
to
speed.
A
So
we
created
a
project
boards
and
milestone
to
track
the
metric
sdk
development
work
in
the
alpha
release,
specifically
around
like
breaking
apart
the
example
branch
that
you
and
aaron
have
been
working
on
into
digestible
steps.
So
it's
not
just
like
a
massive
pr
as
well
as
like
you
know,
you
can
see
components
so
essentially
like
build
implementations
and
I'm
sorry
builds
like
interfaces
and
then
implement
those
interfaces
essentially
and
we're
doing
that
in
our
own.
A
Like
feature
branch,
I'm
guessing,
I
might
be
saying
things
already
know,
but
so
in
the
process
you
know
I
broke
up
a
bunch
of
different
things
into
their
own
tasks
and
I've
put
in
a
few
pr's
and
put
in
a
fpr's
to
clean
things
up
and
so
we're
kind
of
just
going
over.
Well,
I
guess
you
could
say
we're
in
the
weeds
at
this
point
because
we're
we're
digging
into
it.
A
A
One
thing
I
did
want
to
accomplish
in
this
meeting-
and
I
just
kind
of
like
maybe
run
it
by
you-
was
to
get
this
initial
draft
of
the
meter
provider
merged
yeah,
and
so
maybe
we
could
just
kind
of
start
here
and
just
see
what
you
all
feel
about
it
there's.
Definitely
there
are
some
changes
and
it
kind
of
gives
you
like
an
overview
of
like
what
I
was
anticipating
to
break
this
down
as
so.
Essentially,
this
is
just
creating
a
skeleton.
A
There's
there's
like
this
config.
That
is
unimplemented.
It's
also,
you
know,
I
don't
know
if
we
need
to
export
this
or
not,
but
right
now
it's
just
unexported
totally
anticipating.
If
we
need
to
fix
that
we
can,
we
can
change
it
in
the
future,
but
then
you
know
breaking
up
at
the
meter
breaking
apart
the
meter
provider.
Here,
it's
essentially
just
saying,
like
you
know,
here's
what
to
do.
Here's
the
issue,
that's
tracking,
the
actual
implementation
and
here's
how
you
know
the
whole
structure
is
going
to
look.
A
One
of
the
significant
changes
is
the
initial
example.
You
know
name
this
provider.
I
named
this
meter
provider
to
match
the
tracing
signal
as
well
as
the
yeah.
You
know
it's
naming
it's
also
not
final.
You
know
we're
not
merging
this
in
tomorrow,
but
essentially
match
the
tracing
and
to
match
the
specification.
A
This
also
implements
the
other
required
methods
by
the
specification.
This
flash
is
shut
down
at
the
meter
provider
level,
and
then
this,
I
think,
is
the
exact
same
as
what
was
in
the
example
pr.
A
So
maybe
I'll
just
like.
I
don't
know
if
you
guys
want
to
just
like
spend
some
time
afterwards
reviewing
this
or
we
can
kind
of
go
over
details
here,
but
you
know
it's
mostly
just
talking
about
comments.
I
think,
are
the
thing
that
we're
reviewing
in
this
pr,
more
than
anything,
just
to
kind
of
like
make
sure
that,
like
we
all
have
the
same
conceptual
understanding
of
what
this
is
going
to
do.
You
know,
namely
this
method
has
to
be
called
concurrently.
A
B
B
I
know
the
it
makes
it
a
lot
easier
to
call
to
set
up
a
call
structure
if
we
automatically
return
a
meter
sort
of
the
must
pattern
from
prometheus,
but
I
have
not
had
chance
to
to
review
the
comments
if
you
want
to
take
five
or
ten
minutes
just
kind
of
read
through
them,
and
and
do
it,
I'm
I'm
more
than
happy
to
to
set
this
a
time
aside
to
do
that.
If
you,
if
that's
what
you
want.
A
Yeah
I'm
open
for
anything.
You
know
I
would
like
anthony
to
be
a
part
of
the
reader
discussion.
It
does
kind
of
put
us
in
a
bad
position
if
we
only
have
half
an
hour,
though
so
I
guess
josh.
What
are
your
thoughts
on
this.
C
I
hadn't
looked
over
this
pr,
specifically
22.
I
will
just
confess,
being
kind
of
slammed
with
a
few
life
things
and
a
vacation,
and
so
I
didn't
have
enough
high
level
picture
of
all
the
different
pr's
so
that
it's
kind
of
been
like
I've
been
feeding
work
to
aaron
and
talking
about
him
with
it
with
him
and
not
at
all,
paying
attention,
unfortunately,
to
the
group-
and
I'm
sorry
for
that.
So
I
that's
all.
I
have
yeah.
A
That's
that's
good
feedback
and
I
don't
know
I
don't
want
to
I'm
so
versatile
as
well.
C
Well,
I'm
trying
to
get
out
of
the
way
I
feel
like
a
burden
and-
and
just
having
me
just
saying
directly
like
do
this
one
first.
Is
it
the
kind
of
feedback
I
could
use
like
sorry,
because
I
haven't
been
paying
enough
attention
trying
to
again
here.
A
Right,
well,
I
mean,
if
that's
the
case
like
the
thing,
the
real
thing
that
I
really
want
to
get
out
of,
you
is
to
better
understand,
thought
process
on
the
reader
package
structure,
as
well
as
views
and
to
kind
of
like
dive
into
that.
So
we
can
just.
C
I
think
that
would
be
the
most
useful
way
to
spend
the
time,
even
if
we
end
up
reiterating
it
with
anthony.
I
know
that
that's
been
how
aaron
and
I
have
spent
a
lot
of
our
discussion
time
as
well.
I
will
just
I
remind
everyone.
I
know
I
tell
this
to
aaron
more
than
once
a
week,
but
like
I,
I
don't
have
appetite
for
debate
anymore
on
this
stuff,
especially
at
some
level.
To
me,
I'm
I'm
I'm
over
it.
C
I
want
this
all
to
be
implementation
details,
so
I
will,
I
will
agree
to
anything
and
enthusiastically
I
I
have
I'm
sort
of
so
in
the
in
the
trees
or
the
forest
that
I
can't
see
them
anymore.
So
a
lot
of
erin's
feedback
has
been
really
helpful
because
I
can't
see
or
feel
these
distinctions
anymore.
It's
just
been
a
long
time,
so
I
I
didn't
get.
I
did
pass
my
water
test,
but
I
didn't
get
my
branch
put
into
github,
where
you
could
easily
see
it.
We
had.
C
We
had
been
iterating
at
least
three
times
last
week.
I'm
like
okay
aaron
doesn't
like
what
I
did
for
good
reasons.
Now.
I
understand
that
I
will
fix
it,
so
I
can
keep
doing
that
with
aaron,
but
I'm
glad
that
you're
also
investigating
tyler.
So
if
you
want
to
just
talk
about
the
reader
problem,
I
will
follow
and
try
to
do
or
help
or
comply
or
whatever
you
know.
C
A
Yeah
sure
that
sounds
good,
so
yeah
kind
of
on
the
background
on
this
one.
I
totally
get
the
burn
out
on
discussion,
especially
the
wild
journey
that
the
metrics
api
or
metric
specification
has
taken
over
the
past.
I
guess
two
years
now.
I
definitely
understand
that
so
yeah
like
if,
if
that's
the
case,
I'm
really
also
just
kind
of
like
looking
for
to
glean
your
insight
through
experience
and
to
pull
in
you
know.
I
know
you
have
a
lot
of
experience
in
this
field
and
so
like.
A
I
want
to
understand
some
things
here,
but
the
key
thing
here
is
like
I
was
starting
to
look
at
this
new
example
branch
and
in
the
reader
package.
I
was
noticing
well
there's
a
few
things
that
just
looked
odd
to
me,
and
so
I
wanted
to
kind
of
like
think
through
them
a
little
bit.
One
of
the
things
was
like
there's
like
this
whole
there's
a
lot
going
on
in
here,
which
I
think
could
get
broken
up,
but
I
really
think
it's
key.
We
just
focus
on
this.
A
This
is
kind
of
like
the
the
crux
here
like
these
three
interfaces,
this
registry-
it's
like
only
used
here.
We
could
probably
merge
the
two
if
we
wanted
to
use
it,
but
this
whole
registration
process.
That's
the
kind
of
thing
that
I
was
like
you
know,
there's
a
lot
of
complexity
here
and
it's
complexity
like
and
including
you
know,
introducing
interfaces
that
are
not
in
the
specification
to
try
to
accomplish
this
and
then
on
reading
the
specification
I
find.
I
think
that
there's
a
I
think
there
was.
A
There
was
a
direct
implementation
in
the
specification
that
wasn't
really
thought
through
and
the
language
of
it,
I
think,
is
a
little
bit
vague
and
I
think
that
people
kind
of
just
filled
in
the
details
with
what
was
going
on,
and
so
the
problem
that
I
see
is
is
that
one.
A
There
is
a
strong
statement
in
the
specification
which
I
can
pull
up
really
quick,
but
it
says
that
the
metric
reader
can
only
ever
be
associated
with
a
single
meter
provider,
and
I
I
don't
know
how
you
can
enforce
that
other
than
in
the
implementation
of
the
reader,
which
then
it's
like.
I'm
not
exactly
sure
why
that
was
included
either.
I
think
it
was
just
like
a
a
detail,
but
it
seems
odd.
I'm
sorry,
let
me
see
if
I
can
find
it.
A
A
Right,
but
I
I
feel
like
it,
this
isn't
it
yeah.
It
opened
the
door,
though,
because
it
says
that
like
sdk
must
not
allow
the
metric
creator
instance
to
be
registered
with
more
than
one
meter
provider.
It's
like,
like
I
don't
know
like
that.
Just
seems
like
okay
cool
now,
each
meter
provider
instance
that
we
like
decide
to
like
have
implement
this
meter.
Reader
like
we
have
to
go
and
control,
but
then,
like
you,
know
like
this,
goes
back
to
like
what
happens.
A
So
do
you
need
like
a
global
to
track
the
state,
and
it
just
seems
like
I
don't
know
like
I
asked
around
in
the
slack
channel
java-
is
not
doing
this,
although
riley
thinks
that
they
are
doing
this
because
they
have
a
builder
pattern
and
it
looks
like
c
plus
plus
is
doing
some
like
encapsulation
with,
like
you
know,
a
protected
pointer
space
that,
like
only
the
meter
provider,
can
control
and
that
they're
like
transferring
that
pointer
across
this.
A
Like
memory
boundary,
it
sounds
like
python's
not
doing
this
ruby's,
it
doesn't
sound
like
they're
doing
this.
So,
like
I
don't
know
how
effective
this
is
a
part
of
the
specification,
but
it
got
me
thinking
you
know
like
this
is.
B
Actually
done
problems,
I
actually
don't
think
that
we
are
particularly
doing
this
other
than
the
fact
that
if
you
call
register
more
than
once
in
the
current
produce
or
the
current
metric
readers,
the
the
three
that
we
have
created
it
just
replaces
the
meter
provider
or
the
producer
interface.
Oh.
C
B
B
Yeah
the
whole
registration
process
that
that
we
put
into
this
example
came
about
because
there
is
a
complex
interaction
between
adding
instruments
and
how
they
interact
with
essentially
like
going
through
the
views
and
being
added
to
the
appropriate
metric
readers
right
right
slice
of
things
and
if
we
need
to,
if
we're
going
to
delay
where
it
gets
the
product,
the
the
metrics
from
like
it
needs
to
have
some
way
of
updating
that,
like
a
metric
reader,
needs
to
have
some
way
of
updating
it.
B
A
I
that's
exactly,
I
think,
where
I'm
coming
at
this
and
asking
like
is
this.
Is
this
the
right
design
and
I
think
the
specification
like
asserts
that
it
is,
but
I
don't
know
if
it
like?
It
is
because
I
think
that,
like
you
read
through
it
the
first
time,
you
think
there's
this
registration
pattern,
but
you're
right.
There's
like
this
like
integrated
like
back
and
forth
of
like
well,
what
happens
when
new
views
are
added
which
currently,
like
that's,
not
possible,
but
like
even
then
like
what
happens
new
instruments?
A
A
Well,
we
have
this
like
interface
with
this
register
method,
but
really
you
have
like
a
reader
that
needs
to
know
how
to
get
a
produced
set
of
metrics
from
a
meter
provider
at
the
end
of
the
day
right
and
that's
kind
of
like
where
I'm
asking
these
like
questions
of
like
well,
like
you
know
like
you,
can
just
make
this
a
type
but
like
a
struct
directly,
and
then
you
don't
have
to
worry
about
any
sort
of
like
registration,
because,
like
each
implementation
of
a
reader
would
know
what
to
do
with,
like
all
of
these
things
and
just
the
media
provider
would
provide
some
sort
of
api,
which
we
kind
of
talked
about
here,
where
it's
just
like.
A
You
know,
the
provider
provides
some
sort
of
produce
method,
and
you
know
I
think
if
that
would
work
and
like
aaron
kind
of
pointed
out,
I
was
like
well
yeah
like
that
would
work,
but
it's
also
like
it
doesn't
need
to
know
about
the
meter
provider
just
needs
to
know
about
the
views
and,
like
the
view,
compiler
really
and
so
like.
That's
where
a
lot
of
this
like
question
came
in
is
like
is
this?
Is
this
inverted
like?
A
Do
we
have
this
registration
method
like
inverting,
the
actual
control
flow
of
the
whole
reader
pipeline?
I
guess
is
the
question.
B
Yes,
like
the
thing
about
it
comes
down
to
is
yes
and
no
right,
it's
inverted,
but
it's
still
not
like.
We
can't
just
uninvert
it
and
get
it
to
straighten
out
because
of
the
fact
that
the
reader
is
actually
where
the
control
starts.
And
then
it
flows
back
through
to
the
reader
again
at,
like
the
reader
says,
go
collect
data
and
then
the
control
has
to
pass
back
to
the
reader.
To
say.
Give
me
that
data
right.
A
And
like
yeah,
and
I
get
that
and
then
there's
like
this
periodic
thing
that
is
like
it
kind
of
throws
the
wrench
in
the
whole
thing
right,
because
I
I
definitely
see
you
could
you
could
structure
a
reader,
something
like
this
right,
where
it's
flush,
flushes
shut
down
whatever,
but
like
this
collect
method,
is
a
wrapper
around
some
sort
of
produced
callback
right,
like
the
you
know,
you
get
the
the
creation
of
this
reader
and
that
reader
gets
a
meter
provider
or
a
views
compiler.
A
You
know,
depending
on
how
you
want
to
say,
and
the
view
compiler
says,
like
here's
a
function,
call
this
whenever
you
want
to
get
metrics
and,
like
you
know,
anytime,
that
this
collects
is
directly
called
it
just
it
just
calls
that
right.
This
yeah,
this
back
and
forth,
gets
a
little
weird
when
you
get
the
periodic
where
it's
like
yeah.
A
You
can
still
call
this
collect,
but
also
periodically
sent
to
this
exporter,
and
I
think,
like
you,
can
have
this
manual
reader,
not
essentially
like
not
have
an
exporter
associated
with
it
like
it
will
just
hand
you
back
these
these
metrics
and
then
for
this
reader.
You
can
say,
like
okay,
I'm
going
to
wrap
that
in
something
that
pipes,
those
calls
periodically
to
some
sort
of
interface,
that's
called
an
exporter,
and
I
think
that
you,
you
do
disentangle
it
because,
like
that,
that
call
where
it
goes
like.
A
A
B
And
where,
where
I
landed
on,
that,
is
that
reader,
what
you
call
a
reader
is
the
manual
reader
in
the
example
and
there's
an
actual
interface
there.
That.
A
Well,
it's
a
yeah,
I
mean
it
is
it's
it's
it's
similar,
but
the
problem
is.
It's
also
got
this
external
thing
where,
like
the
collects
methods
of
the
two
different,
you
know
the
periodic
manual
reader
or
the
new
reader
as
I'm
calling
it
here
like
this
is
they're
different
because
they
don't
have
to
sell
the
same
problems
like
in
one.
You
may
want
to
pass
this
type
to
actually
have
your
return
values
associated
with
it
or
have
an
optimization
in
memory,
but
the
other
one.
That's
not.
A
It
may
not
be
the
case
right
and
if
it
is
the
case,
you
can
implement
that
internally
and
you
don't
need
the
same.
Call
signature
here
which
screams
to
me
like
they're,
two
different
use
cases.
One
is
a
push
and
one's
a
pull.
You
know
method
and
the
interface
is
not
getting
like
you
you're
overloading
the
interface
for
things
that
like
in
some
cases,
are
not
going
to
be
relevant
and
other
cases
are
like.
What's
the
point
like
why?
Why
do
that?
A
If
you
don't
need
to
have
an
interface
there
like
there's
nothing
in
the
specification
that
says
the
meter
pro
or
the
meter,
reader
has
to
be
an
interface
and,
like
I'm
saying
myself
like
well,
if
that's
the
case
like
having
a
distinct
type
here
with
a
concrete
struct
under
underlying
it,
like
that,
maybe
it's
it's
useful
in
the
go
parlance
right
like
not
exporting
these
interfaces
and
having
the
concrete
types
for
other
developers
to
depend
on
is,
is
going
to
be
a
positive,
not
a
negative,
and
it
like
gives
a
clear
understanding
of
like
where
that
is.
A
You
know
that
control
flow's
going.
It
also
tailors
it
to
what
the
the
meter
program
or
the
meter
readers
actually
need
to
be.
You
know
like
this
periodic
reader.
It
still
has
the
same
collect
if
you
want
to
do
it
explicitly,
but
you
can,
you
know,
pull
and
have
it
have
it
have
a
different
shape?
If
you
didn't
want
to
do
that,
and-
and
you
know
to
that
point-
the
extensibility's
still
there
like,
we
can
always
add
a
new
type
in
the
future.
C
Place
and
aaron
saying
no,
no
and
then
like
I,
I
there
were
two
or
three
iterations
where
I
yeah
and
I
went
through
all
those.
That's
why
I'm
saying
it
all
feels
like
implementation
detail
and
to
me
the
spec
I
I
actually
ended
up
with
a
very
different
reading
of
spec
than
riley
and
aaron,
and-
and
I
can
that's
why
I'm
trying
to
be
super
accommodating.
C
I
don't
want
to
argue
over
what
it
means
I
just
want
to
get
it
done,
but
like
to
me,
the
reader
was
like
was
just
the
configuration
of
the
exporter
like
and
that
there's
no
reason
for
them
to
be
meaningfully
distinct
and
the
reason
why
why
you
might
say
that
there's
only
one
to
one
is
that
otherwise,
I
don't
know
how
to
define
what
shutdown
does
if
shutdown
shuts
down,
then
we
only
have
one
that's
kind
of
where
I
like
ended
up,
seeing
that
being
justified,
and
you
you
two
have
both
now
described,
how
there's
this
bi-directionality
and
in
java,
you
end
up
with
a
factory
pattern,
but
I
preferred
calling
it
registry
and
I
think
it's
the
same
pattern
though
so
reader
is
the
factory
of
exporters,
and
so
I
don't
have
an
issue
with
by
this
sort
of
bi-directionality,
because
it
seems
to
be
sort
of
part
of
the
design.
C
That
that
could
be
that
you're
looking
at
a
week
week
or
two
old
copy
of
the
iteration
that
we
were
working
on,
I'm
hoping
that
that's
actually
improved,
because
I
don't
think
I
have
that
feature
anymore
because
of
aaron's
feedback
making
things
better.
So
we
could
just
have
sort
of
fixed
some
of
that
stuff
up
right.
Now,
I'm
looking
at
my
own
head
code
and
it
was
readers
and
interface
that
includes
a
register
method.
C
So,
like
I
took
a
registry
out
as
your
point,
but
it's
and
then
there's
a
manual
reader,
which
is
exactly
like
aaron's,
describing
it.
B
C
B
So
I
think
I
we
we
went
over
this
at
one
point
I
I
do
remember
that
and
I
believe
one
of
the
the
issues
that
we
landed
on
is
how
does
the
the
thing
that
is
pointed
at,
like
the
thing
that
you
read
from
the
that
the
reader
is
supposed
to
read
from
whatever
the
producer
is
in
in
our
parlance
or
or
the
view
that
it's
registered?
B
How
does
that
view
get
updated
right
like
there
has
to
be
some
way
of
updating?
It
say
you
add
another
instrument
that
should
fall
under
that
view,
that
becomes
now
where
the
complexity
is
stored,
like
we've
just
shifted,
we've
shifted
some
of
the
complexity
and
I'm
honestly
not
sure
exactly
what
a
reader
would
look
like,
but
I
think
it
would
be
very
fairly
anemic
in,
in
the
current
parlance
right
in.
C
My
in
my
copy
of
this
right
now
reader's
interface
and
there's
binding
type
that
needed
a
name.
I
in
my
current
copy
of
this,
it's
called
an
export
pipeline
because
that's
informally
what
I've
been
calling
it
the
whole
time.
So
it
created
a
package
in
the
internal
export
directory
with
a
type
name
pipe
pipeline,
and
it's
just
a
reader
and
a
config
and
of
course
a
reader
is
just
an
interface
so
effectively.
C
I
I
see
no
reason
to
debate
over
the
difference
between
reader
and
exporter,
but
then
why?
Why
is
this
happening?
There
tyler
used
the
word
map
of,
and
I
know
there
was
a
map,
and
I
had
earlier
iterations
of
this.
I
had
a
map
of
an
interface
where
I
knew
that
the
type
under
it
was
a
pointer
of
us
to
a
struct,
and
I
was
relying
on
that
because
the
I
mean
the
sdk
spec
basically
encodes.
C
This
idea
that
the
synchronous
instrument
measurements
are
going
to
go
to
all
readers
while
asynchronous
instrument
measurements
go
to
one
reader,
so
that
there
is
a
question
of
which
reader
is
in
effect,
and
that
leads
to
this
like
need
to
map
from
the
view
something
to
readers,
which
is
the
one
direction,
and
then
the
other
direction
is
the
one
aaron's
all
already
described
so
that
yeah.
I
don't
know
if
this
is
the
unique
design,
but
I
don't
think
it
gets
much
simpler
from
here.
A
Well,
that's
what
I'm
saying,
though,
it's
like
you
have
this
idea
that,
like
you,
have
to
understand
like
what
gets
mapped
to
the
reader.
It's
like!
Well,
if
you
give
the
meter
producer
from
the
start
of
you
compiler,
it
already
knows
like
that.
Have
the
reader
maintain
the
state
of
what
it
needs
to
actually
be
pulling
and
that's
what
you
get
when
you
start
looking
at
it
from
from
the
other
way
around
where
instead
of
saying
like
to
the
to
the
meter
provider?
A
Okay,
here
I
want
you
to
produce
for
me
and
then
it
goes
and
it's
like.
Okay,
let
me
resolve
what
all
of
these
things
are
on
this,
like
ad
hoc
thing
at
the
time
that
I
need
to
be
producing
for
this
reader,
you
go
the
other
way
around.
You
say
like
at
the
reader
creation.
Understand
that,
like
this
use,
compiler
is
gonna,
be
passed
to
whatever
you
want
to
actually
be
produced,
and
you
don't
have
to
do
any
sort
of
mapping
at
that
point,
because
I'm
going
to
maintain
the
state
of
what
compiler
I
need.
C
B
I
think,
the
reason
why
we
ended
up
with
this
here
is
you
when
you,
when
you
have
it
in
this
way,
where
the
the
view,
either
the
views
like
view
reader,
whatever
has
to
maintain
the
state
of
instrument
mapping
to
eventually
the
export
pipeline,
like
the
produce,
whatever
does
the
production
right
wherever
that
is,
if
you
have
multiple
like,
if
you
have
ways
to
create
that,
and
you
have
ways
to
create
instruments
as
you
want,
you
now
have
to
have
both
instruments
get
updated
when
you
create
new
views
and
new
views
updated
when
you
create
new
instruments,
the
effort
that
we
had
was
okay.
B
Can
we
not
do
that?
Can
we
have
only
like
views
in
our
case
or
readers
in
our
case
be
create,
could
be
only
created
at
the
time
of
like
only
get
updated.
A
It's
important
to
understand
between
the
distinction
of
the
reader
and
the
in
the
view
right,
because
I
think
I
think
you're
right
on
the
first
two,
but
the
thing
is
like
the
the
reader
is
complicating
it's
polluting,
both
of
them
right
so
like
if
you
have
this
thing
where
you
need
to
understand
like
okay,
this
view
works
for
these
instruments
and
how
do
you
dynamically
change
these
instruments?
Okay,
so
there's
some
sort
of
like
compiler
element
to
that
right,
but
then
to
say
like
okay
cool
now,
but
what
compiler
should
I
use?
A
Because
I've
got
this
reader
over
here?
So
it's
like.
Why
do
any
of
that,
like
just
say
like
the
reader,
has
the
compiler
and
it
asks
okay,
I'm
just
going
to
give
you
the
compiler
that
you
need.
I
don't
need
to
do
any
mapping
on
top
of
that,
like
there's,
this
collect
collector's
function
that
doesn't
need
to
exist
in
the
new
state
like.
Why
does
what
is
the
views
list
contain
something
that
parses
from
the
reader?
What
you
need?
The
reader
already
knows
what
view
it
needs.
C
When
a
new
okay,
how
do
I
want
to
explain
it
you're
asking
about
collectors
which
I
have
in
my
version,
so
we're
close
enough.
C
There's
a
difference
between
instruments
and
between
what
we
might
call
time
series
or
metric
objects
right
and
the
there's.
The
collectors
is
the
equivalent
of
every
internet,
whereas
the
provider
had
to
have
has
to
flush
out
its
asynchronous
and
synchronous
measurements
and.
A
But
josh,
this
is
what
I'm
talking
about
like
right
here.
Right
you've
got
this
like
compiler,
and
it
has
this
map
of
readers
to
collectors,
and
I'm
saying
like
why
don't
you
just
have
the
reader
maintain
the
state
of
collectors
and
it
can
get
it
at
startup
from
the
meter
provider.
C
C
B
So
the
reader
can't
do
that
because
what
happens
when
you
add
another
view?
Well
sorry,
the
collectors
have
those
so
there's
two
different
scenarios
that
make
this
complicated
and
I'm
trying
to
put
together
a
quick
little
thing
to
kind
of
show
this
off.
C
One
of
the
answers
I
have
has
to
do
with
duplicate
instruments.
So
if
you
create
two
instruments
which
views
them
at
the
same
time
series
they
they
become
one,
and
you
only.
B
C
Them
once
so,
the
once
the
collectors
is
the
deduplicated
list
of
instruments,
whereas
the
external
layers
that
have
created
these
instruments
they
may
have
seen
duplicates.
I
hope,
that's
part
of
the
answer,
but
these
are
not
simple
questions.
B
Okay,
so
in
in
an
idealized
world,
the
media
provider
here
would
know
about
both
the
list
of
instruments
and
the
list
of
views,
right
views
or
readers
or
something
right
and
when
you
add
an
instrument,
it
has
to
go
and
iterate
through
all
of
the
views
and
update
views
to
match
the
different
instruments
right
and
we
haven't
like
what
we
did
in
in
the
example
is.
We
also
have
a
reader
here,
so
the
reader
is
tied
with
a
view.
B
A
A
It's
not
it's
it's
it's
a
mapping
in
the
meter
provider
or
in
the
view
state
and
that
is
associated
with
a
slice
of
collectors
right,
which
is
essentially
a
compile,
or
as
we
want
to
call
the
g-state
right.
But
I'm
saying.
A
Don't
we,
why
don't
we
do
exactly
what
you
said
like
have
a
view
associated
with
a
reader
and
like
on
startup,
the
media
provider
knows
what
all
the
views
are
right
and
so
or
or
you
can
create
one
as
aaron's
api
would
put
out
and
that
explicitly
is
associated
with
the
reader
like
right
now,
it's
the
other
way
around
where
it's
like.
Okay,
now
I
know
that
there
should
be
a
reader
to
a
view.
I
got
to
go.
A
C
C
There's
purse
there's
per
reader
state
happening
is
is
is
sort
of
the
reason
why
there's
a
per
reader
structure
it
is,
it
can
be
indexed
by
number
rather
than
by
pointer.
A
C
A
C
Per
reader
because
they
have
defaults
that
are
per
reader.
So
even
though
right
now
we
only
have
one
views
list.
It's
it's
interpreted
by
each
reader
differently,
so
they're
effectively
different
views
and
if
someone
later
said
you
can
have
pro
reader
views,
that
would
be
like
an
easy
switch
to
make,
but
I
still
think.
C
Yeah,
because
the
readers
have
the
default
aggregations
and
the
default
temporalities
and
so
on,
so
they
effectively
makes
the
views
per
reader.
Even
though
the
set
of
view
clauses
can
be
the
same,
which
is
why
I
support
views
being
just
literally
different,
because
it's
the
same
amount
of
work.
C
And-
and
I
guess
I
I
I'm
a
little
caught
off
guard
now,
so
I'm
not,
I
don't
feel
like.
I
have
a
perfect
answer
to
your
question,
but
the
idea
that
when
you
collect
from
any
reader
of
synchronous
instruments,
all
the
other
readers
receive
something
at
that
moment
in
time.
B
C
Engineer
it
differently,
but
that's
the
way
that's
the
way
it's
hitting,
which
is
why
that
connection
is
happening
right
there,
so
that,
if,
if
you
have
a
reader,
that's
being
like
pushing
every
second
every
second
you're
going
to
come
through,
all
your
synchronous
instruments,
snapshot
them
and
then
all
the
other
readers
will
receive
these
in-flight
snapshots.
And
it's
that
structure.
C
A
Was
I
a
little
confused
so
so
the
metric
reader
must
ensure
that
the
data
points
are
like
and.
A
So,
okay,
then,
maybe
can
you
help
me
understand
this,
because
you
might
have
more
context
here,
but
so
I've
got
the
metric
sdk
support
multiple
reader
instances
to
be
registered
with
the
same
meter
provider
right
and
the
metric
reader
collect
invocation
on
one
meter.
A
metric
reader
should
not
introduce
side
effects
to
the
other
metro
creator
instance
like
how
does
that
not
get
violated
in
this
process?.
C
A
C
B
It
pushes
to
be
underlying
aggregation
allocated
for
that
reader,
so
like
here
I
can.
I
can
modify
this.
This
might
help
a
little
bit
so
pretend
we
have
we'll
just
be
looking
at
this
one.
This
is
a
counter
right
and
we
have
something
a
little
less
complex.
We
have
two
readers
that
are
like
that.
This
one
is
every
five
seconds
or
every
every
five
seconds
and
this
one's
every
60
seconds
right
yeah,
and
this
is
a
synchronous
counter.
B
We
update
it
once
a
second
right
yeah,
underneath
the
hood,
because
it's
gone
through
the
view.
Compiler
there's
actually
a
allocation
of
memory.
B
C
Yeah,
so
a
synchronous
instrument-
I
I
just
feel
like
this-
is
such
a
complicated
piece
of
software,
so
yeah,
that's
synchronous
instrument
allocates
two
out
two
aggregations
plus
one
per
reader,
so
the
the
one
is
the
live
copy,
but
the
second
is
the
snapshot
copy
and
then
the
snapshot
is
written
to
one
for
each
reader
and
then
those
are
those
are
buffered
until
the
actual
collection,
which
happens
only
for
one
reader.
Immediately
after.
B
But,
but
is
it
do
we
have
only
just
the
one
memory
and
when
you
call
add
it
adds
into
both
of
these
if
they're
they
exist
in
both
views
or
I
thought
it
added
into
its
own
little
slice
of
aggregation,
and
then
that
gets
copied
over
into
here.
A
Either
way,
I'm
still
not
sure
this
is
right
like
even
if
it
is
just
an
aggregation
thing,
because
I'm
like
you,
know
the
sentence.
I
just
read
this
one
thing,
but
the
next
sentence
is
you
know,
for
example,
if
a
metric
reader
instance
is
receiving
metric
data
points
for
that
build
that
have
delta
temporality,
it
is
expected
that
the
sdk
will
update
that
time
range
only
for
that
particular
metric
reader
instance.
B
When
you
do
a
collect
in
the
five
second,
it
will
take
the
the
five
that
was
here.
Add
it
to
here,
and
that
becomes
five
and
it
doesn't
update
the
time
ranges
here.
But
it
needs
to
add
five
here,
so
this
can
get
reset
and
you
can
keep
counting
further
up
so
that
you
call
read
again,
you
get
another
five
here,
but
this
actually
gets
updated
to
ted
and
then
once
this
gets
collected,
the
60
second
reader
that
gets
reset
to
zero
so
that
you
can
keep
counting.
B
A
Okay,
and
so
what
you're
saying
then
is
if
we
tried
to
specifically
link
a
reader
to
a
view
like
you
can't
update
the
other
reader's
views.
Is
that
what
we're
saying
here,
because
that
was
going
back
to
this
whole
thing
like
we
didn't-
want
to
explicitly
link
the
reader
to
the
view.
A
C
I
guess
I'm
trying
to
say:
there's:
there
is
another
alternative
implementation
where
every
reader
maintains
its
own
map
of
current
instrument
and
attribute
set
pairs
so
that
when
you
update
the
counter,
it
has
to
go
update
some
data
structure
for
every
reader.
That's
not
what
we're
doing
right
now
and
that
would
simplify
the
idea
that
would
simplify
that
collection
path,
because
each
reader,
then
would
just
go
get
its
one.
Reader,
that's
been
incremented
by
by
the
instrument.
C
C
And
that's
how
you
might
describe
it,
but
it's.
The
alternative
is
then
that
each
reader
would
maintain
like
effectively
that
map
of
current
what
current
instrument
attribute
sets,
and
that
feels
like
it's,
not
just
it's
not
just
the
cost
of
say
more
than
one
aggregation,
it's
more
than
one
map
being
maintained.
C
So
for
all
the
synchronous
instruments
we
just
maintain
one
map.
We
just
call
the
aggregations
once
and
we
just
use
the
merge
function
to
feed
partial
results
to
the
output,
so
wait
hold
on.
A
B
A
C
A
So
essentially
like,
if
the
views
are
already
doing
it
to
themselves
like
they
maintain
a
like
a
you
know,
a
complete
state
and
they
can
update
all
the
other
collectors
right.
Then
all
you
need
is
just
that.
One
collector
to
the
reader
still
like
the
reader
doesn't
need
to
maintain
that
information.
A
I
don't
I
don't,
and
so
I'm
trying
to
understand
it
better
and
I'm
just
I
think
I
I'm
just
lost
because,
like
there's
a
this
registration
thing
like
I
was
saying
it
just
seems
like
you
you're
reaching
back
so
far
right,
because
when
you
register
a
reader,
what
it's
doing
is
it's
going
back
and
it's
you're
trying
to
get
like
this
producer
because
essentially
wants
the
the
meter
provider
to
provide
something
to
it,
which
is
like
the
opposite
right.
We
want
to
register
something
it's
like.
A
I
want
to
register
this
so
that
it
can
provide
something
to
this
and
it's
like
well,
I
want
to
register
this
that
it
can
ask
this
thing
to
provide
something
to
it,
even
though
I'm
registering
it
with
it,
it
just
seems
the
opposite.
When
I
started
to
like
flatten
that
out,
it
was
like
well,
this
is
the
flow
of
information
like
the
flow
of
information
is,
is
going
the
other
way
like
the
instruments
are
coming
to
the
meter.
The
meter
is
going
to
the
meter
provider.
A
The
meter
provider
is
then
providing
something
to
the
the
reader
well
to
the
views,
and
then
the
views
are
filtering
and
passing
it
to
the
reader
and
then
the
reader
is,
you
know,
periodically
pulling
itself
or
it's
just
directly
being
called,
but
it
that's
like
the
flow
of
information,
and
it
feels
like
there's
this
disconnect
where
we
get
to
like
the
reader,
where
it's
like,
okay
cool.
But
we
want
to
shoehorn
that
back
into
like
the
middle
because
and
like
so
one
of
the
things
that
I
haven't
said,
though,
is
that,
like?
A
I
think
the
flow
of
information
is
different
because
we're
trying
to
model
this
off
after
the
tracing
signal
and
the
tracing
signal
has
these
span
processors
and
they
always
sit
in
the
middle.
And
I
think
that
is
a
lot
easier,
because
it's
not
complicated
by
the
fact
that
you
have
two
different
types
where
you
could
have
a
pull
and
a
push
export
on
this.
But
I
don't
know.
I
also
think
that's
a
major
problem
of
this
idea
that
I
have
is
that
like?
A
If
you
do
try
to
wrap
this
and
try
to
straighten
out
and
flatten
this
information
flow
you're
diverging
from
the
tracing
signal
enough,
where
it
may
confuse
the
end
user,
where
they
don't
understand
like
how
to
set
things
up,
because
in
in
the
you
know,
flow
that
I
was
describing.
You
have
to
have
the
meter
provider,
which
then
goes
to
the
view,
and
the
view
goes
to
the
reader,
which
is
the
opposite
of
what
the
other
export
pipeline
is.
So
I
like
I
don't
know.
A
I
think
you
can
flatten
that,
because
you
can
have
the
periodic
meter
provider
become
just
an
option
that
you
would
pass
to
the
metric
provider
and
it
could
do
a
lot
of
stuff
under
the
hood.
But
you
still
like
the
prometheus
exporter
would
not
be
able
to
be
configured
that
way,
and
I
don't
know
I
just
I
have
questions
and
I
was
I'm.
I
guess.
I'm
also
curious
that
you
thought
about
these
and
it
sounds
like
you
have,
but
I
just
yeah.
B
Yes,
we
have,
there
are
knock-on
effects,
changing
it
any
which
way
honestly
like
this
is
complicated
enough
that
it
un
unbundling
this
gordian
knot
is
gonna.
Take
a
giant
sword.
A
C
But
like,
but
this
is
actually
kind
of
the
most
important
thing
so
that
I
can
work
on
other
things
without
feeling
guilty
for
one
thing,
but
I
but
but
maybe
we
we
should
have
a
better,
concise
way
of
saying
this
complexity.
Look
that
looks
accidental
is
really
purposeful
and
we
we
think
we
can
explain
it
and
did
the
best.
We
could.
A
A
At
the
end
of
the
day
is
I
want
an
understanding
of
that
because
I
don't
currently
have
that
and
so
like
I'm
totally
fine.
If
we
want
to
just
say,
like
you
know,
you
now
understand
like
the
question
I'm
posing,
and
you
know
let
you
think
about
it
like
like.
That
sounds
like
a
perfect
resolution
for
this
issue
for
this
meeting.
If
that
makes
sense,
and
if
anthony
and
aaron
are
okay
with
that.
B
I
would
just
so
that
I
have
clarity
on
the
question
that
you're
proposing
I
was.
I
was
wondering
if
we
could
restate
it
and
then
write
it
into
where
would
we
best
want
to
put
it
into?
Maybe
the
2809.
B
C
C
I
think
the
question
starts
with
an
unclear
specification
on
whether
readers
are
physical
things
or
whether
they
are
logical
things,
and
then
whether
exporters
are
physical
things
or
whether
they
are
just
readers
and
whether
those
are
questions
or
not.
It
comes
about
because
every
because,
when
you're
setting
up
this
export
pipeline,
it
appears
that
there
are
two
ends
to
it,
which
there
are
there's
the
end,
where
you
create
instruments
and
there's
the
end
where
you
know
how
to
handle
outputs
and
why
is
it
different?
C
It's
sort
of
different
because
of
the
data
model
and
the
export
period,
which
is
different
than
the
tracing
signal.
But
I
think
taiwan's
fundamental
question
is
comes
back
to
maybe
that
the
uncertainty
about
the
specification,
if
there
is
bi-directionality,
is
it
on
purpose
and
did
you
consider
all
the
other
ways
to
flatten
it?
But
if
you
have
a
cycle,
you
have
a
cycle
and
we
do
have
a
cycle.
I
think,
is
what
and
tyler's
just
sort
of
asking
to
like
be
very
clear
and
intentional
about
declaring
the
cycle
and
maybe
mentioning
alternatives.
C
C
Still
then
there
too,
that
when
we
have
multiple
views
of
or
multiple
exporters
of
a
say,
a
counter
that
the
operation
that
the
synchronous
operation
will
not
pay
for
every
consumer,
it
will
just
aggregate
and
then
declines
will
construct
what
they
need
from
that
information
and
as
a
choice,
then
the
first
step
that
I
took
was
to
buffer
per
readers
per
reader
output,
and
that's
why
you
see
this
map
by
by
reader.
C
C
A
I
got
you
so
I
took
notes
and
I
think
you're
you're
pretty
close
to
what
I'm
asking.
I
don't
know
if
you
can
hear
me,
I
thought
my
internet
connection
is
unstable,
but
yeah
specification
questions
are
physical
or
readers,
physical
or
logical
exporters.
Same
question
is
the
registration
complexity,
justified
and
then
kind
of
like
a
subsection
information
flow?
Is
you
know,
instrument
meter
to
meter
provider
to
view
the
reader,
but
is
there
bi-directionality?
Is
there
a
cycle
in
there?
A
Can
we
define
it
and
can
our
design
be
simplified
to
match
closely
with
this
information
by
matching
closer
to
this
information
flow,
or,
if
not,
can
we
you
know,
say
why
not
and
then
the
optimization
of
synchronous
instruments
buffer
per
reader
output
is
it
needed?
Is
there
justification
behind
that?
I
guess
is
the
question.
C
The
reason
we
have
views
is
to
correct
conflicts
and
whether
they're
accidental
or
on
purpose
and
if
they're,
accidental
or
on
purpose,
you
might
want
to
actually
change
and
merge
instruments
so
that
they
come
out
together
where
they
were
conflicting
in
in
the
source.
And
that's
that's.
That
leads
to
a
different
number
of
outputs
than
inputs,
which
is
what
led
me
to
the
final
place.
Where
the
view
compiler
has
a
list
of
collectors
as
opposed
to
each
well.
C
The
view
compiler
has
a
list
of
collectors
per
reader
as
opposed
to
the
reader
doing
that
itself,
and
I
realize,
as
I'm
saying
it,
that
the
reader
was
always
just
an
idea
and
and
it
moves
it's
moved
around
a
hundred
times,
because
it
was
an
idea
for
me
so
that
right
now
I
have
it
expressed
as
pure
configuration.
But
you
could
have
it
as
a
pure
storage
container
too
like
and
then
all
the
storage
moves
into
the
reader.
A
A
A
I
think,
there's
interesting
questions
there,
because
once
it
starts
to
own
where
its
data
is
getting
collected
from
and
just
getting
that
data
and
how
it
wants
to
manage
memory,
how
it
wants
to
manage
batching,
even
like
it's
all
up
to
the
the
reader
at
that
point,
which
is
good
because
it
sits
right
in
front
of
the
exporter.
A
B
A
There
is
no
question,
there's
no
like
resolution
at
that
point
because,
like
that
whole
single
producer
to
multiple
outputs,
it's
it's
already.
That's
the
consolidated
form
at
the
reader
at
that
point,
because
that's
the
thing
that
needs
to
go
off
somewhere.
A
That
being
said,
we
have
like
four
minutes.
I
want
to
be
respectful
because,
obviously,
like
you
know,
I
could
say
another
10
minutes,
like
I
said,
started
this
meeting.
B
A
Yeah,
which
I
think
is
overloading,
so
we
could
probably
just
put
a
pause
on
it
here:
josh
and
I'd
love
to
just
like
I'll
I'll
post.
This
thing
in
just
a
little
bit
I'll,
probably
fix
the
spelling
errors
that
I
have
in
the
post,
I'm
about
to
make
and
then
I'll
I'll
ping
you
in
it
and
just
to
see
what
you're
you
know
in
given
some
time
what
your
thoughts
on
it
are.
C
I
think
my
attitude
is
that
readers
should
be
implementation
details
and
I
I
did
get
to
write
that
somewhere
in
the
spec.
I'm
not
sure
it's
consistent
everywhere,
but
so
that
you
sh
you
shouldn't
be
providing
arbitrary
readers
from
third
party
code.
That's
just
like
readers
are
a
fixture
of
the
sdk,
so.
A
A
Because
if
it's
an
interface,
it
really
allows
third-party
readers
to
come
in
and
start
to
build
their
own
implementations
around
this
and
register,
and
do
this
whole
like
thing
on
top
of
that,
whereas
if
we
have
concrete
implementations
of
you
know
what
we're
calling
he
was
the
manual
reader
and
the
periodic
reader
like
that's
it
like
in
theory,
we
could
add
it
at
the
future,
we're
not
like
locked
in,
because
all
you
have.
A
The
exporter
only
makes
sense
in
the
terms
of
a
push
model
right,
because
that's
the
thing
that
takes
like
some
sort
of
like
you
know
thing
that
is
periodically
being
generated
and
pushes
it
somewhere.
That's
that
exporter
is
the
translation
from
data
to
a
push
destination
right,
the
pull
models,
the
other
way
around
right.
The
reader
should
already
know
where
the
destination
is
because
their
destination
is
coming
to
pull
from
them
right.
A
So
they
don't
really
need
the
concept
of
an
exporter
which
again
goes
back
to
that,
like
I
don't
know
if,
like
that,
makes
sense
to
have
it
all
unified,
because
they
don't
one,
one
doesn't
really
even
interact
with
the
next
board,
because
it's
not
it's
its
own
reader
right,
like
the
prometheus
model,
is
a
reader.
So
that's
why.
C
I
was
going
to
do
what
you're
saying
is:
have
a
concrete
type.
I
didn't
have
an
interface,
but
that
concrete
type
ended
up,
having
a
shutdown,
flush
method
and
that
register
method,
and
then
I
had
to
call
that
something.
So
that
was
the
registry.
At
that
point,
like
we
keep,
if
you,
I
agree
that
the
the
there's
a
struct
somewhere,
it's
not
a
it,
doesn't
need
to
be
an
interface,
but
when
we.
A
So
maybe
could
you
also
take
a
look
at
the
the
stubs
that
I
have
in
that
issue
because,
instead
of
having
a
register
method
on
the
creation,
you
pass
it
essentially
what
you're
going
to
register
it
with
and
then
it
like
it
solves
the
problem
that
it
can
only
be
registered
once,
which
is
something
in
the
specification
they
were
saying
to
do,
and
you
have
a
direct
linking
like
like.
So
that's
why
I
was
thinking
like
just
do
it
that
way,
but
okay
yeah
we're
definitely
have
time
now
anthony
and
aaron.
A
I'd
love
it.
If
you
could
take
a
look
at
the
meter
provider,
one
and
just
read
some
of
the
comments,
so
we
can
get.
I
think
that
one's
probably
gonna
be
the
least
controversial
out
of
any
of
them
so
and
then
josh
I'll,
give
you
a
little
bit
of
time.
Maybe
we
need
to
set
up
another
one
of
these
as
well
for
all
of
us
to
talk,
because
I.
C
Think
this
is
really
beneficial.
I
I
just
want
to
help
whatever
whatever
I
can
and
if
it's
the
most
thing
we
need
most
is
talking
through
it,
then
we
should
just
talk
through
it,
but
I'll
get
back
to
like
this
afternoon,
working
on
it
and
have
it
frustrating
since
the
last
time.
I
really
hoped
this
was
on
wednesday
intensely.