►
From YouTube: 2021-07-29 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
C
A
C
A
Either
way
it's
fine,
it's
just
heads
up.
We
already
got
approval
through
the
process.
C
Yep
yep
someone
I
I
guess
ceo
had
closed
it
by
accident,
so
it
didn't
go
through
the
auto
merge
that
I
had
expected
it
to
have
already.
So
that's.
D
C
A
A
Okay,
so
I
have
a
skeleton
pr
for
the
exporters.
It's
very
simple:
there's
there's
no
meat,
just
skeleton.
So
please
take
a
look
and
I
have
a
question
because
when
I
look
at
the
the
tracing
spike,
although
we
mentioned
somewhere,
we
need
the
the
the
standard
outer
console
exporter
and
the
memory
exporter,
but
we
don't
have
a
specification
on
that
and
for
matrix
I
I
think
we
probably
need
to
have
that,
because
I,
I
think
many
folks
assume
that
the
in-memory
and
the
console
exporter
will
be
push-based,
but
I
have
different
thinking.
A
B
How
is
that?
An
exporter.
B
A
You
will
have
a
way
to
take
the
data
from
the
sdk,
even
if
the
sdk
is
is
not
sending
you
actively,
for
example
like
premises
when
permissions
agent
reach
out
to
the
endpoint
and
say
I
want
the
data
the
sdk
will
have
to
report
the
data.
To
that
moment,
I
think
the
in-memory
exporter.
If
you
look
at
the
unit
head
scenario,
you
might
have
some
threads
running
report.
The
metrics
and
at
the
end
of
the
unit
has
to
you
want
to
say
I
want
to
collect
all
the
metrics
data
that
I
have
reported
so
far.
A
B
A
A
B
With
you,
it
just
translates
and
exports,
so
this
the
being
affected
by
the
pool
or
the
push
is
something
that
concerns
the
media,
not
an
exporter.
I.
B
All
right,
so
that's
the
idea
with
this
spec
to
define
that,
as
you
just
said,.
A
Yeah
remember
previously:
we
have
something
called
pipeline
and
when
I
do
the
exporter,
I
try
to
put
the
pipeline
information
somewhere
like
when,
should
we
export
the
data?
I
think
the
spotter
should
just
sit
there
and
have
export
method,
taking
the
data
and
do
whatever
it
wants
and
and
the
exporter
itself
can
be
push
or
pull
based
or
both,
but
it
shouldn't
give
the
user
an
api
to
actively
pull
the
data
that
that
api
should
be
somewhere
else
or
that
mechanism,
not
not
necessarily
an
api,
should
be
somewhere
else.
A
And
you
already
see
it,
it's
a
it's
a
little
bit
more
complex
than
the
tracing
part.
To
my
surprise,
we
don't
have
the
trace
exporter
for
in-memory
and
console
spec
out
anywhere,
and
people
just
released
something
so
I
I
think
maybe
like,
because
this
is
for
most
likely
like
unit
test
and
local.
Like
learning.
We
probably
don't
want
to
make
it
too
strict,
but
at
least
I
want
to
clarify
the
push
pull
part.
C
So
so
I
understand
what
you're
proposing
I'm
gonna,
I'm
gonna
put
it
into
trace
terminology,
so
traces
right
now
are
always
push
based
into
the
exporter
right.
C
C
The
only
caveat
I
want
to
call
out
if
we
make
this
decision
it
means,
for
example,
when
you
export
prometheus,
you
could
possibly
be
looking
at
slightly
stale
data
from
that
screen
right
and
I
think
that's
totally
fine
or
relatively
fine
like
I
don't.
I
don't
see
any
issue
with
pushing
for
that.
Simplification.
Right
now,
I
think
that
could
help
us
get
things
through
relatively
quickly,
so
I'm
a
fan
of
this
is
that
going
that's
going
to
be
defined
in
a
follow-on
pr
from
this
pr
yeah.
A
E
Described
in
the
hotel
go
prototype
and
there's
a
controller
that
has
that
has
two
modes:
if
you're
pushing,
then
you
get
the
behavior
that
josh
just
described,
which
is
that
you'll
get
slightly
still
pull
data
because
you've
got
a
push
cadence
already
happening,
and
you
don't
want
to
push
additionally
because
of
a
pull
request
and
then,
if
there
are
no
push
export
configured,
if
there's
no
push
period
configured
because
poll
is
the
only
consumer,
then
it
doesn't
on
demand,
collect
and
gets
you
not
stale
data.
A
A
Yeah
yeah
I'll
I'll
I'll
try
to
make
progress
on
the
in-memory
exposure,
because
when
people
make
progress
on
that,
I
think
the
prototype
we
can
start
to
do
some
unit
tests
and-
and
they
don't
require
a
lot
of
format
like
if
I
start
with
console,
I
think
probably
will
start
with.
What's
the
output
format
indentation
of
things
so
I'll,
try
that
and-
and
I
personally
would
prefer
the
explicit
way.
So
I
I
want
to
avoid
still
data.
A
Yeah,
so
I
have
similar
thinking
as
what
josh
dr
mcd
mentioned.
A
C
A
C
A
I
mean
I,
I
think
it's
totally
fine,
that
we
release
the
first
version.
Without
that
and
later
we
want
to
add
it
back.
We
can
it's
not
a
breaking
thing.
So
if
we
feel
like
this
makes
like
language
maintainers
job
easier,
I'm
I'm
willing
to
do
it
I'll
I'll,
submit
a
pr
to
remove
that
and
put
the
explanation
there.
It's
not
that
we
think
that
concept
is
not
needed.
It's
just.
We
think
this
is
not
something
we
must
have
for
the
first
release
and-
and
we
want
to
be
able
to
focus
on
something
else.
C
Yeah,
I
also
think
if
it's
not
contentious-
and
all
we
have
to
do
is
specify
a
single
method
for
it.
I'm
also
fine,
just
adding
that
in
there,
like
that's
fine,
too,
either
way
I
either
want
that
to
do
gone
or
where
I
want.
The
section
gone
one
of
the
two.
If
metric
processor
is
not
contentious
like
hey,
I
get
in
metric
data
and
then
I
output,
metric
data
and
the
exporter
gets
whatever
output.
That's
fine!
A
A
A
So
either
way,
I
I
want
to
know
your
feedback
josh.
If
I'm
sending
a
pr
to
remove
that
now,
do
you
think
it'll
be
better
make
you
feel
better?
If
that's?
Yes,
I
can,
because,
if
they
export
her
later,
like
I
mentioned,
we
need
that
back.
I
I
should
put
that
in
the
same
pr,
like
the
exporter
processor,
pr.
C
Yeah
yeah,
I,
what
I'm
suggesting
is
we
either
say
that
we
absolutely
understand
what
this
is
and
there's
no
contention
and
we're
going
to
have
it
now
and
require
it
as
a
user
extension
point
or
just
remove
it
and
we'll
add
it
in
when
we
need
it.
I'm
I'm
a
fan
of
only
adding
in
things
that
we
think
are
absolutely
necessary
for
v1
right.
C
C
Meeting,
I
also
want
to
point
out-
I
think
the
reason
we
don't
need
it
is
because
we
have
a
view
api.
C
The
metric
processor,
I
think
the
reason
we
don't
have
as
much
of
a
need
for
it
is,
is
twofold:
one:
is
you?
Have
this
exporter
setup
that
you're
going
to
be
configuring?
That's
going
to
be
a
little
more
complicated
and
that's
half
of
what
you
would
use.
One
of
these
processors
for
and
the
other
half
is
around
modifying
metrics,
which
we
expose
the
view
api
for
so
I
think,
there's
a
very,
very,
very,
very
limited
amount
of
use
cases
where
a
metric
processor
even
makes
sense
because
of
all
the
other
work
we
have
like.
A
See
so
you're
saying
if
people
want
to
remove
a
dimension,
they
would
just
use
view
and
imagine
techniques
wouldn't
be
useful,
but
if
they
want
to
say
if
this
dimension
is
a
and
the
value
is
less
than
http
300
then
drop
the
data.
They
might
need
that.
But
we
also
could
consider
that
in
the
view,
because,
currently
it's
not
clear-
let's
not
do
it
now,
just
remove
that
makes
sense.
A
C
Yeah,
so
the
exemplar
pr
is
still
missing
some
wiring
into
aggregators.
I
think
there's
three
points
of
discussion.
I
want
to
bring
up
from
the
pr
it
it.
Thank
you
wyatt
for
reviewing
it.
I
don't
know
if
we
have
enough
if
we
have
enough
reviews
of
it
so
far,
but
I
just
want
to
call
out
three
things
that
I
think
are
worth
discussing
right
now.
One
is
the
the
exemplars.
C
C
I
can
type
this
down
if
you
want,
you
want
to
share
your
screen.
I
I'm
not
I'm
not
looking
at
anything
useful,
sorry,
exemplar,
filter
what
measurements
actually
can
participate.
Yeah
I'll
share.
My
screen
give
me
a
second
I'm
afraid,
because
the
last
zoom
meaning
I
was
in
my
chrome
window
crashed.
C
So
if
I
disappear,
you
can
blame
chrome
and
that's
my
fault
anyway.
Here
we
go.
D
C
Cool
are
we
able
to
see
the
the
specification
yeah?
Okay,
so
first
off
in
terms
of
of
possible
contention
points
we're
going
to
focus
on
contention
points.
C
I
want
to
focus
first
on
this
notion
of
two
things
that
we're
going
to
expose
to
users.
One
is
an
exemplar
filter.
Okay,
the
minimum
thing
I
want
to
expose
is
actually
down
here
of
we'll
have
some
kind
of
a
configuration
parameter
where
users
can
say.
I
don't
want
any
measurements
eligible
for
exemplar
sampling
like
I
can
turn
the
whole
thing
off
the
next
one
is.
I
want
all
measurements
eligible,
for
example
our
sampling
and
the
third
one
is.
I
want
to
base
exemplar
sampling
off
of
sample
traces,
and
this
would
be
the
default.
C
C
It
makes
sense
to
me,
I
believe
I
have
if
you're
curious
as
to
the
mechanism
of
with
sample
trace
right
here.
C
We
have
the
notion
of
how
to
pull
the
span
context
from
or
the
span
from
context
and
on
the
span.
There's
this
notion
of
whether
or
not
the
span
is
being
sampled.
So
the
idea
here
would
be
we'd
pull
the
span
from
the
current
context.
So
we
check
if
it's
sampled
and
that's
our
mechanism
of
knowing,
if
it's
sampled
now
that
so
that's
that's
the
tie-in
and
it's
only
a
tie-in
to
the
tracing
api.
That's
all
defined
in
that
api,
so
there's
still
no
sdk
sdk
kind
of
coupling.
Yet
it's
just
api
usage.
C
Okay.
The
second
thing
here
that
we
would
expose
to
users
is
this
notion
of
the
reservoir.
Okay
and
the
reservoir
just
defines
an
interface
of
offer
and
collect
and
offer
is
here's
a
measurement
right
with
context.
So
I
have
the
value
I
have
attributes.
C
I
have
context,
and
I
have
a
timestamp
and
it
decides
whether
or
not
to
keep
the
measurement
and
then
collect
is
where
you
take
all
of
your
exemplars
and
return
them,
and
so
this
would
pair
with
the
aggregator
in
some
fashion,
where
the
idea
would
be
there's
going
to
be
a
exposed
interface,
where
I
can
construct
an
exemplar
reservoir
based
on
an
aggregator.
C
So
there
might
be
a
different
exemplar
reservoir
for
histograms
than
there
are
for
sums
than
there
are
four
gauges
right
that
I
don't
have
to
find,
because
I'm
waiting
for
the
final
aggregator
spec
so
that
we
know
what
will
be
available
to
users
because
it
could
be
as
aggressive
as
here's.
The
instance
of
the
aggregator
go
make
me
an
exemplar.
It
could
be
as
simple
as
here
is
the
name
of
the
aggregator
or
the
noom
or
whatever
give
me
an
example.
I'm
not
sure
you
know.
C
I
have
a
default
implementation
in
java
that
I
it's
the
naive
exemplar
reservoir.
It's
a
naive
reservoir
sampler.
That
literally
adds
in
a
probability
based
sampling
of
you,
take
a
random
number
from
one
to
the
number
of
measurements
you've
seen
and
if
that
random
number
is
within
the
length
of
samples,
you're
keeping
you
you
put
it
in
that
bucket,
it's
relatively
efficient.
It
does
a
good
job
of
grabbing,
a
decent
amount
of
samples,
and
it's
dead
simple
to
implement
like
absolutely
dead,
simple.
C
So
that
is
going
to
be
my
suggested
initial
implementation,
but
I
wasn't
planning
to
specify
one.
I
was
going
to
leave
that
open
for
sdks
if
they,
if
they
need
to
get
clever
or
if
it's
valuable
for
them
to
get
clever,
they
can,
if,
when
we
add
histograms,
I
want
room
for
us
to
experiment
with
like
the
default,
for
example
in
prometheus,
is
you
actually
sample
per
bucket?
So
you
you
take
the
last
value
seen
per
histogram
bucket.
A
I
have
a
question
so
like
is
this
supporting
a
stateful
template,
for
example,
I'm
trying
to
understand
like
if
I
I
want
to
define
a
rule
whenever
I
got
some
duration?
A
I
want
to
compare
that
with
what
I
already
trying
to
report
and
if
that
duration
is
even
longer
than
what
I
have
I'll
discard
my
current
my
current
sample
and
I'll
take
the
longer
duration,
but
it
requires
me
actually
some
states
and
if
the
exporting
cycle
or
something
like
happened,
I
would
like
to
be
able
to
understand
that,
because
I
I
don't
want
to
keep
remembering
everything
I've
seen
in
the
past.
C
Yeah,
so
the
reservoir
would
be
the
location
where
you
would
do
that.
What
so
what
this
design
has
is
in
the
reservoir,
I
would
offer
you
measurements
and
you
could
look
at
your
existing
state
and
say
what
determine
whether
or
not
you
want
to
store
the
new
one
or
just
drop
it
on
the
floor.
The
reservoir
gets
to
make
that
decision.
C
C
E
I
support
this.
I've
been
working
on
probability,
sampling
oteps
recently,
and
you
could.
You
could
also
correctly
count
and
convey
that
probability,
which
is
something
that
might
be
done
in
the
future.
E
I
to
me
the
interface
is
almost
identical
to
aggregator,
I'm
in
fact,
I'm
not
sure,
there's
a
difference
between
an
aggregator
and
this
exempar
thing
reservoir.
But
it's
fine
with
me.
If
they
are
called
named
def
named
differently,
they
do
need
to
be
composed
differently,
based
on
which
activator
is
being
used,
as
you
just
discussed
like
if
you're,
if
you're
a
histogram
with
explicit
buckets
you're
going
to
have
different
reservoirs
arrangements,
but
the
api
is
essentially
an
aggregator.
C
And
if
we
want
to
tie
those
two
together
in
some
fashion,
the
only
nuance
here
is
the
filter
right,
an
aggregator
needs
to
remember
all
measurements
and
exemplar.
We
have
this
filter
in
front
of
it
yep.
So
that's
that's!
That's
the
big
difference
between
the
two
and
we
could
actually
expect
them
to
have
the
exact
same
interface.
C
That'd
be
okay.
If
we
wanted
to
find
that
interface
and
then
tie
the
two
together
but
yeah,
I
also
my
aggregator
looks
way
different.
This
interface
by
the
way
is
only
used
in
synchronous
measurements.
The
other
thing
in
the
spec
that
I
don't
know.
I
think
I
called
out
this
does
not
see
asynchronous
instruments
measurements
at
all,
whereas
aggregators
would.
E
How
they're
used
is
differently
interface
wise,
they
feel
identical
to
me.
Yes,.
C
Yes,
yeah.
What
else
did
I
want
to
cover
here?
Because
that's
that's
a
good
point.
The
the
the
missing
bit
here
is
how
to
tie
between
this
reservoir
and
an
aggregator,
which
I
mentioned.
We
have
a
to
do.
C
For
the
most
part,
it's
possible
that,
as
attribute
streams,
you
know
get
added
and
removed
memory
might
shuffle
around,
but
for
the
most
part,
as
long
as
those
are
relatively
stable,
you
should
have
a
stable
amount
of
ram
consumption
and
you
should
avoid
gc
burn
and
churn,
or
you
should
avoid,
like
c
plus
plus,
you
know,
memory
cycles
in
in
allegations
and
delegations
and
that
sort
of
thing,
so
that's
a
should
again,
I'm
okay,
removing
that
and
I'm
also
okay,
removing
both
of
these
interfaces.
C
If
we
don't
want
to
specify
those
yet
the
thing,
the
thing
that
I
want
to
keep
is
effectively
the
notion
that
you
see
measurements,
the
notion
that
you
have
context
and
then
this
filter
config,
where
I
can
turn
it
all
off.
C
I
can
make
sure
it's
with
the
sample
trace
and
I
can
also
make
sure
it
sees
all
possible
measurements.
So
those
are
the
things
that
are
important
to
the
spec
everything
else.
If
it's
contentious,
we
can,
we
can
shuffle
around,
but
I
do
think
we
need
to.
It
sounds
like
we
need
to
have
a
discussion
around
the
reservoir
interface
and
aggregators.
So
maybe
that's
a
sign
to
step
into
the
next
topic
unless
there's
something
contentious
in
the
other
bits.
C
F
C
A
F
Yeah
so
may
aggregator
see
a
screen.
I
guess
if
I
can
figure
out
how
to
do
this.
F
I
don't
know
how
to
do
this.
Maybe
not
it
is
window
window
window.
I
guess
it's
this
one,
I'm
assuming
it's
this
one.
Do
you
guys
see
the
aggregation
measurement
processor
up,
yep?
Okay,
so
I
have
the
pr
out
and
for
the
most
part,
there's
been
some
conversation.
F
I
marked
those
all
resolved,
they've
not
come
back
and
right
now,
there's
no,
you
know
pending
items
except
for
one
open
question
about
unit.
So
the
question
to
the
community
is:
is
it
just
stall
or
are
you
guys
not
quite
ready
to
move
forward
with
approval
approval
of
it
or
is
there
just
more
conversation
that
is
not
being
recorded
in
the
pr,
and
so
I
don't
know
the
answer
to
that.
F
You
know
writing
on
it
and
just
tell
me
if
you
know
yay,
nay,
and
then
I
could
go
follow
up
with
the
people
to
see
how
to
resolve
those
particular
issues
I
mean.
Is
that
a
good
approach,
or
am
I
going
to
take
up
too
much
time
or
I
don't
know
what
we
want
to
do
here
so.
F
E
Opinions
I
can
honestly
answer
the
question
from
for
myself-
is
that
I
haven't
gotten
to
this,
because
not
not
because
I
was
stalling,
but
it
felt
like
1730
was
so
important
to
get
done.
First,
the
big
pr
that
riley
merged
last
week-
and
so
I
was
thinking
I'd,
get
to
this
before
today's
meeting
and
didn't.
But
I
I
it
is
just
lack
of
resources.
F
I
mean
we
could
give
people
more
time,
it's
also
a
option
as
well,
so
so
at
minimum
I
want
to
just.
C
Yeah,
I
actually
haven't
had
a
chance
to
respond
to
the
changes
so
actually
given.
Given
that
we're
looking
at
aggregation
measurement
processor,
my
major
concern
right
now
is:
I
don't
want
to
expose
that
interface.
I
think
we
shouldn't
expose
aggregation
measurement
processor
and
I
don't
think
there
should
be
any
busts
in
this
section
at
all.
This
can
be
guidance
for
like
how
you
could
implement
things,
but
we're
not
exposing
this
to
users,
and
so
any
kind
of
must,
I
think,
is,
is
a
little
too
much.
C
I
think
we
should
we
should
effectively
if
we're
going
to
talk
about
aggregators
and
how
to
configure
them.
That's
the
view
api.
That's
already
specified
if
we're
going
to
talk
about
how
to
instantiate
aggregators.
That
should
be
part
of
this
pr.
But
if
we're
going
to
talk
about
how
they're
wired
through
and
and
all
that
kind
of
junk,
unless
we're
planning
to
expose
measurement
processor
as
an
interface,
I
don't
think
there
should
be
any
busts
in
this
section
whatsoever.
F
C
Concern,
I
don't,
I
don't
think
we
have
to
spec
how
it
gets
activated.
I
think
we
can
spec
its
interface
and
we
can
spec
we
can.
We
can
give
guidance
on
how
to
implement
it,
but
I
don't
think
we
have
to
specify
exactly
how
measurement
processor
works
unless
we're
exposing
it
as
an
interface.
That's
what
I'm
suggesting
okay.
F
F
I
guess
I
don't
recall
you
know
the
the
expansion
and
the
collapsion
of
you
know
the
the
attributes
and
all
of
that
related
things
that
might
come.
You
know
that
might
come
up
and
the
aggregator
is
only
responsible
for
just
one
instance
of
those
and
how
to
take
the
measurement
and
do
aggregation.
So
so
that's
why
it's
split
up
in
the
two.
Now,
whether
or
not
this
aggregation
process
needs
to
happen
in
a
measurement
processor
or
some
other
thing
will
be
spec.
That's
you.
A
C
Right,
like
I
guess
so,
knowing
that
the
aggregator
only
gets
you
know,
measurements
particular
to
one
metric
stream
cool.
Yes,
that
can
be
in
the
aggregator
spec,
knowing
how
to
create
metric
data
points.
C
That's
specified
there
to
the
extent
that
we
are
going
to
expose
aggregators
for
users
to
override
we
need
to
specify
their
inputs
and
their
outputs
right,
but
we
don't
need
to
specify
the
means
for
how
to
implement
the
whole
sdk
the
right
and
that's
that's
where
so
so,
like
the
fact
that
you
have
something
that
you
know
keeps
track
of
this,
you
know
aggregator
instances
and
labels,
that's
great,
but
I
don't
think
that
has
to
be
in
the
specifications
kind
of
implied
like
we
know
that
we
need
that
on
the
one
side,
and
we
know
what
the
aggregator
interface
is.
C
So
I'd
like
to
focus
the
discussion
on
that.
The
specifically
you
know-
and
we
talked
about
this
a
little
bit-
the
implementation
of
aggregators
in
c-sharp
and
java
are
different.
I
don't
think
either
are
wrong.
All
I
want
to
know
is
what
interfaces
I
need
to
expose
to
users,
and
this
is
specifying
things
where
I
have
to
actually
go
change.
My
implementation
for
things
that
aren't
exposed
to
users
like
users
shouldn't
even
care
about
that
right.
C
C
We
should
think
about
what
it
means
and
what
it
looks
like
going
forward
as
well,
so
that
that's
that's
why
I've
been
pushing
on
this
pr
a
bunch
I
haven't,
had
a
chance
to
look
at
all
your
changes
from
my
my
last
ask
but
like
seeing
the
measurement
processor
with
mustang
there,
that
was
one
thing
I
asked
to
remove
right
like
I.
I
don't
think
we
need
any
of
that
for
this
specification.
F
Okay,
so
help
me
out
for
a
second
josh,
so
I
reworded
it
based
on
your
feedback
to
just
saying
this,
and
aggregator
must
again
the
contentious
word
here:
aggregator
must
provide
a
means
to
update
with
given
measurement
data.
Do
you
think
that
is
specifying
an
interface
of
some
form.
C
F
C
F
A
contention
then,
because
that's
what
it
has
right
now,
there's
no
other,
no,
no,
no,
no,
the
section
above
this
okay.
So
we
we
talked
about
the
measurement
processor,
so
I
think
I
will
we'll
we'll
let
riley
chime
in.
If
there
is
no
measurement
processor,
then
this
will
be
removed
and
so
forth.
So
absolutely
this.
C
Section
providing
guidance
for
implementation
is
fine.
The
musts
are
all
I'm
asking
to
remove.
Like
you
can
say:
hey
an
aggregation
measurement
processor
can
do
this.
This
is
a
recommended
way
for
sdks
to
implement,
but
none
of
this
needs
to
be
a
must,
and
none
of
it
exposes
an
interface
to
users.
That's.
C
F
Okay,
so
so
I'm
I'm
happy
to
remove
the
must,
because
I
I
don't
necessarily
see
that
except
you
know
so
so
I
can
remove
the
must
the
measurement
processor,
I
guess
that's
you
know
riley
will
tell
me,
you
know
whether
he's
going
to
include
the
measurement
processor
in
the
spec
or
not,
but
it
doesn't
need
to
be.
You
know
there
necessarily
okay,
then
after
that,
then
do
we
have
any
contention
in
terms
of
the
separation
of
work
between.
F
You
know
a
measurement
coming
into
this
thing
being
split
up
into
multiple
aggregators.
Do
we
have
contentions
on
that
portion.
F
Okay,
then,
do
we
have
contentions
on
the
aggregator
itself,
meaning
that
it
gets
some
measurement
data
and
it
you
could
collect
the
you
know
pre-aggregated
measurement
now
I
know
there
are
some
additional
details
here
that
some
people
wanted
in
terms
of
how
much
we
specify
the
details
of
the
aggregator
per
se.
Okay,
so
so
I
just
made
it
generic
and
so
here's
a
a
question
is:
what
is
the
scope
that
we
want
an
aggregator
to
represent?
F
Is
it
more
aligned
toward
a
singular
decomposable
function
like
a
main
aggregator,
a
max
aggregator,
a
last
value,
aggregator,
an
average
aggregator
or
on
the
other
spectrum?
Is
it
more
aligned
with
what
we
want
to
output
like
in
a
metric
kind?
Like
the
you
know,
the
sum
metric
kind,
which
may
require
one
or
more
additional
information
like
a
histogram
aggregator,
which
also
require
you
know
the
the
buckets
as
well
as
maintaining
a
sum
where
you
know.
If
we
had
the
discrete,
then
the
sum
could
be
from
a
different
aggregate.
F
C
I
I'm
a
fan
of
keeping
the
aggregator
tied
to
the
value
for
the
decomposable
value
function
or
whatever.
Just
because
again,
gauge
is
pretty
loosey-goosey.
Gauge
does
not
mean
last
necessarily
last
value
if
we,
because
that
would
limit
us
from
having
min
and
max,
I
think,
there's
a
reason,
we've
seen
say
in
the
java
sdk.
For
example,
a
bunch
of
these
aggregators
get
added
over
time
and
we're
planning
to
provide
this
limited
set
of.
C
You
know:
histogram
bucketing,
last
value
and
some,
but
we've
already
seen
other
aggregators
get
added
to
java,
and
so
the
the
question
in
my
mind,
is
you
know,
what's
the
usage
of
those
and
are
people
going
to
ask
for
them
and
how
can
we
provide
them
going
forward
to
the
extent
that
we
have
an
interface
and
a
way
to
implement
them
cool
that?
Can
that
can
help,
and
then
we
can
standardize
the
ones
that
we
think
should
be
shared
across
everything,
but
the
the
names
of
those
aggregators
are
these
decomposable
value
functions
right,
they're?
C
Not
it's
not
the
name
of
the
metric
that's
generated
because
there's
a
little
bit
of
a
divorce
between
those
two.
F
Yeah,
so
so
there's
a
bit
of
a
so
so
there's
a
bit
of
a
concern
that
relates
back
to
how
we
specify
the
view
then,
because
today
my
understanding
is
with
the
view.
Generally
speaking
per
view
statement,
you
can
only
provide
an
aggregator
one
right,
so
does
that
mean
that
we
would
create?
If
I
wanted,
both
a
min
and
a
max,
and
I
don't
have
an
aggregator
that
does
both?
I
just
have
a.
I
have
a
separate
decomposable,
aggregator
called
main,
and
I
have
a
separate
one
called
max.
C
Like
what
what
yeah
well,
what
metric
point
has
min
and
max
together
right
now
like?
How
would
we,
I
guess
that's
that's
part
of
my
problem
with
this
example-
is
you'd,
be
exposing
probably
two
gauges
anyway,
like
that's
how
you
would
get
both
a
minute
to
max.
C
F
F
So
the
question
then
is:
do
we
want
to
if
we're
going
with
decomposable
function,
then
we
really
only
just
have
one
metric
output,
which
is
to
say
then
more
work
needs
to
be
done
in
the
exporter
if
they
want
to
quote
get
a
bunch
of
these
aggregators
to
get
enough
information
to,
let's
say
fulfill
the
needs
of
a
histogram
metric
point,
because
a
histogram
metric
point
requires
the
buckets
as
well
as
a
sum
and
maybe
even
a
count,
because
the
count
would
then
be
a
separate
individual
aggregator
as
well.
So
so
that's
why.
C
I
don't
think
this
is
an
either
or
discussion
like
like
to
some
extent
the
there's
the.
What
are
the
names
of
the
built-in
aggregators
and
I'm
suggesting
those
should
be
these
decomposed
value
functions
then
there's
this
notion
of
should
an
aggregator
be
able
to
export
more
than
one
metric
stream
and
that's
kind
of
a
different
thing
and
and
kind
of
unrelated
to
what
the
default
names
are
for
the
default
aggregators.
I
would
suggest
all
of
our
default.
Aggregators
should
be
these
simple
things
related
to
the
value
function.
C
If
you
want
to
expose
an
interface
for
an
aggregator
that
can
do
complicated
things
and
then
users
can
opt
into
what
they
want
to
do.
That's
fine,
too,
that
this
that's
not
an
either
or
discussion
right,
if
the
if
the
interface
for
aggregator
allows
multiple
metric
streams
to
come
out,
that
is
like
orthogonal
to
what
should
be
the
name
of
these
default
things,
be,
I
think,
the
more
contentious
point
to
talk
about
if
we're
going
to
spend
time
here
is
around
the
exporter,
may
drop
metrics
or
support
delta
to
cumulative
conversion.
C
F
Yeah,
so
so
so
the
the
okay.
So
let
me
let
me
okay,
so
before
we
move
on
to
that
topic,
I
wanted
to
at
least
you
know
summarize
what
I
think
I
heard
and
and
what
I
think
the
spec
currently
has-
is
that
basically
we
we,
the
spec,
will
just
have
the
general
concept
of
an
aggregator
which
can
produce
one
or
many
metrics,
which
leaves
the
room
for
implementation
to.
F
If
they
choose
to
implement
a
very
specific
min,
only
aggregator
that
only
produce
one
metric,
they
could
do
that
or
if
they
want
to
have
a
more
complex
aggregator
like
a
histogram
aggregator
that
produce
more
than
one
metric
or
or
more
than
one,
they
could
produce
the
buckets
as
well
as
a
sum
and
maybe
even
a
account.
They
also
have
the
freedom
to
do
that.
F
In
addition
to
that,
we
have
guidance
in
terms
of
when
you
have
an
instrument.
What
is
the
default
aggregator
and
we
will
at
least
in
the
spec,
provide
for
the
first
set
of
default
aggregators
for
the
given
instrument
and
then
we're
good
with
that
I
mean
that's
what
the
spec
is
written
at
the
moment.
Do
we
have
more
feedback
comments
or
or
or
disagreement
on.
E
What
I
just
said,
I
want
to
say
that
I've
been
listening
to
all
this
and
I
I
keep
hearing
what
josh
said
earlier
is
that
this
sounds
like
an
implementation
detail,
and
I
made
this
mistake
myself
a
year
and
a
half
ago,
or
so
when
I
was
drafting
an
sdk
spec
draft,
it
had
what
we
decided
to
call.
This
was
a
reference
implementation
and
I
don't
object
to
calling
this
a
reference
implementation,
but
I
think
josh
might
be
right
that
we
don't
have
to
include
this
in
a
spec.
F
The
defaults
or
the
or
the
concept
of
what,
in
you
know
the
aggregator
with
the
multiple
metrics.
E
C
Yeah,
so
to
echo
that
if
we
want
to
specify
an
aggregator
interface-
and
we
feel
like
that's
necessary
now
for
user
flexibility,
that's
fine
to
the
extent
we
don't
need
to
specify
one.
I
think
your
bottom
table
gives
us
almost
everything
we
need
out
of
this
pr.
C
Now
we
just
need
a
way
to
configure
those
those
that
set
of
aggregators
and
views,
but
we
don't
need
to
specify
an
aggregator
interface
for
users
to
expand
on
aggregators,
possibly
like
that's
that's
a
big
decision
here
is:
are
we
going
to
allow
users
to
provide
their
own
aggregators
in
sdks
or
not,
and
if
we're
not,
we
don't
need
to
hash
out
an
interface
just
yet
we
just
have
to
hash
out.
How
do
I
configure
this
set
of
aggregators
for
views.
A
Yeah-
and
my
answer
is
for
the
for
the
first
release-
we
probably
want
to
scope
it
down.
We
don't
give
that
flexibility
for
user
to
write
their
custom.
Aggregator
we'll
provide
the
defaults
and,
depending
on
how
we
model
our
defaults
across
multiple
languages,
we
will
have
a
better
idea
how
we
can
model
that
and
allow
extensibility
and
that
work
extensibility
work.
The
interface
work
will
be
after
the
rewind.
D
Release
so
one
question:
would
we
still
have
the
concept
of
measurement
processor
exposed
to
public?
So
in
case
someone
is
not
really
happy
with
the
default
implementation
of
the
aggregators.
Can
I
just
use
the
measurement
processor
and
build
whatever
I
want.
A
It
makes
me
feel
like
we're
most
likely
we're
heading
towards
here
goes
the
list
of
the
default
aggregations
that
we
provide
out
of
the
box
from
the
sdk
and
if
you
want
to
use
the
view
here
goes
example
how
you
can
specify
that
and
most
likely,
I,
I
think,
we'll
start
by
each
view
will
only
allow
you
to
put
one
aggregation
type.
If
you
want
multiple
things,
instead
of
trying
to
make
a
composition,
you
have
to
specify
that
in
individual
views,
we'll
start
from
that
and
later,
if
we
learn
there's
a
performance
benefit.
A
A
So
for
this
pr,
I
think
most
likely
it
will
be
here
goes
a
list
of
things
like
mean
max
histogram
last
value,
whatever
thing,
and-
and
this
is
how
you
specify
that
on
the
views
and
give
some
code
example,
people
have
a
better
idea,
and
it
also
says
like
in
the
future.
We
might
allow
multiple
things,
for
example,
me
max
to
be
specified
on
the
same
wheel,
but
for
now
it's
only
one
and
the
ic
implementation
should
consider
that
flexibility.
A
F
Well,
yeah,
so
I
haven't
gotten
there
yet
and
how
do
you
know?
How
do
we
configure
an
aggregator,
but
I
assume
that
for
the
simplistic
version
one,
there
is
no
configuration.
It's
only
defaults,
which
includes
the
boundary
defaults
for
all
the
histograms,
so
the
user
does
not
have
the
ability
to
change
any
of
this.
It's
my
is
my
assumption.
A
C
Yeah,
I
just
want
to
echo
the
notion,
the
notion
of
focusing,
on
the
view,
api
and
like
the
default.
This
is
great
in
terms
of
like
how
we
configure
aggregators,
in
the
view,
api.
That
is
the
next
bit
that
we
need
and
it's
more
it's
about
the
configuration
we're
just
specifying
how
you
configure
aggregators
and
views
and
here's
the
set
of
here's
a
set
of
aggregators
that
you
can
configure
and
then
I
can
leverage
that
in
the
exemplar
spec
to
say,
here's
exemplar,
you
know
aggregator
matchups
right,
but
we
don't.
C
We
don't
need
to
specify
custom
aggregators
just
yet
we
can
add
those
later
and
they
can
follow
the
same
kind
of
configuration.
Mechanic
that
is
provided
in
spec
right,
but
all
we
have
to
do
is
configure
these
things,
not
not
specify
in
detail
like
what
the
interface
looks
like
and
where
it
wires.
It.
F
C
Yeah,
I
don't
actually
care
that
something
is
doing
that
I
just
care
what
the
configuration
looks
like
that's
it
like
like
what
does
that
configuration?
Look
like
that's
the
thing
that
we
specify
so
so,
if
you
think
about
the
spec
as
defining
here's,
the
inputs,
here's
the
outputs,
that's
it!
You
know
it's
like
what
is
the?
What
does
the
view
configuration
look
like,
and
what
do
my
metrics
look
like
when
that's
when
I
do
that?
C
That's
that's!
That's
what
we
need
to
specify
right
now.
We
do
need
to
get
deeper
and
like
this
is
all
good
stuff
that
we
should
get
into.
But
for
the
first
version,
it's
just
you
know:
here's!
Here's,
the
aggregator
configuration
around
the
view
and
here's
what
is
output
and
then
you
already
have
here's
the
default
aggregators
for
these
instruments
and
what
that
will
look
like.
F
Okay,
all
right
so
so
I'll
keep
this
default.
Aggregator
portion
I'll
wait
for
the
view
to
somehow
specify
how
to
pass
in
boundaries
to
the
view
configuration
and
then
for
each
of
these
default
aggregators
that
we
have.
I
will
just
have
these
short
write
up.
That
basically
says
enough
information
for
the
you
know,
submetric
point
and
done.
C
So
I
actually
want
you
to
specify
how
we
do
boundary
histogram
configuration
in
the
view
api
as
part
of
this
pr
like
if
this
pr
is
just
how
do
I
configure
aggregators
in
the
view,
api
that
that's
exactly
what
we
need
right
now,
so
I
actually
expected
that
to
be
kind
of
in
this
pr.
F
C
Yeah,
so
the
view
is
configuration
and
I'm
configuring,
my
aggregator
and
the
view
right
now.
We
defined
like
the
basic
shape
of
the
view
sdk,
but
when
you
look
at
the
aggregator
portion
of
it,
it's
kind
of
held
back
for
this
pr,
so
this
pr
can
go
in
and
flesh
out.
Here's
how
you
configure
a
histogram
aggregator,
here's
how
I
configure
last
value
and
here's
how
you
can
figure
some.
C
That's
totally
fine,
and
I
kind
of
expected
that
in
this
pr
of
here's,
what
that
configuration
looks
like
at
one
point:
you
had
like
newing
classes
right
and
that's
fine
that
that
bit
like
how
how
to
configure
the
view
api
is
the
important
bit
the
there
is
likely,
possibly
a
divorce
between
the
configuration
of
the
aggregator
and
the
actual
instantiation
of
the
aggregator.
So
I
think
there
was
a
bunch
of
comments
on
you.
Shouldn't
just
knew
the
thing
right
here.
C
You
should
knew
the
config
for
it
cool,
but
the
the
actual,
how
I
configure
aggregators
and
views
and
what
the
names
of
those
things
are.
That's
that's
what
we
want
out
of
this
pr.
F
C
Something
yeah
it
it
again:
you're,
that's
the
measurement
processor,
none
like
the
the
meta.
We
don't
need
the
measurement
processor
to
find
that
this
is
about
the
view
configuration
that
a
user
will
write
in
the
sdk
right.
So
if
we
come
back
to
like
if
this
were
based
on
riley
cl
and
you
had
access
to
where,
where
the
view
is
is
outlined,
you
could
go
in
and
have
your
here
are
the
default.
C
You
know
the
default
aggregator
instruments,
here's
the
names
of
the
aggregators
and
then
go
into
where
the
view
is
defined
in
the
spec
and
just
say,
and
here's
how
you
write
config
for
these
aggregator
types
of
view,
beautiful
that,
but
but
it
doesn't
belong
in
that
section.
That
section
is
how
to
wire
things
as
opposed
to
how
a
user
configures
it
right.
F
C
I
I
think
most
of
these
comments
are
in
the
pr
just
just
to
be
frank,
like
they're
they're
in
the
pr
right.
They
were
marked
as
resolved,
and
I
can
reopen
them
if
you
want
right,
but
they
were
in
the
pr.
G
I
I
also
took
notes
in
the
meeting
notes
with
most
of
the
comments
too.
If
you
want
to
refer
to
those
victor.