►
From YouTube: 2021-04-30 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
D
A
A
By
the
way
I
I
might
have
some
connectivity
issue
because
my
internet
went
down
twice
today
so
in
case,
like
you,
don't
see
me
all
of
a
sudden,
it
means
my
internet
is
done
again
and
if
that's
the
case
like
josh
or
anyone
else,
feel
free
to
pick
the
agenda
and
help
me
to
host
me.
I
don't
want
people
just
to
be
there
and
wait
for
me
and
well,
I'm
I'm
desperate,
so
wait
for
another
minute
before
we
start.
F
I
I
can
imagine
I
was
you
know
I
was
looking
forward
just
be
like
not
my
problem
and
then
I
run
away
with
other
people
that
are
smarter
than
me
solve
it.
A
Okay,
we
can
start
so
if
you
have
other
topics,
please
append
them
to
the
end
of
the
meeting,
and
I
will
probably
can
can
shrink
the
time
here
on
the
sdk
discussion
to
give
people
time
to
cover
your
topics.
So
first
I'd
like
to
give
the
update,
I
think
the
the
new
api
is
almost
there
like.
We
hammered
out
the
name,
although,
like
the
name
still
is
not
perfect,
but
I
I
think.
A
Finally,
we
got
the
agreement
from
many
folks,
which
is
great,
and
meanwhile
I
I
I
think
before
enough
may,
if
we
figure
out
any
better
naming
we're
still
open
like
at
any
time
before
we
mark
this
as
experimental.
I
I
I
want
to
open
the
door
for
people
to
say
hey
if
you
have
a
better
name.
We
should
consider
that,
because
this
is
important,
we
don't
want
to
go
with
some
regret
later,
so
give
people
a
month
for
those
feedback
and
I'll
bring
this
to
the
next
tuesday
meeting.
A
Ask
for
more
feedback,
basically
telling
people
we
think
is
almost
there.
We
give
people
a
month
before
we
announce
experimental
version
and
please
review,
and
with
that
I
I
I
think
the
last
pr
merge
this
skeleton
well,
a
lot
of
things
like
histogram.
I've
done
counter.
I
haven't
filled
in
the
details,
but
I
believe
the
details
should
be
very
similar,
like
we
just
take
the
existing
counter
or
the
observable
counter
description
and
do
some
renaming
and
change
stuff,
and
probably
I
can
organize
that
to
be
more
efficient.
A
So
we
don't
have
to
copy
paste,
but
I
have
seen
the
first
pr
on
histogram,
which
you
already
see
it's
very
similar
to
the
the
counterpart
and
please
take
a
look
and
if,
if
there's
no
other
suggestion
I'll
I'll
continue,
this
approach
so
expect
me
to
send
the
up
down
and
the
observable
version
of
I've
done
counter
in
each
one
of
a
separate
self-contained
pr.
So
that
makes
it
easier
for
people
to
review
and
approve,
and
and
after
all
these
are
done.
A
I
I
would
propose
in
early
may,
probably
like
the
the
first
week
or
the
second
week,
depending
on
how
we
progress
on
this.
We
can
flip
the
the
document,
so
we
rename
the
new
api
as
the
api
and
I'll
fix
up
all
the
link.
So
we
can
do
the
clean
up
here.
E
Just
I
I
have
a
quick
one
based
on
the
roadmap
that
you
published.
I
don't
know
a
month
ago
or
maybe
more
are
we
still
good.
A
Yeah,
I
I
I
think,
we're
on
track
the
ice
sdk.
I
expect
we
might
have
like
one
week
or
two
weeks
delay,
but
we
can
probably
try
to
scope
that,
for
example,
we
can
say
similar
like
the
api,
we
can
say:
hey
the
the
hint
api
is
not
a
party
for
now,
because
it
will
be
very
similar
to
the
vo
api.
It's
just
some
similar
video
api
but
exposed
from
the
api
instead
of
the
sdk.
A
So
in
the
sdk
we
can
probably
say
hey
if
we
have
a
scenario
where
we
won't
have
the
push
like
exporter
like
and
the
poor
exporter
to
coexist,
or
we
want
to
have
multiple
push
exporters
and
each
one
is
at
a
different
frequency.
A
A
So
how
about
we
park
that
in
the
brainstorm
session
like
later,
okay
cool,
so
the
next
one
is
something
we
discussed
this
tuesday
and
it's
related
to
the
start
time
pr
from
josh.
So
one
open
thing
that
we
we
discussed
briefly,
but
we
haven't
concluded
how
we're
going
to
handle
that.
So
I
want
to
see
like
if
there's
a
way
we
can
make
progress.
Either
we
decide
okay.
A
This
is
a
problem
with
knowledge,
but
we
don't
intend
to
cover
that
now
or
we
intend
to
solve
that
and
what's
the
timeline
or
we
think
this
is
something
we
can
come
like
solve
later
and
then
what's
the
expectation
here
so
the
the
scenario
is
you
have
a
up
down
counter
where
you
try
to
calculate
the
virtual
cue
like
you
have
a
queue
people
keep
sending
items
and
some
items
have
yellow
colors.
Some
have
red
color
and
you
report
an
increment
or
decrement
depending
on
the
scenario.
But
the
problem
is
the
instrument.
A
Is
there,
but
it's
not
enabled
at
the
very
beginning
of
the
process
and
the
process
has
been
running
for
one
hour.
You
can
imagine
when
all
of
a
sudden
people
enable
that
instrument,
they
want
to
say
I
want
to
collect
the
data,
you
don't
know
how
many
yellow
items
that
you
have
already
seen
from
the
queue.
So
what
you
can
report
is
only
from
that
start
point.
A
You
tell
people
I've
seen
like
three
new
yellow
items,
but
I
I
don't
know,
what's
the
start
time,
so
this
is
like
josh
summarized
that
as
we
can,
we
cannot
really
determine
a
good
start
time.
So
what
are
we
going
to
do?
Do
we
think
this
is
a
something
we
want
to
cover
from
the
api
or
we
think
this
is
a
corner
case.
A
I'm
trying
to
understand
that
so,
for
example,
if
the
application
is
running
and
we
keep
saying
yellow
and
red
items,
but
we
we
don't
have
the
exporter
and
the
processor
configured
and
the
application
is
running
and
all
of
a
sudden
people
enable
that.
So
you
consider
this,
how
can
you
enable
that
yeah?
So
you
consider
this
as
an
invalid
scenario
right.
I
consider.
G
F
F
We
have
tools
that
we
would
like
to
use
and
that
look
sort
of
like
perfmon
on
windows.
It's
basically
ad
hoc
tools,
you
just
you,
you
launch
them
at
any
time,
not
necessarily
the
beginning
of
the
process,
anytime
and
and
to
be
clear.
These
tools
already
exist.
So
we
can't
just
say
that
they're,
not
a
scenario
like
we
can
say
that
they
don't
coexist
with
this
one,
but
that
doesn't
eliminate
them
from
the
world.
F
G
B
F
G
Think
you
can
see
the
delta
since
you
enabled
so
what
you
can
show
is
the
absolute
value.
So
when
you
pre,
when
you
press
a
button
or
whatever
you
do
in
visual
studio
to
enable
grade,
you
start
from
that
moment
and
what
you
display
to
the
user
is
changes
since
that
moment
or
a
delta.
Since
that
moment,
and
that's
right,
we
don't
know
how
many
you
put
before,
because
you
did
not
report
them.
F
Right,
no,
no,
I
I
mean
I
get
the
technical
challenge,
I'm
just
saying
I
I
don't
think
that's
what
customers
are
going
to
expect
from
this.
Like
we
said
you
can
use
an
up
down
counter
to
tell
you
the
size
of
your
queue.
Like
we
didn't
say
you
use
it
to
tell
you
the
change
in
the
size
of
your
queue
since
a
specific
time.
F
We
just
said
it
is
the
size
of
the
queue
and
so
to
to
be
it
to
play
like
oh
well
in
your
monitoring,
dashboard
it'll
show
you
the
size
of
the
queue,
but
in
all
these
other
tools,
it
will
not
show
you
the
size
of
the
queue.
It
shows
you
this
other
thing
that
you
probably
don't
care
about,
which
is
how
much
did
my
queue
change
in
the
last
minute.
G
F
G
So
so
your
problem
here
is
that,
in
this
case
of
visual
studio
usage
right
people
will
not
get
what
they
expect
for
an
up-down
counter.
They
will
get
corrected.
F
F
To
know
like
to
know
that
in
the
last
minute
the
queue
grew
in
size
by
five,
but
you
have
no
idea
how
big
it
is
in
general,
I
I
would
assume
that's
not
the
information
that
they're
looking
for
and
that
it
feels
like
it's
not
living
up
to
the
promise
that
was
made
when
they
picked
to
use
that
type
of
metric.
To
begin
with,
I.
F
The
the
right
and
I'm,
and
so
I'm
happy
to
I'm
happy
to
adjust
our
guidance
to
users,
to
suggest,
for
example,
that
they
should
use
the
observable
one
instead
of
the
synchronous
one.
But
if
we
do
that,
then
it
becomes
have.
We
are
there
any
use
cases
remaining
where
we've
actually
intend
for
them
to
use
the
synchronous
one
or
have
we
now
just
instructed
everybody
to
go,
use
the
asynchronous
one,
and
we
don't
even
need
up
down
counter
anymore.
G
But
that's
a
good
question
for
me
for
me,
even
the
cue
size,
but
also
the
the
other
example
that
I
always
have
in
mind,
is
the
number
of
active
requests.
Indeed,
they
are
not
useful.
G
But
so
the
problem
is,
if
you
are
using
the
observable
version
right,
we
move
the
problem
of
always
counting
that
to
the
next
level,
so
somebody
has
always
to
count
this
if
you
are
using
the
observable.
So
so
because
because
it's
a
it's
a
state-driven
matter
right,
somebody
has
to
keep
the
state
it's
either
it's
either
you
in
perfmon
or
or
or
it's
somebody
else
option
could
be,
I
mean
could
be.
If
you
build
it
with
some
flag,
you
always
keep
that
state.
G
If
you
don't
put
that
flag,
you
just
show
people
delta
or
something
like
that
for
for
upgrade.
I
I
don't
know
I
I
understand
this
scenario
that
you
have
in
in
in
in
these
specific
case,
but
I
it's
not
it's
not
something
that
metrics
in
general,
when
people
are
looking
at
metrics
like
in
back
ends,
they
care
about.
F
F
D
Wait
a
second
if
there
are
cases
for
that,
they're
definitely
going
to
be
those
cases
and
it's
trivial
for
counters
and
histograms
and
all
the
observables.
It's
just
this
one
special
case
where
this
instrument
by
nature
is
sort
of
only
useful
if
you
start
counting
at
the
beginning,
otherwise
you're
forced
to
degrade
into
a
rape
interpretation,
which
is
you
know,
only
so
useful.
D
So
it's
it's
worked
for
me,
even
though
it's
degraded,
but
but
then
I
don't
actually
think
that
people
care
that
about
this.
Stateless
sdk
thing
that
much
that
they're
going
to
go
fully
stateless
and
turn
their
up
down
counters
into
such
things.
D
So
I
I
find
this
middle
ground
where
it's
like
almost
stateless
and
you're,
still
going
to
want
your
up
down
counters
to
keep
state.
I
just
don't
think
it's
that
expensive
for
us
to
maintain
up
down
count
state
and
just
not
export
it
like
the
cost
of
doing
that
from
the
beginning
of
process,
hopefully,
is
very
small,
and
this
is
also
a
reason
why
we've
talked
about
bound
instruments
in
the
old
api,
so
you
can
make
that
up
down
count
extremely
fast,
which
is
what
prometheus
does
and
then,
let's
just
not
worry
about
it.
G
F
It's
there
it's
there
for
any
build,
it's
I'd,
say
basically
think
of
it.
As
the.net
runtime
has
a
little
miniature
simplified
implementation
of
the
hotel
sdk.
G
F
G
F
F
F
F
F
Go
ahead,
so
it
sounded
like
you're.
You
know
it
sounded.
Like
your
suggestion
was
hey.
We
don't
think
the
performance
overhead
is
that
high,
and
I
mean
I
could
tell
you
it's
not
it.
I
mean.
There's
some
storage
and
there's
probably
you
know,
20
to
50
nanoseconds
per
operation
to
do
it.
So
I
guess
mostly,
I
just
want
to
make
sure
that
everyone's
going
to
be
comfortable
like
if
we,
if
we
continue
down
this
course.
F
G
F
F
Yeah,
okay,
but
that
then
I
would
have
I
mean
I
would
still
put
a
disclaimer,
but
maybe
now
it's
a
different
disclaimer.
Now
now
it's
the
disclaimer
that
says,
if
you
don't
opt
in
then
you
won't
be
able
to
read
these
values
from
these
ad
hoc
tools
and
if
you
do
opt
in
then
you
will
be
able
to
read
the
values,
but
there's
going
to
be
this
performance,
overhead,
correct
and
then
and
then
sitting
next
to
that
it
will
probably
be
a
little
sentence.
G
F
Yeah
I
mean
then
then
they
will
be
tracking
the
state.
Thems
I
mean.
Probably
they
can
track
the
state
themselves
even
more
efficiently
than
than
the
sdak
can
do
it
on
their
behalf.
G
G
That's
why
that's
why,
for
example,
it's
already
calculated
by
somebody-
I
always
encourage
people
to
do
the
observable,
like
don't
don't
recalculate
things
that
are
already
calculated
in
this
case.
But
there
are
cases
where,
where
things
are
not
already
calculated
like
the
number
of
active
requests,
because
I
don't
know
any
framework
http
framework
or
anything
that
shows
you,
the
number
of
active
requests
right
now
sure
that
that's
something
that
then,
then
you
either
calculate
you
use
an
atomic
variable
or
you
call
this
one
and
pass
the.
F
Okay,
so
it's
still,
I
I
guess
I
just
want
to
clarify
everyone.
Is
you
got
it
doesn't
sound
like
it
bothers
you
guys,
the
notion
that
net
would
have
a
asterisk
sitting.
Next
to
this,
this
particular
instrument
in
the
docs
that
is
kind
of
warning
people
that
maybe
this
is
not
what
they
want
to
use
and
they
should
go
use
that
observable
thing.
Instead,.
G
Yeah,
so
usually
it
doesn't
bother
me
and,
for
example,
maybe-
and
people
should
correct
me
if
I'm
wrong,
but
for
for
the
number
of
active
requests,
I
usually
recommend
people
to
actually
have
two
counters
one
for
started
request
and
one
for
ended
requests
just
to
see
because
then
you
can,
if
you
really
want
you,
can
calculate
the
the
difference
between
them
and
see
how
many
active
with
approximation
not
very
like
super
super,
statistically
correct,
but
with
some
approximation
you
can
get
that.
G
F
D
Okay
with
this
story,
you're
telling
noah,
I
think
what
I
would
probably
right
next
to
the
asterisk
is
saying
that
if
you
really
have
a
performance
concern
around
this
specific
instrument,
don't
use
it
go
use.
The
observable
form
count
your
own
cue
sizes,
and
then
it
will
only
cost
you
overhead,
when
you
need
it
straight
off.
F
G
Initially,
if
I
were
you
and
I
would
have
resources
to
to
some
kind
of
experience
and
user
research,
I
would
give
them
initially
without
that
and
see
and
see
if
they
complain
and
if
they
really
need
that.
That
will
also
help
us-
and
maybe
maybe
a
good
thing
for
us
would
be
this
way.
But
I
would
give
a
try
to
see
how
people
react.
G
Do
they
really
need
these?
Do
they
come
up
with
like
right?
You
skip
these
or
they're,
or
we
are
imagining
use
cases.
Okay,.
F
I
mean
I'm
happy
to
leave
the
up
down
counter
out
just
like
dotnet's
timeline
here.
Is
we
so
we're
planning
to
put
out
a
preview
api
of
this
spec
qui?
Quite
soon
like
we're
going
to
be
doing
some
api
review
in
our
official
api
review,
probably
in
a
week
or
two,
and
then
I
would
say
within
I
don't
know
if
it's
going
to
be
hopefully
within
may,
but
maybe
it's
a
little
later
there'll
be
a
preview
5
of
the
next
version
of
net,
and
it
will
have
these
apis
in
it
does.
F
Really
get
feedback
that
we
needed.
No,
so
adding
is
easy.
We
can
cert,
so
we
can.
Basically,
we
can
make
changes
up
through.
I
think
early
august.
Okay
is
not
too
bad
and
then,
after
that
it
would
become
very
difficult
to
make
changes
in
net
six.
But
adding
things
in
future
releases
is
also
not
a
problem.
Adding.
G
D
G
Leave
it
out
and
and
see
how
what
feedback
you
get
sure,
and
then
I'm
happy
to
do
that
as
long
as
you
have
time
until
august
re-evaluate
these
after
the
feedback
and
come
back
to
us
to
certainly
tell
us
what
what
you
got
yeah.
I'm
curious
because
I
mean
again
we
can
always
add
new
things,
but
removing
things
or
or
changing
behavior
right.
F
Yeah,
no,
if
we
once
once
it's
in
the
atleastfor.net,
it's
super
hard
to
get
anything
out
ever
so
yeah,
I'm
happy
to
just
leave
it
out
for
now,
and
we
will
gladly.
We
will
show
it
to
customers
and
we
will
see
what
they
think
and
then
I'm
happy
to
you
know,
report
back
anything
that
we're
hearing
from
them
in
terms
of
whether
it
meets
their
needs
or
whether
they
feel
that
you
know
they
need
more
yeah.
C
A
F
G
I
would
put
a
to
do
to
discuss
what
to
do
with
this
because
of
this
problem,
but
no
matter
what
I
think,
it's
very
important
to
collect
feedback,
and
if
we
have
this
of
this
option,
it
would
be
good
to
to
use
it
another
thing
that
will
be
useful
for
you,
and
maybe
I
don't
know
if
you
can
is
ask
people
if
they
complain
about
these,
ask
people:
how
do
they
feel
about
seeing
the
delta
since
they
enable
the
pool
or
stuff
like
that,
because
that
will
also
be
yeah.
F
A
Cool
thanks
era
now
the
last
topic,
so
we
have
30
minutes.
So
I'm
I'm
trying
to
work
on
the
sdk
spike
by
number
one
following
the
old
tab.
Like
scenario
try
to
see,
if
I
can
do
some
prototype
number
two
is
I
look
at
the
existing
implementations
like
python,
java
and
stuff?
So
I
now
I'm
hitting
a
list
of
questions
and
most
of
the
questions
are
related
to
the
scope.
Some
of
the
issues
have
been
there
in
the
spec
report
for
a
long
time.
A
So
I
I'll
share
my
list
of
questions
and
the
number
one
question
for
everyone
is
help
me
to
see.
What's
the
the
the
best
approach
you
would
prefer
like
like,
should
I
just
open
the
pr
and
put
all
the
questions
there?
Let
people
randomly
comment
or
we
should
go
through
all
types
or
I
should
ask
for
separate
meetings
we
discuss
them
through
and
and
once
that
we
can
go
individual
questions
see
if
we
can
get
quick
answer
for
each
of
them.
If
not,
then
I'm
happy
to
follow
up
on
whatever
people
would
prefer.
A
So
here
goes
the
for
people
who
want
to
take
a
look.
I
put
the
link
here,
so
this
is
a
skeleton
dock,
so
these
are
the
types
I'm
guessing.
We
won't
need
so
I'll
quickly.
Explain
this
thing
like
the
reason
we
have
meter
provider
here
is
because
meteor
provider
in
the
sdk
will
expose
more
interfaces
than
the
api,
like
the
api
only
gives
meter
provider
the
power
to
create
meter,
but
here
we
might
allow
meter
provider
to
configure
like
processors
exporters,
so
there
shouldn't
be
a
surprise.
A
The
view
api
is
something
we
allow
people
to
change
the
behavior
of
the
instrument.
For
example,
you
have
an
instrument,
saying
hey,
this
is
a
counter
and
there
are
people
saying
we
don't
need
a
counter.
I
just
want
a
histogram
or
something,
and
they
can
also
say.
I
only
need
these
three
dimensions.
I
don't
want
all
the
dimensions
or
they
can
say
hey.
A
I
probably
want
to
grab
one
extra
information
from
the
baggage
or
contacts
and
make
that
my
dimension,
although
that's
debatable
whether
it's
a
view
or
something
else,
the
measurement
process
is,
is
something
that
I
invented
that
term.
But
the
idea
is,
you
have
a
processor
that
takes
the
raw
data
like
when
people
report
a
measurement
from
the
instrument.
You
will
be
able
to
have
some
code
there,
so
you
have
access
to
the
contacts.
A
Otherwise,
if
you
have
the
processor
after
the
aggregator,
it
will
be
too
late.
You
don't
have
contact
access
and
the
metric
processor
is
something
that
goes
after
the
aggregator.
So
you
will
be
able
to
see
the
data,
and
this
is
the
place
where
you
take
the
data
and
potentially
you
can
call
the
exporter
if
it
is
exporting
processor
and
for
the
exporter.
A
I
put
the
concept
like
push
and
pull
and
the
pull
matrix
powder
is
mainly
used
for
premises.
The
push
one
is
for
like
console
or
something
else,
so
so,
first
that
this,
like
the
high
level
concepts,
make
sense
or
people
think
I'm
missing
some
important
high-level
items
or
you
think
some
items
here
are
not
needed.
For
example,
the
measurement
processor
is
something
we
we
haven't
talked
before,
or
at
least
I
haven't
seen
them
before.
G
G
F
G
G
G
F
G
It's
a
good
good
question:
if
we
really
want
to
give
this
powerful
thing
or
or
stuff
also
we
have
couple
of
users
of
these
and
I'm
happy
to
talk
to
anton
the
guy.
That
is
using
this
to
help
to
understand
if
they
have
other
requirements
or
just
extracting
the
baggage.
So
far,
I
think
was
just
extracting
the
baggage.
D
I
could
I've
talked
about
sampling
applications
or
where
you
might
want
to
customize
this
thing
that
we're
talking
about,
but
I
don't
find
them
to
be
very
to
find
much
traction.
When
I
talk
about
that
particular
path
in
the
hotel
go
prototype.
We
call
this
an
accumulator.
This
thing,
which
is
sort
of
the
part,
that's
responsible
for
the
high
concurrency,
the
synchronous
actions
and
getting
deltas
over
short
periods
of
time
computed
and
the
key
property
that
I
wanted
to
specify.
D
I
don't
care
about
the
name
very
much,
but
it
was
that
today's
prometheus
user
is
forced
to
remember.
Every
label
set
they've
ever
used
for
all
time,
more
or
less,
and
I
was
hoping
that
we
come
out
of
this
with
at
least
an
option
to
have
a
memory
like
a
forgetful
sdk
that
doesn't
accumulate
memory
over
time,
and
this
part
this
first
stage
of
whatever
we
call
it
the
accumulator
in
the
hotel
go.
D
Is
that
thing
that
is
built
very
carefully
to
both
support,
concurrency
and
support
for
getting,
and
so
in
the
the
the
four
parts
of
the
hotel
go
prototype
had
accumulator
processor
exporter.
That
was
the
data
path
and
then
had
this
controller
thing
that
was
like
push
and
pull
stuff.
So
I
just
want
to
call
that
there
was
one
more
part
there.
D
G
Fyi
in
java
measure
measurement
processor
is
before
accumulator
is
a
hook
on
the
synchronous
thing.
So
what
you
get
you
get
the
value,
the
labels
and
the
context,
and
you
return
back
the
value
and
you
return
back
new
labels,
I
think
or
something
like.
So
essentially,
we
were
allowing
you
to
say
you
can.
G
D
G
Anyway,
what
I'm
trying
to
say
is
also
the
accumulator
yeah
so
anyway,
what
I'm
trying
to
say
is
the
measure
processor
was
a
bit
different
than
the
accumulator
in
goal.
That
was
the
plan.
Okay,.
D
A
Yeah
so
so
it
seems
like
this
one
is
in
question
and
and
people
believe
we
need
the
vo
api.
So
the
question
is:
do
we
handle
baggage
and
contacts
in
the
view
api?
For
example,
you
can
specify
statically
this
view
will
take
a
baggage
called
like
riley
or
something,
and
this
way
we
probably
will
reduce
the
scope
here,
and
we
can
say
we
don't
have
this
measurement
process
or
whatever
name
we
decide
and
and
if
there
turns
out
to
be
a
high
demand.
We
can
always
add
that
later.
G
Yeah,
I
I
think
it
would
be
good,
I
think,
essentially,
in
an
ideal
world,
even
a
view
should
not
be
an
interface.
You
should
be
a
concrete
implementation.
You
are
allowed
to
configure
with
different
things,
but
yeah
complete
implementation
in
an
ideal
world.
G
I
think
people
should
be
able
to
customize
only
the
exporter,
and
maybe
maybe
what
we
called
in
java
is
aggregator.
Aggregator
is
a
small
interface
and
we
have
a
sum
aggregator.
We
have
a
histogram
aggregator,
so
people
can
build
their
own
crazy
aggregation
mean
marks
some
count,
average
blah
blah
blah
whatever.
D
When
you
start
to
talk
about
views,
it
becomes
a
little
overwhelming
because
you
there's
no,
it
doesn't
become,
as
modular
as
you'd
like
like
to
configure
a
view
you're
going
to
change
what
the
processing,
what
processing
is
done,
but
you're
also
going
to
change
what
the
measurement
processor
does
before
the
aggregators.
So
there's
like
this
they're
all
connected
and
so
like
you
can
imagine
an
sdk
in
the
future
that
has
a
yaml,
a
very
sophisticated
yaml
file.
D
That
says
exactly
what
you
want
and
that
sdk's
job
will
be
to
assemble
all
these
modules
and
components
and
processors
and
aggregators
and
accumulators
and
measurement
processors.
That
does
exactly
what
you
asked
for,
but
they're
all
interrelated.
You
have
to
do
something
up
front,
so
you're
not
dropping
the
data
that
you
need
downstream,
and
so
I
I'm
not
sure
it's
as
simple,
as
should.
G
Should
this,
should
these
components
be
exported
publicly
or
should
just
be
an
sdk
like
internally
in
sdk?
We
can
have
this
and
we
can
have
that
complicated
logic
of
combining
them
lego
piece.
Whatever
we
want
it's
an
implementation
detail,
but
more
or
less
the
question.
What
exactly
is
the
user
interaction
with
the
sdk?
I
think,
if
I
understand
correctly,
that
was
the
noaa
question
about:
should
user
override
this
should
user
be
able
to
touch
this
part
of
the
sdk
or
or
should
we
just
say?
Okay,
these
are
internal
details,
implementation
from
user
perspective.
G
A
A
So
my
suggestion,
like
I
didn't,
put
accumulator
or
aggregator
here,
because
I
think
if
you
have
process,
when
you
have
the
exporter
that
captures
the
what
the
end
user
should
definitely
see
and
all
the
other
stuff
can
be
part
of
the
implementation
and
if
it
turned
out,
we
want
to
expose
that
as
long
as
we
don't
expose
those
accumulator
as
part
of
the
spike.
For
now,
we
can
always
ask
the
sdks
to
expose
that
later
and
they
can
do
the
refactor
without
having
to
break
the
customer
unless
they
expose
it
publicly.
G
G
D
Yeah,
the
ones
that
we
have
in
go
are
like
install
a
prometheus
and
install.
You
know
install
a
pusher
for
otlp
helpers
that
are
like
one-liners
and
there's
a
lot
of
sort
of
specification
underneath
there
and
as
a
power
user.
D
Since
I
wrote
a
lot
of
code,
I
know
what
I
can
do
to
like:
configure
a
push
and
pull
exporter
at
the
same
time
and
install
special
processors
like
I
have
one
that
takes
a
histogram
and
turns
it
into
a
counter,
because
lightstep
doesn't
show
me
histograms
yet,
and
I
and
I
just
need
to
see
my
histograms
even
as
a
counter.
So
that's
like
I
can.
I
can
tweak
the
behavior
of
the
pipeline
because
I'm
I'm
a
power
user,
but
I
wouldn't
call
that
a
stable
api.
D
G
There's
an
option
for
that.
Definitely
we
should
support
that.
There
is
no
question
we
should
support.
Our
library
will
be
push
based,
so
we
will
push
things
from
from
the
from
the
sdk
to
the
next
layer,
most
likely
or
anyway.
We
should.
G
We
should
define
that
story
now
when
it
comes
to
the
power
user
that
you
are,
you
may
lose
your
power
for
from
for
the
initial
version,
unless
we
under
until
we
understand
better
what
we
give
to
the
power
users,
you
may
do
that
by
com
by
compiling
your
sdk
differently,
your
stuff,
but
for
the
moment
I
think
we.
D
Yeah,
I
don't
want
to
force
the
sdk
maintainers
to
like
maintain
these
internal
interfaces
that
power
users
are
using
to
get
what
they
want,
but
yeah.
I
guess
I
I
want
to
keep
my
powers.
As
you
say,
one
of
the
other
things
I'm
doing
with
this
library
is.
I
have
a
health
health
checker,
that's
reading
my
own
internal
metrics,
exactly
the
way
prometheus
would
and
I
don't
want
to
have-
to
parse
prometheus
exposition
format,
just
to
read
my
own
metrics
and
I
don't
want
to
put
up
a
otlp
receiver
either.
D
So
like
is
there
a
way
I
can
just
directly
access
my
own
metrics,
that's
the
kind
of
thing
I
want
us
to
do.
Eventually
I
can
lose
that
in
the
short
term,
fine.
G
D
Does
that
I
don't
think
maybe
I
mean
prometheus
is
a
is
not
a
push-based
exporter,
and
so
I
having
the
ability
to
do
a
pull-based
exporter
either
means
you
have
to
maintain
your
own
copy
of
metrics
or
you
have
to
be
able
to
access
the
current
state,
and
I
I'm
accessing
the
current
state.
Okay,.
D
G
G
I
saw
that
the
idea
for
that
was
because
we
will
have
to
define
our
formats
in
code
our
model
encode
somewhere.
The
idea
was
like
if
I
want,
for
example,
to
do
micrometer
to
otp,
I
will
make
micrometer
a
metric
producer
and
just
plug
into
the
export
pipeline
and
will
just
work.
So
we
can.
I
think
you
have
to
do
some
work
there
to
define
how
how
things
will.
G
A
A
Then
we'll
park
it
and
and
then
at
the
end
of
the
meeting
we
decide
what's
the
best
way
to
make
progress
here,
because
I
I
think
it's
there's
so
many
open
questions,
probably
a
word
document
or
like
like
google
doc
or
like
some
like
old
type,
would
be
helpful.
So
just
try
to
get
some
basic
idea.
So
so
first,
do
we
like
how?
How
do
we
describe
which
data
we
care
about
like
if
a
library
is
exposing
both
temperature
and
http
request,
duration?
A
In
case
we
don't
have
that
scenario
so
here
like
if
you
have
a
like
meter
provider
and
under
that
you
have
multiple,
like
meters
and
each
have
different
instruments,
and
do
we
expect
people
to
take
over
them
or
they're
able
to
say
I
only
want.
I
I
only
want
memory,
I
don't
care
about
anything
else.
I.
G
Think,
personally,
even
in
tracing
you
get
all
the
annotations
that
you,
the
library,
get
records,
correct.
You
get
all
the
spans
that
the
library
starts
yeah.
So
I
think
you
should
get
all
the
metrics
now
when
it
comes
to
do
we
calculate
all
of
them
or
do
we
export
all
of
them?
I
think
that's
where
the
views
will
answer.
A
G
A
D
I
think
we
should
export
everything
unless
there's
some
sort
of
filter
view
configured
yeah.
A
And
number
two
question:
do
we
think
we
want
people
to
know
what
instruments
and
meters
are
available?
If
I
got
a
library,
it's
a
black
box
for
me,
should
I
read
the
spike
and
document
or
I
should
be
able
to
use
some
like
api?
I
I
can
inject
the
sdk
and
use
some
api
exposed
there
from
the
application
to
say,
hey
give
me
a
list
of
instruments.
G
When,
when
do
you
want
to
know,
do
you
want
to
know
at
runtime
like
is?
Is
this
a
developer
that
writes
some
code
and
needs
to
retweet
is
and
makes
a
decision
based
on
this?
Is
this
a
person
that
runs
an
app
and
wants
to
see
what
are
my
metrics
right
now?
What
are
my
meters
doing
and
stuff
like
that?
More
like
a
debugging,
so,
okay.
A
It's
more
related
to
the
first
question:
it's
about
the
developer,
discovering
those
for
example.
If
I
like,
if
we're
saying
hey,
we
allow
people
to
specify
views
and
the
question
is:
I
want
to
specify
the
deals,
but
but
how?
How
do
I
know
which
instruments
I
have?
I
got
to
read
a
document
or
if
there's
a
way,
I
can
ask
the
isdk
hey.
Would
you
list
all
the
all
the
instruments
that
are
registered
then
I
can.
I
can
start
from
that.
A
G
So,
okay,
this
question
becomes
more
and
more
complicated.
For
for
for
thing
is
how
do
you
configure
a
view?
Do
you
configure
a
view
via
a
yaml
file
or
via
code.
A
G
B
G
Approach
that
problem,
then,
I
think
I
don't
think
you
need
a
list
of
instruments,
because
if
the
instruments
are
configured
with
views
and
they
produce
even
if
it's
a
counter
but
somebody
configured
to
produce
a
histogram
doesn't
matter
for
you.
If
I
tell
you
that
this
is
a
counter,
because
you
actually
need
to
know
that
this
is
going
to
produce
a
histogram
correct.
B
B
G
B
A
A
Okay,
I
I
see,
and
some
other
questions
just
try
to
poke
ideas
and
then
give
people
the
gut
feeling
that
this
sdk
space
we
have
a
lot
of
open
question
about
the
scope.
What
we
want
to
achieve
so
so
here
the
last
few
questions
about
the
exporter.
Do
we
think
we
allow
a
push
exporter
and
a
pool
exporter
to
coexist
on
a
single
meter
provider?
D
A
G
D
So
I
would
opt
for
just
there
there's
a
way
to
configure
the
default
output
for
every
instrument,
and
that
means
one
view
to
me
because
anytime
you're
going
to
add
more
than
one
view.
I
feel
like
there's
something
complicated
going
on
and
it's
going
to
be
really
complicated.
Yeah.
G
So
so
my
idea
was
that
you
have
the
default
view
installed
by
default
and,
if
you
install
another
one
replace
is
the
default
one.
So
the
idea
with
that
being
that
you
don't
anyway,
we
can
discuss
about
this,
but
in
general,
my
my
two
cents
on
this
are
simpler.
Implementation
that
can
be
extended
is
better
at
this.
D
Moment
but
okay,
another
another
point:
riley,
maybe,
is
that
I've
described
this
architecture,
at
least
in
the
go
prototype
where
there's
an
accumulator,
a
processor
and
an
exporter
and
every
one
of
those
layers
you
could
imagine
putting
in
a
like
multi
like
multiplexer,
that
just
copies
it
to
two
of
them
and
every
one
of
those
layers.
You
have
a
reason
why
you
might
not
want
to
do
it
there.
A
That
people
are
going
to
want.
You
know
when
I,
when
I
was
thinking
about
this,
it
looks
like
the
rendering
pipeline
like
doing
the
3d
graphics
yeah.
You
have
the
frame
buffer,
which
is
the
accumulator,
and
you
have
the
exposure
which
is
the
actual
device.
Okay.
So
so
some
quick
questions
here,
I
know
we're
running
overtime
a
little
bit.
So
if
we
have
push
metrics,
do
you
think
we
want
to
support
multiple
push?
G
I
think
I
think
I
think
this
is
this
is
very
interesting.
I
think
we
need
to
discuss
more
about
the
design.
I
I
don't
see
a
problem
to
support
these,
but
there
may
be
complications,
as
you
pointed
so.
A
It's
it's
needed:
okay,
okay,
cool
and
the
last
question
for
pool
matrix
is
powder.
I
I
think,
there's
an
issue
and,
and
at
that
time
most
of
the
folks
got
the
gut
feeling
they
don't
support
this.
So
let
me
say:
if
you
have
a
permissive
exporter,
that's
trying
to
pull
the
data
randomly.
For
example,
the
agent
decides
to
pull
the
data
every
five
minutes,
but
word
the
users
are
saying:
no.
We
don't
want
to
just
call
our
callback
based
on
that
one.
D
A
D
Feel
like
there
are
simple
approaches
to
those
things
you
describe,
though,
but
for
example,
when
you
say
multiple
push
exports,
the
most
the
the
one
you
might
be
thinking
about
is
the
one
where
you
push
one
second
intervals
and
then
somebody's
gonna
aggregate
those
again
into
ten
second
intervals.
Instead
of
pushing
one
seconds
and
10
seconds,
you
don't
yeah
like
there's
so
many
ways
to
approach
that
yeah.
G
Yeah,
so,
by
the
way,
pushing
a
different
frequency
is
super
critical
for,
and
I
I
have
a
good
example
from
google,
where,
for
example,
in
search
in
google
search
for
a
couple
of
metrics,
they
pushed
every
second,
the
metrics,
because
they
had
they
had
an
sla
of
or
they
their
whole
sla
or
the
whole
downtown
downtime
for
a
search
that
the
budget
was
30
seconds
per
year,
or
something
like
that,
so
they
had
to
they
had
to
to
to
report
some
of
the
metrics
super
like
extremely
granular
like
every
second,
but
definitely
they
did
not
need
to
export
cpu
usage
and
everything
every
second,
but
they
needed
to
export
other
things.
A
And
we
have
that
in
the
old
tab-
the
scenario
okay.
So
I'm
going
to
stop
here
and
by
default
I
I
I
would
prefer
to
send
a
google
doc
just
to
list
those
questions
and
my
expectation
is
number
one
you
give
me
your
vote.
Do
you
think
this
is
a
problem
you
want
to
address
or
not
and
based
on
that
I'll,
reduce
the
scope
and
bring
that
to
the
next
tuesday
meeting,
ask
more
like
maintainers
spec
owners
to
to
help
us
to
define
the
scope,
and
I
agree
with
spoken
by
default.