►
From YouTube: 2021-09-03 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
So
I
want
to
look
at
the
the
board
here
and
see
like
if
join.
I
want
to
see
if
we
can
mark
this
item
as
down.
A
I
think
we
can
start
so
so
I
have
a
topic
first,
I
want
to
go
through
the
the
current
metric
reader
pr.
I
know
there
are
still
some
open
comments.
I
haven't
replied
yet
I
want
some
discussion
here.
B
B
We
will
have
to
either
invent
some
very
arcane
way
to
make
sure
that
you
connect
the
request
with
the
response.
Yeah
the
api
you
design
or
yeah,
or
we
could
just
make-
have
the
collect
return
of
future.
That,
then,
is
associated
the
closure
of
that
with
the
request
that
will
then
just
write
when
the
data
is
ready
or
as
an
alternative.
B
Then
it
would
be
using
kind
of
standard
language,
idiomatic
structures
to
accomplish
what
your
intent
was.
I
think,
without
having
these
kind
of
two
separated
apis
with
requiring
some
complex
stuff
to
tie
them
together.
B
Sure
I
just
wanted
to
propose
an
alternative
that
would
be
very
simple
that
wouldn't
require
any
prototyping
work
to
be
done.
I
mean
it
just.
A
Would
just
work,
I
I
think
I
I
kind
of
understand
what
you
want
to
achieve,
but
I
I
have
a
hard
time
understanding
your
proposal,
so
maybe
you
can
send
a
counter
proposal,
just
a
snippet
of
thing
you
want
to
put
in
the
spec.
This
one
is
not
clear
to
me.
For
example,
you
want
to
get
rid
of
the
unclogged
at
all
and
how
you
expect
this
to
like
to
be
used.
Some
example.
B
Okay,
I
think
I
could
do
that.
I
mean,
I
think
that
it
just
what
the
callback
or
the
future
would
replace
the
uncollect.
That's
really
cool
yeah.
A
I
think
the
callback
probably
like
is
a
very
language
agnostic
thing,
the
future.
We
might
need
to
lose
the
wording
a
little
bit
mention
like
the
language
appropriate
way
of
being
able
to
like
pass
in
some
data
in
the
delayed
manner,
or
something
like
that
right.
B
A
Yeah,
okay,
cool-
and
I
I
guess
this
is
also
similar
to
a
comment
from
from
josh
here.
It
seems
like
the
the
way
I
I
put
a
base
exporter
that
was
causing
some
misunderstanding
and
he
was
saying
it
looks
like
riley
is
trying
to
encourage
the
inheritance.
Well,
I
I
didn't
what
josh
proposed
is
like
two
interfaces,
but
I'm
seeing
problems
this
like.
We
encourage
people
to
use
op
and
we
encourage
people
to
use
multiple
inheritance
which
is
not
possible
in
some
languages.
So
my
proposal
is
we.
A
We
should
lose
this
language
a
little
bit
instead
of
encouraging
people
to
use
any
inheritance
or
multi-harris,
but
as
long
as
we
can
achieve
the
the
goal,
so
I
wonder
like
josh
is
not
here,
but
I
I
I
think
john.
This
is
very
similar
to
your
previous
comment.
I
I
think
we
understand
the
goal.
It's
just.
We
want
to
give
some
flexibility
instead
of
forcing
people
to
use
any
design
patent
here
right.
A
A
A
A
A
A
A
A
Okay,
next
question:
I
I
think
is
related
to
josh
mcdonald
here,
so
this
one
I
want
to
discuss
so
josh.
I,
if
you
don't
mind,
I
will
start
first.
So
I
understand
where
you're
coming
from,
and
I
I
think
this
pr
currently
I'm
trying
to
allow
that.
So
you
can
I'm
trying
to
say
you
can
do
that,
but
I
don't
want
to
force
people
to
do
that.
A
C
C
That's
derived
from
two
different
exporters,
because
there'll
be
different,
different
data,
and
I
think
that
would
be
confusing,
and
I
also
always
felt
the
observer
pattern
was
there
to
avoid
these
expensive
calls,
and
so
those
two
are
making
me
lean
towards
wanting
to
spec
to
specify
a
single
sort
of
sequence
of
observations,
and
it
just
requires
either
that
we
get
strict
or
I
you
said
polling
logic.
I
I
I
think
I
understand
how
you
mean
it.
C
A
C
C
If
there
are
two
exporters,
I
don't
really
don't
want
to
pay
for
it
twice,
so
that
that's
where
I
it
was
coming
from.
As
for
the
api,
I
think
I
can
implement
exactly
this
api
and
I
think
my
feeling
is
it's
a
little
bit
over
prescribed.
Maybe
I
I
don't.
I
think
it
just
maybe
a
forced
api
in
the
same
way
that
josh
said
he
felt,
and
so
I
didn't
want
to
say
it
again.
I
could
definitely
implement
this.
A
C
It
is
a
case
where
the
value
is
not
extremely
well
defined
and
if
I'm
down
sampling,
I
would
like
to
take
to
there
to
be
a
property
that
the
high
frequency,
the
the
low
frequency
exporter,
sees
exactly
the
same
point
as
the
high
frequency
exporter
at
some
point
in
time,
so
that
the
two
signals
are
consistent
in
a
way.
C
This
is
what
I'm
and
the
practical
place
where
this
came
up
and
I
want
to
say
not
exactly
it
has
to
do
with
prometheus
cumulatives
and
when
you
have
a
reset
point
that
the
reset
point
is
an
opportunity
for
different
observers
to
see
different
behavior
prometheus
also
has
this
notion
of
high
availability
and
when
you
have
a
high
availability
stream,
what
you
get
are
different
observations
of
the
same
system
and
they
have
tend
to
be
at
different
points
to
time
and
it
it's
harder
to
work
with
data,
that's
less
aligned.
A
A
Yeah,
okay,
I'll
explain
my
scenario.
So
imagine
if
you
have
a
like
windows,
core
component
running
an
operating
system
and
from
the
windows
developer,
they
want
a
way.
Whenever
there's
something
bad
happened,
they
can
trigger
the
matrix
collection
and
report
that
back
to
microsoft,
removing
all
the
customer
like
privacy
data.
Meanwhile,
viral
studio
team
would
expect
the
tooling
to
be
able
to
run
at
any
time,
and
you
can
see
those
two
cases
are
very
rare.
They
only
got
triggered
based
on
certain
conditions.
Normally
on,
like
four
billion
users
or
windows.
A
C
I
I
can
see
how
it
sort
of
doesn't
matter
in
many
ways,
and
probably
I
should
just
recognize
that
I'm
being
wrong
here
it
does.
It
doesn't
matter
that
when
multiple
exporters
are
configured
you're
going
to
evaluate
each
of
the
asynchronous
instruments
multiple
times,
if
that's
a
big
deal,
you
should
just
do
what
you
said,
or
you
know,
run
one
exporter,
for
example,
so
yeah,
I'm
not
sure
this
is
a
big
deal.
A
Okay,
so
I'll
I'll
reply
and
explain
one
scenario
and,
and
for
now
I'll
I'll
still
keep
it
as
is,
but
if
we
see
other
options
I
can
see
if
there's
alternative
way
like
we
have
a
different
processor
at
all,
or
we
can
see
like
from
the
reader
perspective.
We
still
give
some
flexibility,
but
for
exporter
we
don't
export
that
so
how
to
explore
that.
It's
just.
I
think
it
will
force
everyone
to
reuse
or
to
cache
the
thing
and
find
the
like
maximum
common
divider.
That
would
be
a
show
stopper
for
some
microsoft
scenario
and.
C
Can
we
talk
about
the
synchronous
instruments,
then,
because
I
think
that
kind
of
is
was
your
example
in
the
the
pr
that
or
the
change
that
you
made
recently
after
the
first
meeting
this
week,
which
was
using
the
delta
export
as
an
example
saying
that
each
exporter
would
get
their
own
copy
of
the
delta.
C
So
this
does
seem
to
require
that
each
exporter
has
some
record
of
the
accumulations
that
have
happened
since
the
last
time.
They
made
an
observation
and
there's
still
only
one
api
caller
making
these
updates
to
the
metric
state
so
anytime
one.
This
is
why
I'm
worried
what
I'm
seeing
is
anytime.
One
exporter
asks
to
get
all
the
metric
state.
A
A
C
C
A
A
I
agree,
and
I
I
think
you
can
imagine,
the
thermal
approach
would
be
just
duplicate
the
effort
and
do
that
individually
for
each
like
the
sdk
will
basically
maintain
a
separate
state
for
every
explorer.
This
is
the
dumb
solution
and
we
can
say:
oh
we're,
actually
saying
like
each
delta,
it's
more
like
the
the
git
commit,
so
you
can
merge
multiple
commits
and
squash
them,
so
you
can
maintain
the
state
saying
this
is
my
current
value
and
this
is
delta
one.
A
This
is
delta
two
and
I
cannot
remove
delta
one
because
there
is
another
exporter
expecting
the
combination
of
two
deltas
and
when
the,
when
the
other
exporter
asks
for
the
delta,
you
have
to
realize
where
what's
the
what's
the
delta
changes,
so
you
you
might,
you
might
end
up
merging
multiple
deltas
into
a
bigger
one
right,
so
you
can
do
something
like
that
or
you
can
see.
I
you
have
some
copy
on
right.
I
think
similar
I
get
you
maintain
different
branches
and
how
you
merge
different
commits
there's
different
ways
to
do
this.
C
A
Complex
and
I
I
think
the
current
ick
spike
proposal
wouldn't
like
force
anyone
to
use
a
certain
approach.
It
gives
the
flexibility
so
for
simple
cases,
people
can
say
I
don't
have
a
production
scenario,
running
multiple
things
and
I'm
willing
to
pay
for
the
actual
memory
cost
and
computation
cost
just
to
duplicate
everything,
to
keep
it
a
simple
design
and
or
the
other
scenario.
People
can
see
that
I'm
willing
to
maintain
the
chain
of
delta
changes
and
do
the
reference
company
or
something.
C
It's
that
I,
where
what
I,
what
I
see
is
a
simple
opportunity
to
optimize
something,
and
I
guess
I'm
going
to
drop
it
right
there,
like
the
simple
opportunity,
is
if
you
force
all
the
exporters
to
have
sort
of
multiples
of
each
other
other
in
frequency,
then
there
is
a
straightforward
approach
that
gets
all
the
exporters
what
they
want
without
having
to
cop
maintain
delta
state-
and
I
hinted
at
it
last
time,
which
is
let's
just
not
let
the
pull-based
exporters
have
deltas
prometheus,
doesn't
do
that
and
I'm
not
sure
anyone
really
should
so
that's,
and
that
gets
back
to
the
first
concern
of
john's
and
josh's
is,
is
that
it
seems
like
there
are
two
interfaces
and
you
have
two
diagrams,
and
one
of
them
is
a
poll
oriented
interface.
C
Where,
honestly,
I
think
we
should
only
allow
you
to
ask
for
cumulatives,
in
which
case
this
delta
question
goes
away
and
then
for
push-based
exporters.
You
can
either
do
what
you're
implying,
which
is
you
know
what
we'll
describe
to
just
two
different
solutions.
Now
one
is
essentially
every
metric
has
its
own
intermediate
state
or
you
compute,
a
single
intermediate
state,
and
then
all
the
exporters
have
sort
of
essentially
a
staging
area
where
they
compute
their
own
aggregation
of
any
deltas
that
have
arrived
since
the
last
period.
C
C
This
property
that
all
the
observer,
all
the
asynchronous
all
the
asynchronous
instruments,
will
have
the
same
value
across
all
the
exporters,
but
you've
argued
that
that
can
be
done
anyway
and
we're
not
preventing
anyone
from
choosing
to
do
it.
That
way.
So
I
will
rest
my
case.
A
Yes,
I'm
trying
to
capture
what
you
mentioned.
I
I
hope
it
is
accurate.
So
you
start
with
you
want
to
make
the
sdk
simpler
instead
of
having
to
maintain
multiple
states
for
different
exporters,
and
in
order
to
do
that,
you
propose
the
exporters
should
be
able
to
maintain
some
state
and
exporter
a
might
be
getting
something
when
exporter
b
got
the
data,
even
if
a
is
not
ready
to
export.
So
it
has
to
take
the
data
store
it
somewhere
and
when
it's
ready
to
export
it
has
to
aggregate.
C
Well,
if
you
have
a
use
that
is
pull
a
pull
exporter,
that
is
not
a
single
essentially
like
prometheus,
then
I'm
not
sure
whether
what
you're
what's
effectively
happening
is
like
a
reverse
stream
request,
where
the
scraper
or
the
puller
calls
in
and
says.
Please
start
streaming
these
metrics
that
is
effectively
a
push
channel.
A
The
way
I
I
think
about
pull
exporter
is
you
don't
have
the
luxury
to
send
the
data
at
any
random
time?
You
can
only
send
data
when
you're,
given
permission
to
do
so
like
when
the
scripter
makes
the
http
request
well
for
pushing
exporter.
I
think,
whenever
you're
happy,
you
can
always
send
the
data.
A
Yeah
yeah,
I
I
feel
like
we're
we're
discussing
something
that
seems
to
be
a
little
bit
like
deep
and
abstract,
so
it's
probably
unfair
for
many
other
folks
on
on
this
sorry
about
that,
okay,
I
I
guess
you
can
probably
stop
here
and
and
probably
like
see.
What's
the
outcome
from
josh's
prototype
on
java
and
download,
probably
we
can
work
on
a
prototype
and
see
how.
D
That
works
yeah
I
mean
I
sent
a
pr
like
about
an
hour
back
trying
to
implement
exactly
what
the
pr
is.
So
it
looks
good
to
me.
I
don't
see
any
issues.
I
have
linked
it
to
the
spectator
itself,.
A
Yeah,
probably
because
we're
both
coming
from
donald
world,
so
yeah
you
get
to
get
some
java
prototype,
okay,
cool,
so
josh,
let's
park
here
and
and
we
can
move
to
the
next
topic.
So
last
time
we
mentioned
like
I'll,
follow
up
to
some
separate
api,
so
I'm
I'm
currently
a
little
bit
stuck
on
the
metric
reader.
A
So
I
I
wonder
like
what's
the
what's
the
timeline,
I
just
want
to
sort
out
like
who's
doing.
What
and
what's
the
timeline
giving
like
josh
sewage
is
not
here,
probably
won't
be
able
to
get
it,
but
let's
go
back
to
the
the
tracking
here
so
for
experimental
release.
Api
is
already
like,
like
done
a
month
ago,
so
for
the
sdk
part
just
quickly
go
through
that.
I
think
this
one,
the
metric
observer
collection
should
be
independent.
A
We
already
discussed
this
was
raised
by
data
trace
developers
and
we
haven't
got
response
and
from
the
others.
We
haven't
seen
this
as
a
big
ask,
and
even
if
we
need
to
do
this
with
the
current
proposal,
the
reader
proposal,
we
will
be
able
to
cover
this
easily
with
adding
some
parameters.
So
I
would
prefer
to
move
this
out
of
scope
even
out
of
the
first
stable
release,
scope,
folks,
agree
or
not,
or
at
least
like.
A
C
C
He
mentioned
wanting
min
max
and
sum,
but
would
six
data
points
batched
into
one
request,
every
minute
be
good
enough
or
because
that's
that's
a
much
easier
thing
to
ask
for
and
then
we
could
just
specify
for
the
otlp
exporter.
A
Yeah,
I
I
guess
like
the
ask
here
is,
for
example,
you
have
a
you,
have
a
like
signal
that
change
very
frequently,
but
due
to
some
limitation,
you
cannot
export
at
a
high
enough
frequency.
A
So
what
you
do
is
you
you
trigger
the
asynchronous
callback
frequently
and
you
only
report
in
a
very
slow
manner
and
in
that
way
I
I
don't
know
if
the
classroom
would
be
helpful.
So
I
can
imagine
this
in
the
iot
scenario.
You
have
some
embedded
device
that
uses
sensor
and
you
have
like
satellite
like
wireless
connection,
which
is
super
expensive
and
any
call
takes
like
seven
minutes
communicating
to
mars.
Then
probably
one
that
features
from
ic
and
I
I
don't
see
how
clocks
would
help
here.
C
I
I
could
pitch
you
another
way
to
do
to
model
this.
That
would
work
for
us,
but
it
still
requires
the
evaluation
of
the
asynchronous
instruments
to
happen
faster.
We've
talked
about
this
thing
called
a
gauge
distribution.
If
you
treat
each
of
these
asynchronous
points
as
a
gauge
value,
so
they're
going
to
be
six
of
them
over
your
minute.
In
this
hypothetical
scenario,
when
it
comes
time
to
export
we're
going
to
perform
an
aggregation
to
get
one
point
again,
and
that
would
be
this
conversion
that
happens
from
gauge
to
histogram
called
the
gauge
histogram.
C
C
He
asked
for
min
max
and
average,
and
this
would
be
a
good
point
to
remind
us
all
of
us
that
a
histogram
with
zero
buckets
is
equivalent
to
a
min
max
average,
roughly
speaking
so
gauge
histogram
with
zero
buckets
equals
min
max
average
in
my
opinion,
and
that
so,
if
we
both
for
this
delta
k,
the
prior
discussion
that
we
had
about
deltas,
it
seems
like
there
needs
to
be
a
mechanism
to
take
multiple
observations
across
time
and
to
collapse
them
into
one
point
earlier.
C
This
discussion
was
about
deltas
being
combined
and
most
for
the
most
part,
you
might
be
thinking
about
sums
which,
when
you
have
delta
sums,
they're
easy
to
combine.
You
just
keep
one
extra
sort
of
aggregator
state
and
you
combine
by
addition
every
time.
Well,
a
delta
for
a
gauge
histogram
is
is
going
to
do
the
correct
thing
here,
so
you
you're
going
to
have
a
gauge
coming
in,
but
the
aggregator
is
a
gauge
histogram.
C
C
Release,
I
I
I
know
it's.
It
can
be
done
essentially
as
a
new
stage
and
it's
like
an
exporter
stage.
It's
the
same
machinery
that
I
would
use
to
collapse.
Deltas
would
be
to
collapse
gauges
into
gauge
histograms,
and
it's
once
you've
once
you've
called
the
reader.
C
A
C
Well
to
me
it's
either
asking
in
the
example
it
was
given.
It
sounds
like
it's
asking
for
a
gauge
histogram,
but
it
sounds
like
you've
been
specifying
that
we
should
implement
delta
delta
for
pull
and
there's
just
sorry.
I
I
don't
think
I
should
comment
anymore
this
this
is,
I
don't.
I
think
you
can
remove
it
from
scope.
I
agree.
A
A
So
I
don't
know
whether
these
two
can
be
marked
as
done,
but
I
I
think
they've
been
working
on
both
of
them
and
these
are
the
the
current
items
on
our
plate,
so
this
magic
reader
pr
once
we
agreed
it's
merged.
I
think
I
can
also
close
this
metric
processor,
because
this
is
basically
the
the
processor
right.
A
A
A
Okay,
that's
all
from
my
side.
I
I
still
have
a
follow-up.
I
want
to
find
the
third
language
that
can
commit
to
the
beta
release,
so
I
I
already
reached
out.
I
I
just
need
to
hammer
out.
What's
the
beta
timeline,
I
want
them
to
like
publish
the
beta
timeline
on
their
like
project
home
page,
so
I'll
I'll
continue
to
do
that
and
report
back
next
time.
C
We,
how
can
we
help
you
go
faster,
rightly
on
the
reader?
Pr
specifically
you've
totally
convinced
me
that
all
of
my
reservations
were
you
know,
sort
of
like
less
important
than
your
imagined
use
cases.
I
think
we
should
go
forward
with
what
you
have
if
we
can
overcome
john's
type
of
question
and
josh
who's.
Not
here,
I
wonder
if
we
could
invite
john
to
talk
more
about
this
a
little
bit
since
it
is
a
small
group
and
yeah
we're
all
still
here.
A
We
can
give
some
example.
You
see.
This
is
the
language
choice
as
long
as
it's
like
idiomatic
to
them.
I
think
that
might
make
john
happy,
but
john,
please
tell
me
I'll
stop
here.
Yeah
I
mean,
I
think.
B
B
I'm
still
not
honestly
convinced
that
there's
a
lot
of
value
in
having
a
single
interface
for
both
push
and
pull
exporters,
which
I
think
is
the
primary
thing,
is,
I
feel,
still
feel
like
we're
really
bending
over
backwards
for
a
design
choice
that
I
do
not
see
a
lot
of
value
in.
B
Yeah,
I
don't,
I
guess
I
don't
think
it's
a
real
production
example
that
anyone
will
actually
care
about
in
the
real
world.
I
think
it's
a
contrived
example
that
you
know
might
be
interesting
to
implement
for
demos,
but
it's
not
one.
That's
going
to
be
a
real
world
example
that
people
run
in
production
like
a
command
line
exporter
where
people
get
data,
but
they
can
hit
the
spacebar
to
get
more
data.
Like
that's
a
fine,
that's
a
great
demo,
but
it's
not
something.
C
Yeah,
can
I
can
I
maybe
back
up
it
sounds
like
riley
has
agreed
that
we
can
loosen
the
text
and
make
it
less
prescriptive,
and
that
might
mean
that
you
can
say
languages
should
just
choose
an
idiomatic
approach
here
and
by
the
way
we
think
there
are
two
patterns
and
you
can
do
it
with
one
api.
Like
riley's
done
and
I
I
said
it
was
commendable
like
I,
I
can
see
how
that
was
at
execution
of
the
goal,
but
I
think
john
is
saying
that
wasn't
a
good
goal
for
me.
C
It
did
it
like,
like
john,
was
saying:
it'd
be
awkward
in
java,
I'm
not
saying
it's
awkward
and
go
to
do
the
exactly
interface
that
you
wrote
in
this
current
draft,
but
it'll
be
a
little
awkward,
not
it's
it.
I
was
saying
it
might
feel
a
bit
forced.
I
I'm
I'm
happy
with
having
two
separate
interfaces,
one
for
a
pull
exporter
to
use
and
one
for
a
push
exporter
to
use,
and
that
will
make
it
more
idiomatic
and
go.
I
think.
B
B
And
that
I
mean
that's
really
all
it
boils
down
to,
because
I
think
languages
should
be
able
to
build
code
and
synthetic
and
easy
to
understand
as
long
as
they're
fulfilling
the
the
goals
that
we
have
for
for
actually
getting
data
out
of
the
system.
A
Okay,
yeah,
I'm
I
I
I
totally
agree,
so
I
probably
need
to
notify
josh
sturridge,
because
I
don't
want
to
surprise
him
like
he
tried
hard
to
make
java
using
a
consistent
model
and
tell
him
we
just
give
flexibility
and
use
different
things
for
holes,
so
I'll
I'll
ping,
him
and
and
I'll
I'll
change.
The
pr
right
after
I
I
ping,
josh
and
and
he's
okay
with
that
I'll
change,
the
pr
to
losing
that
part
and
john.
A
I
have
a
question
for
you
if
I
change
that
part
that
that
would
make
the
current
sequence
diagram
wrong
and-
and
if
we
don't
give
any
specific
like
prescription
about
this,
then
I
wouldn't
have
the
sequence
diagram
at
all,
or
I
need
some
of
your
insight
because
I
I
cannot
imagine
how
would
I
draw
a
sequence?
Diagram
is
just
tell
people
you
can
do
whatever
you
want.
A
B
Yeah,
so
I
don't
think
the
sequence
diagram
is
needed.
If
we
don't
aren't
being
prescriptive
like
this
okay,
I
don't
think
it's
needed
there.
Oh,
I
was
almost
asking
for
because
I
could
not
fathom
what
you
were
saying
and
I
needed.
I
needed
a
picture
because
my
brain
didn't
process
the
words.
That's
that
was
all.
A
A
If
you
think
that's
important,
it's
not
needed
because
we're
like
what
I
think
you're
trying
to
push
for
is
we
don't
restrict
the
language
so
we're
not
you're
not
trying
to
see
everyone
should
follow
the
java
way.
Then
I
think
we
don't
require
that
if
you
think
that
would
help
the
others
to
understand
where
you
were
coming
from.
You're
still
welcome
to
do
so,
but
don't
feel
you
have
to
do
it.
Okay,
cool
yeah.
I
mean
my
whole
goal
was.
B
C
Have
multi-exported
support
yet,
and
I
the
way
I
did
this
in
go.
It
was
there's
one
push
exporter
allowed
and
you
can
set
one
frequency
and
then
pullers
can
can
probe
whenever
they
want.
And
if
you
happen
to
configure
just
pull
you
can.
You
can
be
on
demand
and
if
you
happen
to
configure
just
push,
you
can
set
your
frequency
and
if
you
want
both
the
puller
gets
to
see
whatever
the
last
push
get
got
and
that
only
works
for
cumulative.
So
it's
pretty
restricted.
C
It
wasn't
going
to
be
flexible
enough
for
what
riley
has
pitched
and
I'm
on
board
with
this
essentially
other
than
thinking
that
it
is
slightly
awkward
api
and
we
can
just
do
whatever.
If
we
could,
the
language
implementers
can
do
what
we
want.
That'll
solve
this
problem.
A
And
josh,
so
I
I
had
an
offline
discussion
with
josh
suresh
and
I
I
I
think
one
possible
way
he
he
might
he
might
be
doing
is
if
we
have
delta
and
vitamin
takes
powers,
they
export
things
on
different.
A
So
that's
why,
instead
of
making
like
how
people
should
implement
that
as
a
spike,
I
I
just
decided
to
forget
about
it
like
each
language
to
figure
out
what's
the
best
way
and
for
doughnut
I
know
seizure
is
picking
the
duplicate
effort
way
and-
and
we
talk
with
many
folks
in
microsoft,
they
seem
to
be
okay
or
not
I'll.
Stop
sharing,
because
this
one
is
like
probably
introducing
more
confusion
here
instead
of
cloud.
B
A
Yeah
and
serial
has
something
he's
not
exposing
that,
but
something
like
aggregated
like
aggregator,
so
you
call
the
aggregate
aggregator,
then
that's
why
it's
going
to
call
multiple
aggregators
and
each
of
them
update
their
own
state.
C
As
a
as
a
implementer
I
might
ask
for,
but
this
doesn't
have
to
be
a
requirement
like.
If
I
make
one
counter
ad
call,
is
it-
and
I
have
three
exporters?
Am
I
gonna
have
to
sum
three
times
or
am
I
gonna
do
that
once
at
the
api,
so
because
we
expect
many
more
api
calls
than
export
calls
and
so
like?
If
I'm
calling
the
ad
a
million
times
per
second-
and
I
have
three
exporters,
am
I
really
calling
three
million
additions
per
second
or
is
it
one
million
magicians
per
second.
A
Now
we're
doing
the
stupid
thing
so
now
it's
three
million
and-
and
I
believe,
if
it's
cumulative
it'll,
be
easy-
that
we
can
do
the
optimizations.
You
end
up
with
one
minute,
if
it's
delta,
no
more
struggle,
whether
we
keep
the
delta
change
separately
and
being
able
to
merge
that
later
or
we
just
duplicate
the
effort
and
we'll
do
the
benchmark
to
see
which
one
is
better
sure.
C
Yeah,
that's
fine!
I
the
way
the
sdk
is
already
structured
for
me.
It
wouldn't
make
sense
to
go
the
other
way.
I
I
can
just
reuse
existing
pieces.
I
have
to
wear
them
up
a
bit
to
get
this,
but
each
exporter
will
maintain
its
own
processor,
but
they'll
all
get
it.
They'll
do
delta
to
cumulative
conversions
of
their
own
if
needed,
but
they
can
also
do
delta
the
delta
conversions
of
their
own.
C
A
I
I
believe
bogdan
and
josh
sewage
have
the
same
thinking
as
you,
so
they
probably
will
prefer
the
same
thing
for.
C
Child-
and
I
think
you
haven't
specified
things
in
a
way
that
I
can't
do
that-
that's
okay,
but
that
is
the
reason
why
I
asked
about
asynchronous
instruments
and
whether
they
would
be
reevaluated,
because
it's
possible
to
make
the
same
argument
for
asynchronous
instruments,
but
I
think
it
just
fell
apart
for
me.
I
don't
need
to
make
that
argument
anymore.
It's
fine
to
evaluate
basic
instruments
for
every
exporter,
but
I'm
still
gonna
for
the
synchronous
instruments,
probably
snapshot
whenever
anyone
needs
to
and
do
the
delta
conversion
and
the
cumulative
conversion
in
each
exporter
pipeline.
D
Question
yeah,
so
it's
about
the
like
temporality
part,
so
we
now
have
metric
exporter
and
metric
reader
is
like
almost
ready
to
be
merged,
so
will
either
of
these
interfaces
or
either
of
these
classes
expose
something
like
what
is
their
preferred
temporality,
because
josh
did
mention
like
something
like
that
in
his
co-prototype
and
I
pretty
much
followed
the
same
internet
also,
so
will
there
be
like
any
way
like
either
leader
or
the
exporter?
D
A
A
D
A
Yeah,
so
so
we're
not
going
to
focus
on
that
now
until
we
got
the
sdk
experimental
release
out,
we're
we're
a
little
bit
behind,
if
not
terrible.
So
once
we
have
that,
then
that'll
be
the
next
thing
for
the
feature:
freeze,
scope,
okay,
okay,
that
gives
us
more
confidence
thanks.
Sarah,
I
I
think
the
action
item
for
me
is
to
to
ping
josh
storage
and
see
if
he
agrees
and
then
I'll
update
my
pr
or
wait
for
him
and
then
update
my
pr
and
then
I'll
get
to
pro
from
here
guys
awesome.
Thank
you.