►
From YouTube: 2021-07-23 meeting
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
A
Yeah,
so
I
think
the
number
one
goal
of
this
meeting
is
to
see
if
we
can
finish
the
new
pr
this
week
and
I
I
think,
zhang
put
some
good
points.
It
seems
john
and
I
have
different
perspective
and
we
kind
of
understand
where
each
of
us
are
coming
from.
So
I
want
to
get
more
feedback
from
other
folks.
A
A
A
Think
about
if
this
is
the
sdk
meter
provider,
can
you
see
my
screen?
I
believe
yes,
yes,
okay,
you
can
you
have
meter
provider
and
you
don't
specify
any
view
when
you
configure
something
like
just
export
like
exporter,
we
we
haven't
figured
out
this
name
so
I'll
just
put
something
here,
for
example,
you're
saying
fullback
exporter
and
you
configure
the
thing
then
by
default,
you
will
look
at.
A
So,
for
example,
the
default
behavior
histogram,
you
will
have
histogram
with
some
buckets
for
counter.
You
will
get
the
sum
and
for
gauge
you
will
get
the
last
value
and
if
you
have
view
so,
you
have
provider
you're
saying
I
want
to
either
view
here
and
you're
saying
I
want
to
pick
like
I'll,
just
say:
temperature
and
then
you
can
have
some
configuration.
A
A
A
B
I
think
the
main
reason
for
for
my
wanting
that
is,
I
don't
like
things
that
happen
implicitly
and
that
are
surprising.
So,
as
a
user,
if
I
call
add
view,
I
don't
expect
that
also
disables
all
other
all
other
instruments.
I
expect
what
it
does
is
adding
a
view,
and
so
I
would
much
prefer.
If
you
want
to
disable
everything,
then
you
have
to
make
a
specific,
explicit
call
to
turn
everything
off.
A
A
C
D
F
All
if
we're
gonna,
if
we're
gonna,
have
like
we
want
to
remove
defaults,
then
we're
gonna
have
to
have
at
least
remove
defaults.
F
B
A
So
the
way
how
it
works
is
the
acl
is
a
list
of
policies,
so
you
you
can
either
give
access
or
reject
access
and
they
you
can't
have
give
reject
and
you
can
give
a
group
of
people
or
a
specific
security
id
and
the
way
how
it
works
is
when
the
folks
try
to
access
a
securable
object.
It
goes
through
the
list
and
you
see
okay,
this
is
josh
and
he
belong
to
this
group
and
you
want
to
give
access.
Then
I'm
going
to
give
access
to
josh
and
now
stop
processing
any
further.
A
So
here,
if
you
see
a
match,
then
stop,
but
if
you
don't
see
a
match,
then
you
continue
and
you
still
reject.
Then
you
reject
and
stop
and
if
nothing
matches
you
keep
going
until
you
see
a
match
in
this
way.
The
order
matters
and
I
think,
if
we
have
a,
we,
have
something
like
stop
anything
else.
I
struggle
with
this
because
it
seems
like
we
have
the
the
give
access
and
reject
access.
A
If
people
put
something
before
advil
they're
saying
I
don't
want
the
default,
should
we
always
pull
that
at
the
end
and
that
other
instinct
seems
to
be
like
a
challenge
to
me.
I
couldn't
think
out,
like
I
I
understand
where
john
is
coming
from,
but
if
we're
going
to
add
something
saying
I
don't
want
default,
I
think
that's
going
to
create
more
problem
and
I
couldn't
find
a
good
solution.
B
Why
just
having
a
disabled
defaults
method
on
your
meter
provider
builder?
Wouldn't
just
do
that
and
wherever
you
call
it,
the
defaults
are
off
and
the
only
things
that
are
explicitly
added
will
be
added.
Well,
I
don't.
I
guess
I
don't
understand
why
that's
a
why
that's
confusing
or
difficult
to
implement.
B
H
Hey
riley,
could
you
do
me
a
favor,
and
could
you
just
call
out
how
you
select
the
instrument
versus
the
renaming
of
an
instrument,
because
I
think,
maybe
that
has
something
to
do
with
it
in
terms
of
if
you're
going
down
the
list
of
rules.
A
It
wouldn't
because
later
the
sdk
will
check
and
find
the
mismatch.
So
I'll
give
you
one
example,
and
here
meetup
provider,
you
want
to
see
add
view,
and
here
you're
saying
the
instrument
name
is
x
and
I
want
the
output.
You
can
call
it
a
view
name
or
whatever.
I
call
that
output
just
to
be
very
explicit.
Then
you
have
some
configuration
and
then
you
can
add
another
view
saying
instant
name,
the
same
equals
to
x
and
I
want
output
y
z
and
because
we
don't
stop
here,
we'll
continue.
A
And
then
you
have
a
problem
here.
If
you
have
add
view
instrument,
name
equals
to
x
and
you
don't
specify
anything,
this
will
output
x
and
in
my
proposal
here,
if
you
add
a
view,
you're
saying
I
want
defaults,
so
you
basically
put
instrument
name
equals
to
anything,
it's
a
wild
card.
Then,
if
you
have,
if
you
have
instrument
x
x1
here
x,
you
would
still
try
to
map
to
x
with
the
default,
but
it
has
a
conflict
because
you
already
output
x.
So
this
one
is
saying:
no,
no,
you
already
have
x.
A
B
And
in
my
proposal,
those
last
two
calls
are
nonsensical
and
would
never
be
allowed,
and
their
api
would
not
even
support
such
usage.
B
A
A
B
A
Will
have
idiomatic
ways
of
doing
it
yeah,
but
then
that's
going
to
create
other
problems.
For
example,
people
might
say
I
want
this.
I
want
to
disable
all
the
histograms,
but
I
still
want
something
else,
so
you
can
see
like
it's
starting
to
become
asymmetric
here.
Everything
is
symmetric,
like
you
specify
what
you
want
in
a
very
consistent
way
here,
you
specify
what
you
want
and
what
you
don't
want
in
two
different
ways
and
if
you
want
to
say
I
want
to
have
a
callback,
I
only
disable
things
when
they
are
double
not
in.
F
I
I
would
say,
there's
a
look
at
a
different
way,
so,
instead
of
saying
disable
defaults
would
say
include
or
define
defaults.
So
when
you
construct
it,
you
say
I
want.
I
just
want
the
defaults
and
if
you
don't
want
the
defaults,
you
say
false
and
then
you
can
go
add
the
views
like
you've
already
got
there
riley
yeah,
and
maybe
we
have
helpers
that,
let
you
add
individual
defaults,
like
you
were
saying
with.
I
only
want
to
add
the
histograms
back
in
which
is.
F
B
A
A
Instrument
state
name,
so
you
only
want
instrument
name,
but
my
question
is:
if
people
want
to
specify
other
criteria,
they
will
challenge
you.
Why?
If
I
ask
for
something
I
have
to
specify
like,
I
can
specify
all
the
criterias.
But
if
I
want
to
say
I
don't
want
something,
I
can
only
specify
criteria
a
instead
of
b,
but
let
me
step
back
so
I
I
won't
be
able
to.
I
guess.
F
A
So
we're
saying
we
have
the
semantics
and
the
language
can
decide
whatever
they
want
to
do.
Do
we
feel
that
that's
going
to
give
us
a
bad
spot?
That's
exactly
what
I
was
going
to
say:
yeah,
okay,
so
we
still
want
the
spike
to
give
us
some
restriction,
but
but
we
have
different
thinking.
Okay,
so
let's
assume
we're
going
with
strong's
proposal.
A
B
Criterias,
I
think
that
we
we've
so
far
punted
on
the
defaults
question
and
I
think
it's
it
is
a
separate
question
than
views
right.
You
know,
I
don't.
I
think
we
can
say
how
to
specify
views
without
diving
all
the
way
into
how
the
faults
are
or
are
not
specified
or
what
they
are.
It
seems
like
it's
a
different
concern.
A
H
H
A
So
victor,
are
you
suggesting
that
we
have
a?
We
have
a
rule
and
action
is,
do
nothing.
D
Reminding
me
of
male
processing
rules
like
this
is
a
problem-
that's
totally
independent
of
telemetry
at
this
point,
but
I
I
I
just
feel
like
we're
spending
a
lot
of
time
talking
about
how
to
specify
rules
and
like
yeah,
you
can
order
them
and
you
can
have
them
halt
processing-
and
I
I
just
don't
know
when
to
stop
talking
about
this
and
move
on.
A
D
Here,
in
some
sense,
we
can
create
views
by
having
a
matcher
that
specifies
instrument
type.
Just
that's
all
you
need
to
say
like
for
any
counter
do
the
following.
So
the
real
concern
here
is
that
you
want
to
have
a
view,
that's
sort
of
conditional
on
whether
other
views
matched
and
it's
just
becoming
a
complicated
configuration
question.
B
A
B
Sure,
that's
very
different
than
having
explicitly
to
name
every
instrument
that
you
want
to
see.
Metrics
for,
if
you
like
configuring,
an
sdk
meter
pro
meter
provider
for
the
sdk
should
give
you
metrics,
like
I
shouldn't,
have
to
go
and
like
try
to
figure
out
what
instrument
names
might
be
in
these
random
libraries
that
I
pulled
in.
I
should
get
the
metrics
and
then
be
able
to
get
rid
of
them.
B
A
Up,
I
see
so
I
I
view
this
very
differently
from
you,
probably
because
we
work
for
a
different
company.
What
I'm
saying
is
nobody
is
going
to
ask
for
everything
by
defaulting
production
because
it
will
kill
them.
What
they
want
is
to
be
ex
become
very
explicit
about
what
they
need
and
they
will
get
anything
else.
It's.
B
A
B
I
know,
but
they're
going
to
try
they're
going
to
they're
going
to
do
one
at
a
time,
they're
not
going
to
go
and
turn
off
the
turn
on
10
000
posts
all
at
once,
they're
going
to
say:
hey,
let's
see
what
this
new
metric
system
about
we've
just
signed
up
for
vendor
xyz
we're
going
to
do
a
proof
of
concept.
Let's
take
one
tiny
little
pod
in
our
kubernetes
cluster
and
turn
on
some
metrics
for
it
and
see
what
it
looks
like
they're
not
going
to
turn
on
their
entire
fleet
without
trying
things
out.
B
It's
just
not
the
way.
It's
just
that's
not
the
way.
They're
gonna
do
things
and
then
they're
gonna
say
wait.
This
is
way
too
many
metrics.
I
don't
care
about
any
of
this
stuff
rather
than
they
turn
it
on,
and
they
see
nothing
and
then
they
don't
know
what
to
do,
and
they
have
no
idea
and
they
think
it's
broken
and
they
throw
it
away
and
they
go
do
something
else.
A
I
think
you're
talking
about
different
scenarios.
What
I
I'm
thinking
is:
if
you
you
just
by
default,
get
everything.
Then
you
have
no
control
about
the
underlying
dependency.
Whatever
thing
changed,
you
will,
you
will
be
punished,
you
will
take
the
consequence
and
as
a
developer,
I
would
want
to
be
able
to
control
what
I
got.
So
I
know
ahead
of
time
I'm
going
to
get
this.
Nothing
else.
A
So
this
is
where,
like
john,
I
talked
about
that
offline
and
I
I
just
think
like
we
should
stop
debating
here,
because
we
both
have
our
points
and
it's
very
hard
to
align.
I
just
think
like
a
simple
vote
would
help.
So
it
seems
like
people
here
are
in
preference
of
this,
and
we
just
have
to
hammer
out.
Where
do
we
specify
this
flag
and
do
we
think
it.
D
Actually
wasn't
saying
disable
defaults.
I
was
thinking
that
if
there's
two
different
like
types
of
configuration,
one
is
all
the
views
and-
and
they
all
may
apply
and
there's
no
like
bordering
and
stop
rule
or
anything
like
that
and
there's
just
like
a
description
of
what
to
do.
When
you
don't
have
a
view,
so
you
can
configure
all
your
views
and
then,
if
you
fall
through
all
your
views
and
nothing
matched
go
to
the
defaults
and
that's
a
different
configuration
and
then
you
can
just
say
what
aggregators
you
should
use
and
like.
A
D
Yeah
it'd
be
like
dot,
add
default,
behavior
and
then
spec
it
out.
I
guess
so
in
the
go
prototypes,
there's
something
called
the
aggregation
selector.
It's
its
job
is
to
choose
an
aggregator
when
you
don't
have
what
like.
A
Yeah
that
that
looks
good
to
me,
because
everything
is
added
here.
It's
very
clear:
you
follow
the
order
and
you
hit
the
rule
instead
of
you
have
both
positive
and
active
and
put
them
in
different
places,
and
also
I
like
it
because
you
have
a
consistent
interface,
see
whatever
you
add
here,
you
can,
you
can
have
the
same
filter
and
you
can
space.
D
F
I
might
be
missing
something
we're
going
to
have
more
than
one
meter
provider
right,
so
eventually
I
would
assume
would
have
different
vendors
providing
their
own
providers.
So
therefore,
wouldn't
it
be
a
case
of
up
to
whoever
is
providing
them
the
provider?
It's
a
bit
of
a
mouthful,
they
define
what
the
defaults
are
like,
riley,
you're
talking
about
the
defaults
or
everything
and
I'm
I
think
I
disagree
with
that
and
say
well,
no,
the
defaults
will
be
a
certain
set
which
will
be
documented
for
that
particular
provider.
F
G
B
So
nev,
I
think,
there's
a
little
bit
of
confusion.
A
meter
provider
is
an
is
a
sdk
api
that
the
the
sdk
will
be
providing
it
doesn't.
There's
not
like
a
different
implementation
per
vendor.
There's
one
sdk
meter
provider,
implementation
that
needs
a
support.
Vendors
could
provide
their
could
provide
the
right
version,
though
yeah
they
could,
but
the
api
won't
be
any
different,
though
the
api
needs
to
be
the
same.
Yeah.
A
I
agree
yeah,
I
think
that's
what
I'm
saying.
If
you
have
a
vendor
provider,
the
vendor
can
decide
I'm
going
to
give
you
all
the
defaults
or
the
vendor
can
decide.
I'm
going
to
give
you
nothing,
and
that
should
be
the
flexibility
and
the
isdk
shouldn't
put
a
restriction.
So
it
basically
say
language
client
can
do
whatever
they
want.
B
F
I'm
extrapolating
that
a
little
bit
further
in
saying
what
what
we'll
do
is
we'll
say
the
meet
provider
provides
a
certain
set
of
defaults,
so
the
implementation
of
said
add
default,
behavior
method
versus
a
flag
in
in
the
builder
or
the
constructor.
I
think
we're
talking
about
the
same
thing,
we're
just
saying:
how
do
we
define
that
we
want
to
include
those
defaults.
F
C
H
D
And
a
computer,
you
could
have
a
boolean
to
say
disable
default
behavior
and
what
that
does
is
tell
the
vendor
or
the
default
sdk,
whichever
it
is,
take
to
take
whatever
default
rules
and
turn
it
off
and
the
default
behavior
that
otel
specs
only
applies
to
default
sdk
and
we
we've
talked
about
all
those
standard,
histogram
buckets
and
all
that
stuff.
So
then
we
only
disable
hotel
default
behavior
when
all
default
sdk
is
used
and
you
disable
microsoft
default
behavior.
When
the
microsoft
behavior
is
used,
that's
sensible
to
me.
I
support
that.
A
B
I
mean,
of
course,
vendors
can
go
and
pre-configure
meter
providers
for
their
distribution.
Like
that's,
that's
just
a
given
for
the
way
open,
telemetry
works
right,
they
can
pre-configure
it
any
way
they
want
and
and
if
they
want
to
provide
additional
hooks
for
their
users
to
further
configure
it.
That's
also
fine,
but
that's
not
that's.
That's
outside
the
scope
of
the
spec,
I
mean
that's
just
the
way
software
works
right
opens
up.
Vendors
can
do
whatever
they
want
with
the
apis.
E
Okay,
can
I
have
two
questions
or
maybe
more
like
asks,
so,
no
matter
which
way
will
this
go?
Can
we
can
we
all
agree
that
this
behavior
must
be
the
same
across
like
sdks
for
different
languages?
E
E
I
want
to
see
it
as
a
developer,
because
the
first
time
I
will
start
my
service
with
open
telemetry,
I
will
have
zero
idea.
What,
for
example,
meters
can
I
choose
and
can
I
filter
out,
if
I
don't
need
it
and
what
are
the
names
of
those
because,
for
example,
if
I
am
using
a
third
party
I
don't
know
http
client
and
whoever
instrumented
it
I
mean
the
maintainer.
E
They
did
not
like
documented
that
I
even
have
no
idea.
I
will
need
a
way
to
by
default,
have
everything
so
that
I
can.
I
can
choose
like
what
do
I
need.
F
B
Who
is
going
to
be
making
recommendations
about
what
the
sense
of
thing
I
mean?
Who
is
even
going
to
be
in
a
position
to
be
able
to
recommend
defaults
based
on
arbitrary
libraries
that
are
out
there
in
the
world
that
people
have
just
instrumented,
with
whatever
yeah.
B
A
B
No,
but
nev
was
suggesting
that
there
would
be
some
recommended
set
of
defaults.
That,
like
difference,
are
there
would
be
various
different
recommended
sets
of
defaults,
and
I'm
asking
how
I
don't
I
don't.
I
don't
know
how
that
would
how
that
could
be
or
how
you
would
specify
that
or
what
what
it
even
would
mean
for
those
things.
For
that
to
be
something
yeah.
F
There's
probably
an
extension
on
that
too,
and
that
would
different
languages
want
or
require
a
different
set
of
defaults,
and
the
answer
is
probably
yes
like.
If
you
look
at
linting
depending
on
the
linting
library,
you
include,
they
come
with
a
different
set
of
recommended
defaults
that
you
can
then
go
and
configure.
F
F
But
yeah
do
we
want
to
define
at
the
spec
level
what
those
defaults
are
or
do
we
just
say
you
must
provide
an
old
one.
You
must
provide
a
recommended
set
and
then
we
leave
it
up
to
the
language,
slash
environment,
to
choose
what
the
recommended
set
might
be
and
then
like
what
I'm
thinking
for
extending
that
further.
You
might
have
then
have
a
you
know
when
you're
creating
new
instrumentations
new
meters,
new
histograms,
new
logics,
you
have
the
I
want
the
beta
set
of
values,
etc.
A
Yeah,
I
I
think
the
library
owner
will
ultimately
own
the
the
defaults
and
the
cemented
convention
can
give
some
recommendation
and
and
to
me,
there's
no
big
difference
than
we
say.
The
library
owner
will
give
the
default
recommendation
on
which
dimension?
Should
the
user
pick
like?
If
you
have
hdp,
you
have
10
dimensions.
The
library
owners
know
the
best
about
how
like
people
can
use
that
to
avoid
like
cardinality
issue.
B
A
F
C
I
I
don't
think
so,
though,
because
my
set
of
defaults
is
everything
that's
defined.
It's
it's
not
some
specification
of
a
view.
It's
give
me
all
of
the
metrics
or
give
me
none
of
the
metrics,
and
let
me
specify
my
own
or
give
me
all
the
metrics
and
let
me
specify
some
additional
ones
on
top
of
it
that
are
aggregations
of
those
metrics.
A
Okay
and
anthony
I
I
can
give
you
one
example
where
I
start
become
worried
about
this.
For
example,
you
use
two
libraries
and
those
two
libraries
are
developed
by
people
who
don't
care
about
the
others.
They
have
some
naming
conflicts,
so
they
have
the
same
instrument
name,
but
we
can
cover
that
because
they
have
different
meter
name,
they
have
different
meter
and
they
might
have
different
semantic
convention
url,
so
they're
splitting
in
their
own
namespace.
A
A
B
The
meter,
well,
I
don't
mean,
I
don't
think
I
I
don't
know
if
you're
any
suggestion
we
have
here,
that
he
even
comes
close
to
addressing
this
particular
issues.
I
don't.
I
think
we
should
punt
and
say
that
it's
a
bug
in
the
library
in
that
case
like,
let's
not,
I
don't
think
we
should
try
to
solve
the
the
developer,
does
something
very
like
pathological,
like
anyone
could
build
a
pathological
library
that
does
terrible
things
it
generates
like
goods
for
ever
all
of
their
dimensions
for
their
metrics.
A
B
F
Okay,
so
what
about
a
mixture,
so
we
say
during
construction.
We
say
this
is
a
set
of
defaults,
which
will,
if
you
don't
say
otherwise,
will
be
everything
as
part
of
the
definition
we
can
say
you
can
pass
in
a
different
set
and
I'm
not
going
to
find
what
that
set
looks
like
a
different
set,
whether
it's
a
name
or
whatever,
or
you
can
say
nothing.
F
B
B
This
is
the
way
I
think
about
it
in
reilly.
This
is
why
I
think
it's
really
important
that
a
view
as
a
selector
must
include
the
instrument
type,
because
the
defaults,
which
I
think
should
use
exactly
the
same
structure,
api
instrument,
selector
and
view
definitions
as
any
any
other
view
need
to
be
able
to
say
for
all
histograms.
Here's
how
I
want
it
to
look
as
the
default
yeah
we'll
cover
that
next,
so
I
think
it's
actually
very
tightly
interrelated.
B
I
think
the
fact
that
I
think
the
defaults
need
to
be
as
verbose
and
and
you
should
use
exactly
the
same
api
as
any
other
view,
I
think,
makes
it
mandatory
that
instrument
types
are
a
required
selector
for
views,
so
I
think
it's
actually
very
tightly
coupled
those
two
ideas.
B
D
B
I
think
if
we,
the
question
is,
if
you
need
to
override
the
default
behavior
of
the
sdk
and
say
that
all
histograms
should
have,
should
use
this
new
fancy.
Fancy
bucketing
binary
blah
blah,
whatever
base
2
thing
for
their
histograms,
rather
than
fixed
buckets
like
that's
a
that's.
A
programmatic
sdk
configuration
not
a.
D
B
B
B
Seems
fine,
I
don't
think
that
gets
us
very
far
in
view
configuration.
But,
yes,
that
seems
fine.
B
A
A
A
A
A
Yes,
here
yeah,
so
what
what
I
I'm
trying
to
say
is
I
I
think
type
can
be
a
filter,
but
I
I'm
not
saying
that
we
must
make
it
a
requirement
in
the
spec,
but
I
don't
feel
super
strong.
So
these
are
the
two
options.
I
just
want
people
to
give
a
vote
here
because
I
can
see
like
both
are
having
some
valid
points.
B
So,
just
I'll
give
a
little
bit
of
commentary
when
I
was
implementing
the
new
selector
in
java
logged
in
was
suggesting
that
we
don't
even
have
the
name
at
all
that
we
only
do
it
on
type.
So
I
think
think
type
is
super
important.
I
think
name
is
also
important,
which
is
why
I
put
them
both
in
there.
A
Yeah
I'll
give
some
context.
I
worry
about
type
because
I,
like
I'm
thinking
if
later
we're
saying
hey
like
duration,
is
not
good
enough.
Let's
add
a
timer
instrument
in
version
two,
then
it
will
be
hard.
If
you
use
name,
it
will
continue
to
work
because
timer
is
a
more
accurate
type
of
like
histogram.
If
we
use
type,
then
we
have
to
define
some
rule.
For
example,
do
we
match
the
exact
type
or
we
understand
the
the
inheritance,
so
we
can
match
the
child
classes
or
something
it
starts
to
become
very
complex?
B
A
A
B
A
B
B
A
F
A
H
H
C
B
Yeah
exactly
the
question
the
question
anthony
is:
does
the
sdk
need
to
support
both
of
them
or
can
riley
wants
to
make
it
so
that
sdks
can
choose
not
to
support
type
as
a
selective?
And
that's
no?
I
that's
what
I'm
disagreeing
with
they
both
should
be
optional
for
the
api
caller,
but
they
both
should
be
mandatory
for
the
sdk
implement
implemented.
C
A
C
Go
ahead,
I
I
think
that
it
has
definite
value
and
should
be
included
as
a
thing
that
sdks
must
implement
application.
Authors
are
then
free
to
not
use
it
if
they
don't
feel
that
it
has
value
for
them,
but
it
should
be
something
that
can
be
implemented
fairly
easily
for
the
sdk.
If
the
the
sdk
is
implementing
some
level
of
filtering
based
on
attributes,
right
type
is
an
attribute
just
like
name.
A
Yeah
yeah,
then
you
can
see
like
there
are
many
other
criterias
like
do
we
allow
integer
or
double
I.
I
think
this
is
a
perfect
case
where
some
languages,
they
don't
try
to
distinguish
integer
and
double
they
don't
care
about
strong
type
at
all.
So
this
might
be
some
flexibility,
but
you
see
the
instrument
type
has
something
that
we
should
make
a
first
class
hitting.
Is
that
correct.
C
B
I
mean,
I
don't
think
you
can
implement
an
sdk
without
being
able
to
detect
the
instrument
type.
Okay.
I
don't
think
that,
because
you
have
to
assign
aggregators
to
instruments
like
and
the
defaults
have
to
be,
there
has
to
be
some
sort
of
defaults
and
clearly
they're
going
to
vary
by
type
right,
so
yeah
every
language
should
be
able.
A
To
discriminate
on
type
and
the
type
should
be
optional
right.
If
I
don't
specify
type,
then
I
match
any
type.
Absolutely
yes
and
then
let's
come
back.
Currently
I
put
name
as
a
required
thing:
do
we
think
that's
optional
as
well?
I
think
it's
optional,
then
everything
is
optional.
So
do
we
think
if
we
we
have
nothing
here
or
we're
saying
you
must
have
a
name
and
if
you
don't
have
name,
then
you
must
have
a
type
they
can
like.
You
can't
have.
A
B
A
I
see
it
so
so
you're
saying
like
we
must
have
some
values
and
all
the
optional
parameters
they're
optional,
but
in
combination
there
must
be
something
instead
of
everything
is
missing
right.
I
think.
A
H
H
So
the
so
the
two
scenarios
right
for
example,
if
you
wanted
to
disable
by
default,
you
know
we
said
that
we
could
have
the
default
to
say,
select
everything,
select,
nothing
and
so
forth
right.
So
for
the
first
case,
if
you
just
want
to
by
default
disable,
if
you
don't
have
a
view,
then
you
have
this
rule
where
you
don't
have
a
name,
you
don't
have
a
kind
and
then
the
default.
You
know
for
your.
H
You
know
selection
for,
like
your,
I
guess
your
aggregator
whatever
it
could
be
like
something
like
no
or
none
or
something
that
will
automatically
match
all
instrument
and
default
to
nothing
or
the
action
to
be
nothing
or
if
you
wanted
to
change
all
instrument
to
let's
say
some
aggregator
then
same
thing
apply.
But
you
know
your
matching
rule
will
just
match
everything,
because
it's
kind
of
a
wild
card
and
your
action
would
be
take
the
default
or
only
use.
You
know,
histogram
right.
So
that's
kind
of
I'm
thinking.
H
Sure
sure,
but-
and
I
I'm
not
against
that-
I'm
just
saying
the
concept
of
quote-
you
know
having
a
standard
ad
view
that
acts
like
you
know.
If
it
here's
a
rule,
if
it
match
the
rule,
apply
this
and
that's
all
we
have
to
care
about,
and
then
the
users
can
use
just
that
simple,
you
know
method
to
define
any
defaults
or
non-defaults
or
whatever
they
want.
C
C
A
Okay,
I
have
one
final
question
on
this,
so
when
we
treat
it
as
a
fault,
normally,
if
there's
a
fault
in
the
sdk,
we
don't
blow
up.
But
here
if
people
set
up
meter
provider
and
they
define
something
that
really
doesn't
make
sense,
should
we
just
like
blow
up
the
application,
let
them
feel
fast
or
we
should
try
to
be
silent
and
emit
some
love.
In
the
background,
my
suggestion
would
be
blow
up
here.
Yeah.
B
I
think
I
think
it's
totally
fine
for
sdk
configuration
to
be
invalid
and
then
basically
have
no
like
have
have.
It
failed
to
start
up
like
right
now
in
the
java
sdk
like,
for
example,
if
they
haven't
included
the
prometheus
library
in
their
class
path
and
they
try
to
configure
prometheus
we
blow
up.
A
A
B
I
also
think
there
is
some
flexibility
here
for
what
the
idiomatic
behavior
is
for.
Language,
like
I
think,
go
apps
tend
to
fail
fast
and
blow
up
right
and
yeah
other
languages.
They
might
have
a
more
like.
No,
we
want
to
try
to
keep
operating
and
not
fail
fast,
like
that,
so
I
think
there's.
I
don't
think
we
necessarily
need
to
be
overly
prescriptive
here.
C
B
A
Okay,
so
we
concluded
this
and
two
topics
we
spent
one
hour.
So
I
have.
A
B
A
B
B
By
default
is
additive,
I
think
we
should.
I
agree,
I
think
it
should
be
edited.
I
just
think
we
need
to
specify
it.
We
need
to
make
sure
we
say
it.
That's
all
yeah,
I
think
if
we
try
to
make
it
or's,
I
think
it
will
get
very
confusing
very
fast,
and
I
think
that
and
handing
together
their
criteria
is
the
simplest
way
to
do
it,
but
we
also
have
the
the
thing
that
we
either
are
going
to
punt
or
not
punt
on
which
is
do
we?
Do
we
define
a
like
that?
B
A
B
A
B
B
Yeah,
that's
what
I
didn't
follow
that
this
is
that
paragraph
that
I
didn't
understand
what
you
were
trying
to
say
so
anyway,
we
should
make
it
very
clear
that
it
is
in
the
order
that
the
views
are
registered,
that
they
are
evaluated.