►
From YouTube: 2021-06-25 meeting
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
B
I
right
I
just
joined
the
gym
this
week
and
to
use
the
pool,
so
I
started
I've
been
swimming
again,
so
my
arms
are
tired.
B
Yeah
I'm
worried
about
the
fact
that
we
don't
have
air
conditioning.
B
C
C
C
C
A
Okay,
I
I
I,
I
think
it'll
be
a
little
bit
hard
for
us
to
have
the
discussion
without
two
josh's,
but
I'll.
Try,
because
I
I
think
john
has
a
has
some
strong
opinion
and-
and
I
I
think
he
has
valid
points-
I've
been
struggling
with
the
the
the
view.
Part
so
far
is
the
hardest
pr
I've
I've
experienced
since
I
joined
this
effort.
So
let
me
share
my
screen,
okay
and
so
for
folks
who
haven't,
haven't
been
able
to
join
the
previous
meeting
so
just
to
retype
for
the
for
the
view.
A
Pr,
we
have
multiple
questions
and-
and
there
are
a
lot
of
dependencies,
for
example,
we
have
the
aggregation.
If
the
view
is
not
specified,
then
we'll
take
everything
by
default.
If
you
specify
one
view
of
the
mode
just
take
that
and
all
the
default
one
will
suddenly
like
like
job
what's
the
behavior.
So
there
are
several
things
depending
on
the
future,
pr
which
makes
it
extremely
tricky
and
and
also
they're,
like
they're
ambitious
goal
like
we
want
to
be
able
to
send
it
through
multiple
pipelines.
It
should
be
configured
individually.
A
So
that's
why
it's
been
there
for
almost
a
month
and
I
think
we're
a
little
bit
stuck
so
I
I
try
to
break
down
the
topics
and
conquer
them
one
by
one.
So
far
I
think
I
probably
covered
80
percent,
not
100,
but
I
want
to
find
a
point
where
people
it's
not
going
to
be
perfect
because
there's
still
a
lot
of
things
to
be
to
be
fixed
or
to
be
documented
in
the
subsequent
pr.
A
So
I
try
to
find
a
place
where
we
think
the
existing
stuff
is
good
enough,
so
we
can
park
it
and
merge
the
vr.
So
there
there
a
lot
of
comments
here.
I
try
to
find
a
better
way,
so
people
prefer
me
to
go
through
the
pr
like
this
or
we
just
look
at
the
rendered
result.
A
I
I
would
prefer
this
pr
view,
because
I
think
here
everyone
developer,
you
look
at
the
pr
as
well.
It's
a
little
bit
tricky
if
the
comment
is
too
long,
but
I
I
think
that
might
work
better
than
the
rendered
one
so
I'll
go
through
that.
But
let
me
know
if
the
experience
sucks
it's
fine
by
me
and
it
looks
like
we
just
picked
up
the
josh.
A
Hey,
hey,
josh
yeah,
we're
talking
about
like
waiting
for
you,
so
so
before
I
jump,
I
think
he
stepped
away
his
camera.
Is
there
but
he's
not
in
view
yeah
before
I
jump
into
this,
I
want
to
know
if
anyone
has
some
small
like
data
model
topics,
because
I
think
this
topic
itself
will
take
the
entire
one
hour.
So
I
want
to
see
if
anything
smaller
than
we
probably
can
talk
about
that.
D
Actually
rightly,
I
do
okay,
I
just
merged
otep
149
in
the
last
few
minutes,
but
before
I
did,
I
wrote
up
a
new
spec
issue
because
I
don't
feel
confident
that
we
have
as
broad
a
consensus
as
we
should
given
the
late
arriving
question
about
open
histogram.
I've
summarized
it.
I
hope
we
can
make
a
quick
decision
at
this
point,
but
I
think
the
the
summary
is
a
bunch
of
experts
like
by
base
2,
of
course,
they're
computer
software
engineers.
D
This
is
a
question
about
whether
users
prefer
base
10
really.
So
let
me
find
that
number
for
you
and
then
I'll
shut
up
spec
level
issue,
1776.
D
I'll
put
it
in
the
chat,
and
then
I
that's
it
all.
I
had
to
say
thank
you.
D
D
This
is
the
question
about
how
we're
gonna
transfer
histograms
over
the
wire.
It's
also
a
question
about
which
libraries
we're
going
to
use
in
our
sdks,
although
they
are
separate
questions
and
maybe
we'll
discuss
this
at
a
wider
community
level,
somehow
in
the
near
future,.
A
I
my
my
personal,
take
a
lot
of
folks.
They
started
with
space
10.
I
think
it's
not
because
of
a
business
reason
or
something
they
must
use
that
it's
because
there's
a
lack
of
guidance
from
the
experts.
So
if
they
just
pick
something,
then
normal
people
would
pick
base
10,
but
if
the
guidance
from
the
experts
like
the
histogram
was
invented
by
experts,
not
by
like
normal
users
right,
they
start
to
follow
that,
but
there's
no
good
thing
to
follow
when
they
pick
base
10,
because
it's
straightforward
for
them.
A
D
B
D
I
felt
too
close
to
it
to.
I
did
write
my
opinion
in
the
issue,
though
I've
given
you
my
opinion
is
that
open
instagram
is
a
good
choice
for
us
with
a
slight
modification
that
I've
talked.
E
C
A
Okay,
cool,
so
I'll
I'll,
quickly,
read
through
and,
and
some
part
might
be
easy
and
if
you
see
anything
so
I'm
trying
to
use
this
as
a
live
pr
review
because
it
has
been
stuck
for
a
while.
I
want
us
to
resolve
as
much
conflict
or
at
least
discuss
about
different
opinions.
Here
then,
hopefully,
we
can
resolve
some
of
them,
so
I'll
go
through
here.
A
The
first
part
is
basically
copied
from
the
tracing
and
I
just
renamed
things.
So
I
think
there's
no
question
about
this,
and-
and
here
we're
saying,
the
configuration
must
be
solely
managed
by
meter
provider,
and
here
we
also
don't
have
any
conflict,
but
this
is
where
things
are
becoming
tricky,
so
whether
we
expect
all
the
configurations
to
be
available
at
one
shot
or
we
expect
the
dynamic
configuration
to
be
provided.
So
what
I'm
trying
to
do
is
I
try
to
mimic
the
behavior
from
the
tracing
spec
and
I'm
going
to
show
you
the
tracing
stack.
A
The
sdk
must
provide
the
configuration
at
least
when
creating
or
initializing
something,
and
it
may
provide
something
to
update
the
configuration
later
on
and
I
think
that's
the
right
balance
so,
instead
of
forcing
everyone,
for
example,
if
I
put
in
the
matrix
back
saying
the
configuration
must
be
available
at
creation
or
initialization,
then
later
we
decided
there
are
business
scenarios
or
we
have
smarter
ways
to
handle
dynamic
configuration.
It
will
be
a
breaking
change
and
we
have
to
scrap
the
spike
and
move
to
the
next
major
version.
D
I
felt
okay
with
it,
I
feel
like
if
we
want
to
be
language
lawyers,
we're
going
to
find
ways
to
understand
these
words
and
conflict
with
each
other.
But
I
think
your
intent
is
clear
and
it
looks.
A
D
I
was
in
the
go
sig
today
and
there's
a
related
question
that
came
up
at
the
spec
meeting
this
week
about
tracer
provider
and
there
was
a
legacy
in
open
tracing
which
basically
spam
could
tell
you
it's
tracer
and
open
tracing
and
then
when
and
go
the
way
go
contacts
happens
to
work.
This
pattern
was
carried
over
into
open
telemetry.
So
there's
this
in
the
go
sdk
this
thing
called
the
spam
has
a
method
named
tracer
provider
to
get
the
current
tracer
dependency.
D
It's
partly
because
go
doesn't
have
proper
dependency
injection
so
but
in
the
gosig
the
suggestion
was
that
we
should
talk
about
here.
Anthony
is
here
to
talk
about
that
too.
I
see
him
and
it
might
be
worth
discussing
a
little
bit
about
that
in
this
context.
A
A
A
A
So
I'll
I'll
try
to
quickly
go
through
view.
I
I
think
number
one
number
one
thing
is
you
can
have
you
can't
have
zero
view,
then,
by
default,
all
the
instruments
that
are
available
will
be
given
to
you
by
default
and
they
will
use
all
the
default
behavior
like
all
the
default
aggregation
default
name
unit
description.
Whatever
thing
like
the
attributes,
then
it
brings
the
question
I
cover
somewhere.
So
the
question
is
hey:
if
you
have
a
histogram
instrument,
but
that
histogram
instrument
is
not
providing
you
the
default
bucket,
what
do
you
do?
A
I
think
we
have
three
options.
One
is
we
tell
the
user
there's
an
arrow
and
and
like?
I
guess
that
was
the
the
idea
from
majority
of
the
folks
from
the
previous
meeting.
So
john,
you
were
not
there,
like.
You,
probably
missed
one
me
here,
but
here
I
see
a
point.
Like
john
has
the
question.
He
believes
that
if
you
didn't
specify
any
extra
configuration
you
just
take
all
the
instruments
even
for
histogram,
like
every
instrument,
they
will
be
able
to
give
you
something
meaningful
instead
of
blaming
you.
B
B
A
D
Understanding
is
the
reason
that
we've
been
talking
about
high
resolution
histograms
and
all
these
histogram
format.
Discussions
is
because
everyone
sort
of
doesn't
want
to
talk
about
histogram
buckets
and
that
they
would
prefer
if
something
could
just
be
not
a
question,
often
that's
either
accepting
high
resolution
or
it's
some
of
the
stuff
we've
talked
about
of
like
an
automatic
resolution.
That's
all,
I
think,
stuff
that,
technically
speaking,
we
do
know
how
to
do
so.
I
really
don't
think
we
should
spend
much
time
talking
about
mr
grandpa
there's
other
questions
about
views
that
involve
dimensions.
B
I
do
think
there
is
one
thing
we
need
to
agree
on
or
or
agree
one
way
or
another,
and
that
is
should
the
sdk
be
usable,
the
metrics
sdk
be
usable
with
no
configuration
or
not
whether
you're
talking
about
histograms
or
anything
else
like.
Should
you
be
able
to
start
it
up
with
no
configuration
and
my
opinion
is
yes,
it
should
be
able
to
be
concerted
up
to
no
configuration.
F
B
B
The
sdk
configuration
could
be
as
simple
as
new
sdk
done
like
I
don't
want
to
have
to
specify
like
look
up
histograms
and
figure
out
all
the
stuff
like.
I
want
to
be
able
to
create
an
sdk,
but
I
don't
want
to
have
to
configure
every
last
little
detail
of
it
in
order
to
have
something
that
functions
and
doesn't
break
my
app.
B
B
So
I
want
to
start
up
an
sdk
with
no
configuration,
so
it
has
no
exporters
associated
with
it
right
and
I
haven't
specified
it
that
it
that
it's
going
to
do
anything
necessarily
meaningful.
A
All
right
how
sdk
this,
if
we're
saying,
there's
anything
that
we
struggle,
we
don't
crash
the
app,
but
we
can
fail.
For
example,
we
have
failed
by
sending
some
internal
logging
and
saying
we
notice
that
there
is
a
histogram,
but
there
is
no
bucket.
We
have
no
health
idea
how
to
handle
that
so
we'll
drop
the
data
and
give
you
this
error
log.
Would
that
be
a
reasonable
balance
or
you
still
want
the
user
to
be
able
to
see
the
data
and
the
data
will
tell
them.
D
Value
in
the
go
sdk
prototype,
we
returned
errors
for
duplicate
instrument
registration
when
there
was
a
conflict.
I
think
that
was
just
about
it
like
if
you
tried
to
create
a
gauge
encounter
with
the
same,
you
know
aim
in
the
same
instrumentation
library.
Otherwise
I
think
we
have
hotel
library
guidelines
that
say
we
should
never
like
harm
the
user
essentially,
and
I
like
to
think
any
any
kind
of
errors
like
log
it.
It
becomes
a
an
output
rather
than
a
synchronous
problem.
A
That's
the
api
part
and
I,
I
think
we're
perfect
line.
100
agree,
but
here
we're
talking
about
the
isdk
side.
It
sounds
to
me
like,
if
you
specify
hey,
I
want
otlp
exporter
and
this
is
the
endpoint
and
you
pass
in
the
endpoint.
Instead
of
putting
an
ip
address,
you
put
some
random
characters.
I
think
the
exporter
is
going
to
a
slow
exception
and
this
is
also
allowed
by
the
spec.
I
think
the
spec
is
saying
on
instrumentation
side.
A
B
I
think
there's
a
difference
between
bad
configuration
and
no
configuration
right.
I'm
not
saying
that
we
shouldn't
crash
on
bad
configuration,
but
if
there's
no
configuration,
I
think
we
should
have
intelligent
defaults-
and
this
is
I
mean
this
this.
This
is
I'm
saying
this,
because
I
have
to
support
users
and
I
have
to
support
users
who
don't
know
what
they're
doing,
and
it
is
extremely
painful
if
the
default
behavior
is
going
to
be
to
crash.
A
A
If
they
don't
have
the
data
they
will
figure
out,
if
they
don't,
probably
they
don't
even
care
like
in
this,
like
in
my
scenario,
if
the
library
b
developer
either
histogram
and
the
user
didn't
care,
they
wouldn't
get
the
data
at
all.
If
they
got
something
strange
like
it's
a
min
max,
then
they'll
be
crazy.
G
G
That
only
cares
about
making
things
easy
for
users.
F
F
How
easy
do
we
have
to
make
it
do
we
do
we
have
to
make
it
such
that
there's
a
sensible
default
that
they
get
values
out
of
or
do
we
just
drop
it
on
the
floor
and
let
them
figure
out
why
they're
not
getting
the
data
that
they
might
have
expected,
and
I
think
that
probably
is
a
case-by-case
determination
right.
There
may
be
some
cases
where
there's
a
good,
easy
same,
sensible
default
that
everybody
agrees.
A
Okay,
so
so
john,
if,
if
I
try
to
meet
with
your
design
principle,
I
want
to
say
like
if
the
user
is
giving
a
default
configuration,
we
should
never.
A
B
Yeah
we
talked
about
this
last
week.
I
think,
and
it
does
have
some
defaults
for
instagrams
there.
I
think
they,
I
think
the
documentation,
I
think
josh
posted
it.
One
of
the
josh's.
I
don't
remember
whom
might
have
been
certh.
It
basically
is
the
default.
Histogram
configuration
is
designed
to
measure
what
are
normally
http
response
times,
which
is
the
most
common
thing
that
people
end
up
measuring.
D
Well,
I
feel
that
the
outcome
of
all
this
histogram
research
is
that
there
are
pretty
simple
approaches
that
you
can
use
to
get
a
fixed
number
of
buckets
that
which,
which
mostly
addresses
most
of
people's
concerns.
Like
I
don't
know
what
my
resolution,
what
my
values
are,
but
I
I
want
to
give
you
32
buckets
period,
and
these
are
these-
are
this
is
possible
today,
but.
D
Also
are
histograms,
where
you
can
say:
look
there
could
be
10,
000
buckets
and
like
it's
fine,
you
can
use
that
we're
pretty
compressible
too
so,
and
this
issue
that
I
just
gave
earlier
is
about
choosing
the
final
answer
here.
But
but
either
of
the
answers
gives
us
something
we
can
do
essentially
automatic
bucketing
and
I
think
that's
the
holy
grail
for
instagrams.
C
I
I
think
I
pretty
much
agree
with
everything
that's
been
said.
I
just
wanted
to
mention
one
pattern
that
we've
got
in
some
of
our.net
apis
around
tracing
libraries
is
that
by
default
they
do
not
throw
exceptions,
but
sometimes
that
can
be
awkward
if
you're,
the
user
and
you're
not
getting
the
data.
You
expect
to
get
and
you're
trying
to
diagnose
why
it
isn't
working
and
so
there's
a
there's,
usually
a
property
there
that
you
can
opt
in
to
having
it
throw
exceptions
back
at
you.
C
F
Yeah,
I'm
typically
a
fan
of
failing
fast
and
loudly,
because
I
think
that
developers
will,
while
they're
building
something,
often
notice.
Oh,
I
haven't
configured
this
it's
exploding.
I
need
to
go
configure
it,
but
I
understand
why
safety
first
is
also
an
important
consideration,
especially
given
the
the
conversations
we
had
earlier
about
you
know,
instrumentation
live
or
a
library
starts
to
become
instrumented
or
adds
more
instrumentation,
and
now
they're
triggering
some
code
path
that
you
weren't
using
before
and
you're
exploding.
F
That's
definitely
undesired,
so
I
think
having
that
switch,
that
you
could
turn
on
and
say
I'm
in
development
mode.
I
want
to
know
when
I've
done
something
wrong
or
not
done.
Something
could
be
very
useful.
B
A
A
So
I
can't
follow
up
and
log
on
issue
and
I'll
I'll
park
this
for
now,
because
this
is
out
of
the
scope,
at
least
for
this
discussion.
A
Okay,
so
I
think
we're
making
progress
good
so
going
through
this.
I
think
the
scenario
here
should
be
clear,
like
you
use
view
to
customize,
which
instrument
you
want,
which
one
you
want
to
ignore.
You
want
to
customize
what
aggregation
you
use
and
you
want
to
say
which
attributes
you
want
to
take
which
one
you
want
to
ignore
there.
There
are
questions.
I
remember
clearly
multiple
questions
regarding,
if
you
don't
want
certain
attributes,
but
you
got
them,
how
are
you
going
to
aggregate
the
value
for
some
like
for
some
instrument
type?
A
A
I
I
try
not
to
answer
that
question
in
this
part,
because
that
that
part
requires
us
to
define
the
default
aggregation,
behavior
and-
and
it's
not
documented-
and
it's
going
to
be
a
big
pr.
I
think
so
just
want
to
make
sure
I'm
not
ignoring
that
it's
just
it's
just
a
much
bigger
topic
than
this
pr
can
cover,
and
also
you
can
get
additional
dimensions
from
the
contacts
like
give
one
example,
you
want
to
get
something
from
the
baggage
and
use
that
as
a
dimension
any
other.
C
As
part
of
the
configuration
you
provide
to
the
view
you
provide,
you
explicitly
say
what
you
want
the
aggregation
behavior
to
be
in
that
instance,
you
know
you
say
I'm
going
to
throw
away
this
label,
and
that
means
I'm
going
to
get
a
set
of
values
back
and
then
this
is
the
function.
I
want
you
to
apply
to
merge
those
many
values
back
into
a
single
value.
Yeah.
A
C
B
And
riley
you're
not
trying
to
tackle
like
how
you
specify
what,
in
the
context
you
want
to
pull
out
and
how
you
want
to
get
attributes
out
of
it
like,
for
example,
you
have
the
example
of
baggage,
but
if
you
want
to
get
baggage
out
of
the
context,
there
are
apis
to
get
the
baggage
out
of
the
context,
and
there
could
be
other
things
in
the
context
that
people
want
to
use.
But
it
sounds
like
you're
not
trying
to
tackle
like
what
that
api.
That
configuration
api
looks
like
specifically
here.
A
A
Those
require
us
to
hammer
out
the
detail
and
probably
put
some
code
example.
I
I
think
if
I'm
trying
to
cover
all
of
them,
we
won't
be
able
to
finish
this
vr
until
this
year.
A
B
A
A
Okay,
so
the
the
next
thing
I
I
refactor
this
part
a
lot
based
on
the
feedback
from
josh
suresh.
So
so
the
meetup
provider
gives
the
user
the
ability
to
register
view,
and
I
try
to
categorize
that
based
on
the
feedback,
so
the
number
one
thing
is
the
identity
of
the
view.
So
this
is
basically
the
name
and
if
you
don't
provide
the
name,
we'll
take
the
instrument
name
and
this
name
will
be
be
used
for
the
out
for
the
output
of
the
matrix
stream.
A
So
I
clarified
it
here,
but
I
I
feel
uncomfortable
with
this,
although
I
know
a
lot
of
people
might
might
like
this
clarification.
I
have
this
question.
If
you
have
multiple
meters
and
they
have
different
versions
and
they
have
the
same
instrument
name,
we
allow
that.
So
you
can't
have
two
different
meters
and
they
don't
know
each
other
and
they
have
the
same
like
they
have
two
separate
instruments,
but
they
share
the
same
name.
A
Then,
when
we
export
the
data,
I
think
there
might
be
a
place
where
we
need
to
give
the
user
flexibility
to
say.
I
know
there's
a
duplicate
so
instead
of
reporting
this
as
full
bar,
I
want
to
put
a
prefix
or
post
fix.
So
in
this
way
the
output-
I
think,
by
default,
I
would
prefer
to
have
the
matrix
stream
name,
be
the
same
as
the
view
name,
but
there
are
cases
I
think
people
will
will
make
them
different.
B
A
Yeah
I
hear
you,
but
previously
we
struggled
with
this
as
well,
and
this
is
what
we
have
in
the
api
spec
so
far,
so
we're
saying,
if
you
have
the
same,
if
you
have
the
same
name,
used
multiple
times
for
the
instrument
under
the
same
meter,
we'll
screw
it
up
right,
we
return
an
arrow
when
the
instruments
are
under
the
same
using
the
same
name,
but
you
have
different
meters.
A
We
allow
you
to
like
we're.
Basically
saying
meters
are
isolated
from
each
other
they're
treated
as
a
separate
name
space.
In
that
way,
I
think
it's
safe
to
say
when
we
export
the
data
like
as
a
matrix
data
stream,
we
always
take
the
meter
name,
plus
the
instrument
name
as
the
as
the
resulting
matrix
stream
name.
For
example,
you
have
a
library
and
then
it
has
the
duration.
Then
you
have
the
dot
duration
or
something
we
wouldn't.
We
wouldn't
change
the
names
of
the
metrics.
B
B
B
I
have
one
question
while
he's
gone,
and
that
is
he
the
first
line
that
he
totally
glossed
over,
I'm
actually
not
sure
I
agree
with
was
that
meter
provider
has
to
allow
people
to
customize
views.
So
I
think
the
way
that
we've
approached
all
of
this
in
the
java
sdk
at
least,
is
that
you,
you
construct
those
views
as
a
part
of
the
configuration
of
the
meter
provider
and
then
it
is
locked
in
place,
and
so
you
can't
take
the
meter
provider
and
add
views
to
it.
B
B
Yeah
so
riley,
I
was
just
stepping
back
to
the
first
sentence
that
you
pointed
at
and
then
glossed
over
without
talking
about
it,
which
was
you
said,
the
meter
provider
must
must
allow
people
to
customize
views
or
to
add
views.
B
I
want
to
say
I
don't
think
I
would
implement
it
that
way
in
java
we
would.
We
would
create
a
meter
provider
with
all
of
the
views
registered
and
then
the
meter
provider
itself
would
not
allow
any
registration
of
views.
That
would
be
done
when
we're
building
the
meter
provider
from
configuration
or
from
what
the.
A
User's
doing
I
I
see
so
I
have
a
different
opinion.
I
I
think
when
you
create
the
meter
provider,
there's
a
big
part
about
the
multiple
pipeline
and
I
want
to
explain
a
little
bit.
So
if
you
have
a
meter
provider,
another
provider,
you
have
multiple
meters
and
instruments,
and
you
want
the
the
data
to
be
exported
to
both
premises
and
otl
key,
and
you
want
to
specify
hey
for
promises.
I
want
to
get
this
histogram
and
for
otl
I
want
these
two
counters.
I
have
different
purpose.
A
A
B
B
So
I
guess
I
would
say
that's
why
I'm
a
little
worried
about
this
language.
It
says
the
meter
provider
must
provide
a
way
to
register
views,
and
I
would
I
would
probably
rephrase
this
and
say
the
sdk
must
provide
a
way
for
register
for
views
to
be
registered
with
a
meter
provider
and
if
some
language
decides
they
want
their
meter
provider
be
mutable,
that's
that's
their
choice,
but
I
think
in
java
we
would
definitely
want
it
to
be
immutable.
D
D
We,
like
start
small
and
have
like
a
simple
configuration-
that's
not
dynamic,
because
that's
so
much
harder
to
get
dynamic
configuration
and
then
when
it
becomes
a
demand
and
there's
a
prototype
and
like
really
a
lot
of
interest,
then
we
can
do
something
like
that,
and
this
was
the
main
feeling.
Last
summer
there
was
an
intern
from
google
working
on
dynamically
configured
sdks.
It
was
just
way
too
soon
to
do
that.
B
Yeah-
and
I
also
think
there
will
be
a
lot
of
very
difficult
and
tricky
decisions
to
make
once
we
make
things
dynamic
like
how
do
things
happen
when
like
what
happens
in
the
middle
of
a
collection
cycle,
when
somebody
does
something
dynamic
like
how,
at
what
point
do
new
instruments
get
created
for
views,
et
cetera,
et
cetera,
like
I
think,
there's
a
lot
of
very
tricky
little
details
that
we
would
have
to
hammer
out
to
make
it
dynamic.
A
Yeah
totally
so
so
far,
I
I
I
think
no
one
has
a
clear
understanding
how
we
can
support
the
fully
dynamic
scenario,
so
we
we
want
to
start
from
static
and
all
my
ask
is
the
you
know:
spec
we
tell
people
static
is
good
enough.
If
you
want
to
explore
dynamic,
the
spec
is
not
going
to
stop
you.
So
in
this
way,
in
the
future,
we're
not
blocked.
B
Yeah,
I
think
that's
fine,
although
I
do
think
when
we
get
to
dynamicism.
My
guess
is
that
we're
going
to
it's
going
to
be
a
major
revision,
because
things
are
going
to
be
different
enough.
That
we'll
need
to
you
know,
rethink
a
bunch
of
things,
but
that's
just
a
it's
a
prognostication
based
purely
on
gut
instinct,
not
on
data.
G
Maybe
then
you
can
add
to
the
spec
a
comment
stating
that
in
the
future
we
this
may
change
so
that.
F
And
we
lost
rightly
again,
so
I'm
wondering
if,
if
just
changing
must
to
may
in
that
sentence,
does
what
we
need
right.
If
we
say
that
a
meter
provider
may
register
views
or
do
we
need
something
else
explicit
that
talks
about
if
a
meter
provider
can't
register
views
how
you
would
register
it.
B
I
think
just
saying
the
sdk
must
provide
a
way
for
views
to
be
registered
with
a
meter
provider,
and
then
I
think
it's
wide
open
for.
However,
people
want
to
do
it,
they
want
it
to
be
a
method
on
a
meter
provider
and
make
it
dynamic,
that's
up
to
them
and
if
they
want
to
have
it
be
part
of
the
media
provider
builder
which
we'll
do
in
java,
then
we
have
that
option,
because
the
sdk
is
still
providing
a
way
to
configure
views
on
the
media
provider.
A
Okay,
let
me
stop
sharing
my
my
video.
Probably
probably
my
video
driver
got
some
problem
keeps
crashing
on
me,
so
I
I
want
to
give
an
example.
Even
in
the
spike
you're
saying
this,
api
must
have
two
parameters
and
you
put
a
disclaimer
that
in
the
future
we
might
change
that
and
the
next
version
you're
saying
we
can
have
three
parameters.
That's
a
that's
a
breaking
change
for
the
spec.
You
have
to
bump
the
spec
version
from
major
version,
one
to
major
version
two,
and
I
won't
avoid
that.
A
A
B
A
You
can
see
the
conversation
here,
okay,
so
so
the
question
here
once
you
specify
the
view,
do
you
use?
Do
you
think
that
the
the
user
can
have
other
meter
or
instrument
created
and
and
even
after
these
things
are
created
after
the
view,
registration?
They
would
still
be
picked
up
by
the
view.
So,
for
example,
when
you
register
view,
I
think
they're
different
scenario.
So
from
john's
perspective
is
when
you
register
view
you're
saying
I
want
to
take
instrument
that
name
x
at
that
point.
A
It
might
not
even
have
instrument
x
registered,
so
the
view
will
sit
there
and
wait
and
at
certain
moment
some
library
got
loaded
and
they
start
to
register
instrument
x.
Then
the
provider
will
say:
okay,
let's
take
instrument,
tags
and
use
the
view,
configuration
and
start
to
handle
the
data,
and
I'm
worried
about
that
because
I
I
think
it
it'll
have
some
tricky
thing.
Like
you're
saying
I
want
instrument
x
and
a
certain
moment
he
got
the
instrument
tags,
which
is
a
histogram
and
you're
running
like
you're
happy
after
five
minutes.
A
B
B
F
A
I
have
a
question
so,
for
example,
if
you
have
a
main
class,
I'm
not
a
java
expert,
but
if
you're,
if
you
have
a
main
class
where
you
register,
like
you,
initialize
the
sdk
and
you
register
all
the
view,
and
in
that
class
you
have
a
dependency
on
some
other
classes
and
that
class
has
a
static,
initialization
function.
I
don't
even
know
if
java
has
static
in
their
situation,
but.
F
A
B
The
behavior
of
that
is
you're
getting
a
no
op
version
of
the
sdk.
At
that
point,
you
you
get
those
those
instruments
will
not
ever,
nothing
will
ever
happen
with
them
and
what
we
tell
people
is.
The
first
thing
you
have
to
do
is
set
up
your
sdk
and
if
you
need
to
do
that
in
a
static
initializer
in
your
main,
then
that's
what
you
need
to
do.
B
But
you
pick
any
instruments
that
are
registered
or
meters
that
are
asked
for
before
things
are
initialized,
do
nothing,
and
especially
we
don't
want
people
using
the
global,
and
so
the
only
way
they
could
do.
This
is
via
the
global
right
because
they
won't
have
a
handle
to
an
sdk
and
if
they
use
the
global,
we
explicitly
tell
them.
It
will
do
nothing
if
it
hasn't
been
configured.
A
Interesting
in
go,
we
support.
D
A
A
A
Okay,
so
so
let
me
summarize,
I
I
think
what
like
john
mentioned
this.
You
must
specify
the
isdk
and
configure
all
the
view,
and
at
that
point
you
will
have
no
here
which
instrument
exists,
because
all
the
instruments
that
can
be
used
by
this
sdk
will
be
registered
later,
and
in
this
way
we
can
like
we
cannot
validate.
If
the
user
put.
A
I
want
this
view
and
they
specify
something
like
this
view
should
be
a
histogram
and
there
is
a
bucket
and
later
the
instrument
is
saying:
oh,
I
gave
you
the
name
and
it
is
the
I've
done
counter.
It's
not
a
histogram
there's.
No,
how
way
we
can
at
the
view,
registration
point,
detect
any
error.
So
simply
we
have
no
idea.
So
that's
why.
A
Yeah,
I
I
see
your
point
and
and
later,
if
we
notice.
Oh,
the
the
view
register
is
different
from
the
instrument,
because
the
instrument
is
calling
the
api.
We
cannot
give
any
exception.
We
can
only
like
be
unhappy
and
lock
some
internal
arrow.
Probably
so,
there's
no
way
we
can
tell
the
user
is
screwed
up
besides
logging,
some
internal
error.
Well,
I
have
a.
I
have
a
flipped
thinking.
I
I'm
thinking
when
you
start
to
register
the
isdk
and
define
the
pipeline.
A
At
that
point
you
might
say
I
want
to
look
at
all
the
all
the
instruments
and
on
the
meters
that
are
already
registered
and
I'm
going
to
take
a
snapshot,
I'm
going
to
take
all
this
instrument
and
do
the
validation
to
make
sure
everything
is
okay.
So
if
you
register
view-
and
I
haven't
seen
that
instrument-
yet
I
will
throw
exception
at
you,
so
no
you
messed
that
up
in
this
way.
B
I
wonder
what
some
of
this
is.
Some
of
this
is
because
java,
like
the
class
loading
that
happens,
super
dynamically,
like
we
do
not
like
there's
the
java
runtime
has
no
idea
what's
going
to
be
loaded
by
the
user
until
they
make
calls
in
their
code
like
java
is,
is,
is
fundamentally
an
interpreted
language
and
it
does
not
does
not
load
any
class
until
it
is
asked
for
so
there's
no
way
in
java
to
know
what
instruments
might
hypothetically
be
registered
anywhere,
because
any
kind.
F
C
I
mean
to
me
it
sounds
like
a
place.
Sorry
go
ahead,
go
ahead!
Oh
I
I
was
just
gonna
say
I
mean
I
don't
know
if
this
adds
overly
much
complexity.
It
sounds
like
a
place
where
you
might
say
in
the
in
the
spec
to
say:
if
your
language
is
capable
of
providing
a
early
validation
mechanism,
then
you
are
allowed
to
do
so,
but
because
we
know
that
we
need
to
support
languages
that
do
this
dynamically.
B
C
D
Go
what
we
do
is
we
defer
that
until
that
first
stdk
is
installed,
and
then
at
that
moment
we
go
through
and
call
the
registration
functions
as
if
it
had
been
deferred
in
the
order
they
were
registered.
So
you
then
get
the
error
late
and
I
can't
remember
how
it
was
handled,
but
it
becomes
a
late
found
error
and
therefore
all
you
could
do
is
log
it.
I
think
can't
remember
what
happens
actually.
F
G
D
D
Yeah,
I'm
not
sure
what
else
to
add
about
configuration
files.
B
D
Right
there
was
a
second
motivation
I
had
when
I
was
working
on
this
actually
two
almost
two
years
ago,
which
is
that
in
a
stasd
environment
which
is
the
code
environment,
the
code
I
was
familiar
with
before
and
didn't
have
a
background
in
prometheus.
You
just
give
a
name
on
the
call
site.
I
got
a
counter,
here's
his
name
count.
I
got
a
gauge
here's
his
name
count
and
most
of
the
libraries
at
least
almost
every
library
you
find
for
statsd.
A
A
So
you
might
say
the
collector
will
get
something
called
fubar
and
this
should
be
a
histogram,
but
the
collector
later
might
get
something
which
is
not
a
histogram
and
it
can
complain
by
logging,
some
internal
arrow,
but
it
shouldn't
fill
at
the
beginning,
because
there's
no
way
it
know
whether
it's
wrong
or
not,
and
I
I
think
that
would
solve
the
the
concern
from
john
and
for
people
who
can
check
something.
I
I
think
just
for
sake
of
consistency.
A
I
want
to
avoid
the
situation
where
I
want
to
say
like
if
you
can
check
some
error,
then
you're
free
to
report
that,
but
you
cannot
then
keep
silent
in
this
way.
I
would
rather
say
you
keep
silent.
I
mean
register
view.
You
should
always
like
log
internal
error.
At
any
point,
if
detected,
there
is
a
mis
configuration,
but
you
should
never
throw
exception
or
terminated
application.
A
I
I'll
give
you
one
example:
you
register
view,
and
you
see
these
are
the
histogram
buckets,
and
these
are
the
type,
but
actually
the
the
data
type
is
not
going
to
meet
with
your
expectations.
For
example,
you're
saying
the
the
bucket
should
be
something
like
integer
like
you
give
all
the
buckets
anything
greater
than
that,
but
the
actual
instrument
is
using
a
double
which
is
like
far
like
bigger
than
what
the
integer
can
handle.
A
When
you
register
view,
you
have
no
idea
whether
you
can.
You
can
hold
all
the
data,
but
when
you
actually
receive
that
you're
saying
no,
that's
not
possible,
you
won't.
You
want
a
you
want
a
in
histogram,
but
instead
the
instrument
itself
is
giving
double,
so
the
number
could
be
much
bigger
than
I
could
report
and
there's
no.
However,
I
can
convert
that
double
too
long.
B
So,
at
least
in
java,
the
way
we
implemented
the
the
view
prototype
is
well
a
all.
Your
instruments
are
typed
entered
long
or
double,
and
when
you
register
the
view
you
have
to
specify
which
one
you
want
and
then,
when
somebody
registers
an
instrument
like
creates,
creates
an
instrument,
we
look
it
up
by
whatever
criteria
are
provided
and
if
there's
something
that
matches
we
use
it.
Otherwise,
we
ignore
it
like
if
somebody
tries
to
register
an
in
histogram
and
there's
a
view
registered
for
a
double
histogram,
like
just
nothing,
it'll
use
whatever
defaults.
A
B
So
we
also
remember
so
previously
there
were
no
histograms
right
there.
They
were
just
the
value
reporter
and
you
had
to
choose
double.
You
had
to
choose
double
or
long,
and
it
was
up
to
like
if
your
backend
didn't
support
it.
The
exporter
for
that
back,
end
needed
to
need
to
figure
out
how
to
convert
to
something
it
did
support.
A
Okay,
so
I
I
figured
like
we're
running
over
time.
Sorry,
my
zoom
like
like
sucks
today,
so
I
think,
even
if
we
spend
another
five
minutes,
we
won't
be
able
to
get
some
conclusion
here.
So
I'll
follow
up
and
change
the
pr
based
on
what
we
discussed
today
as
much
as
I
can
and
for
the
rest
of
the
issue
we'll
have
to
spend
more
time
on
the
pr
comments
thanks.
Sarah
use
views
are
complicated.