►
From YouTube: 2022-01-11 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
A
A
Okay,
let's
start,
maybe
we
share
my
screen.
Thank
you
for
joining.
We
only
have
a
pair
of
items
so
far
in
agenda,
so
let's
try
to
go
over
them.
The
first
one
is
regarding
service
name
and
weather
service
should
be
part
of
like
something
required.
Sorry
here
on,
the
left
here
are
very
very
interesting
comments.
Memorizing,
what's
situation
and
the
options
there
we
have.
We
have
job
people,
maybe.
C
Maybe
maybe
I'll
maybe
explain
my
comment
quickly
here.
It
seems
like
we
somehow
gravitated
towards
making
the
service
a
required
thing
in
the
telemetry
that
we
emit
using
the
sdk.
C
C
I
think
we
should
delete
that
from
the
from
the
from
the
specification
and
instead
and
since
because
it
was
added
because
some
of
the
formats
some
of
the
back
ends
require
it
and
it
should
be
a
responsibility
of
the
exporter
for
that
particular
format.
To
figure
out
what
to
do
when
that
information
is
missing,
can
fall
back
to
some
other
value
can
have
a
default
value
whatever
right,
it
should
be
the
exporter's
decision,
and
if
we,
if
we
remove
that
requirement,
then
we
we
open
up
the
possibility
of
having
alternates
there
right.
C
So
if
the
client-side
applications
don't
think
that
they
should
be
named
a
service,
then
they
can
make
their
that
choice.
I'm
not
saying
they
should,
but
we
open
up
that
possibility
and
then
it's
the
particular
workgroup's
decision
to
decide
whether
the
set
of
service
attributes
is
a
good
enough
set
to
describe
the
entity
that
they
are
modeling
or
not.
C
If
not,
then
they
can
introduce
another
set
of
attributes
which
may
be
called
whatever
up
dot,
name
or
whatever
right,
and
then
that
is
as
valid
to
including
the
telemetry
as
service
instead
of
the
service
right.
So
that's
that's
my
opinion.
I
I'd
like
to
see
what
others
think
about
this
and
well
that's
a
good
idea.
Now.
A
Yeah,
I
would
also
like
to
comment
that
part
of
this,
like
removing
or
deprecating
service
name,
would
be
to
have
a
notion
of
telemetry
source,
which
would
act
for
the
same.
You
know
for
for
the
other
one,
hey
john,
so.
C
To
be
clear,
I'm
not
advocating
for
that.
I
am
not
saying
we
should
remove
the
service
name,
I'm
saying
we
should
not
make
it
a
required
attribute
for
everything
that
is
emitted
by
open
planetary.
As
the
case,
it's
it's
most
likely
going
to
be
the
most
commonly
used
entity
for
for
the
telemetry
that
is
emitted
by
the
sdk,
but
not
the
required
thing
right.
That's
that's
what
I'm
saying
and
whether
we
need
something
more
generic
like
telemetry
source.
C
I
am
not
that
sure
about
that
right.
Maybe
not!
Maybe
I
think
we,
it
would
be
more
desirable
to
have
have
a
more
more
narrowly
defined
domain,
specific
entity
right
if
you're,
modeling,
client-side
applications
or
you're
modeling
mobile
applications.
C
C
It
is
it
models,
something
that
we
most
of
us
understand
as
being
something
that
runs
on
the
back
end
is
some
sort
of
logical
entity
which
which
which
functions,
and
then
it's
telemetry
stay
on
the
same
level
of
abstraction
and
try
to
be
similarly
specific
when
you're
modeling
something
different
like
an
application
that
runs
on
the
client
side
or
a
mobile
application,
or
something
that
runs
inside
the
browser
do
not
change
the
level
of
specificity
right.
Don't
try
to
generalize
more
here
again,
just
my
opinion.
D
D
The
main
reason
the
in
fact
the
sole
reason
service
name
is
required,
is
the
simple
fact
that
a
number
of
back
ends
break
if
they
don't
have
an
easily
identifiable
name
for
the
the
class
of
object,
they're
trying
to
model,
and
so
we
chose
service
name
as
the
the
required
field
that
back
ends
could
use
in
order
to
to
do
that.
That
sort
of
class
modeling
so
that.
C
C
F
So
in
ted
I
would
also
say
that,
respectfully,
this
is
not
overthinking
it
if
you're
a
client-side
developer,
and
you
tell-
and
I
have
to
tell
you
that
you
need
to
set
something
called
service
name,
that's
extremely
confusing,
because
if
I'm
a
mobile
developer,
the
service
is
the
thing
I
talk
to
on
the
back
end,
not
the
thing
that
I'm
writing,
which
is
an
app.
F
G
G
F
F
C
D
It's
it's
a
breaking
change
from
the
consumption
of
the
data
model,
which
is
another
thing
we
care
deeply.
C
D
C
D
Sure,
if,
if
we're
saying
like
another
possibility,
is
that
the
the
back
ends
need
a
field
and
we're
going
to
say
we
call
that
field
a
service
name,
because
everything
that
emits
data
is
service
in
our
lexicon.
But
if
for
ease
of
use,
if
developers
don't
include
service
name
but
include
another,
you
know
legal
set
of
identifiers.
We
construct
the
service
name
out
of
whatever.
D
They're
providing
us
in
order
to
allow
back
ends
to
have
just
a
single
field
like
like.
Basically,
the
question
is:
how
far
down
do
we
push
this?
You
could
say
that
the
sdk
does
this
you
could
say
rather
than
the
sdk
now
a
set
of
exporters
have
to
do
it
or
you
could
say
that
every
backend
that
consumes
this
data
has
to
has
to
be
searching
for
a
set
of
fields
rather
than
just
looking
at
the
service
name.
So.
F
Yeah,
so
I'd
like
to
call
out
that
the
two
I've
worked
on
two
or
worked
with
people
on
two
client-side
run
implementations
now
and
in
both
cases
the
back
end
was
not
the
same
as
the
back
end
that
consumed
service
data.
It
was
a
completely
separate
back
end
with
completely
separate
analysis
and
very
different
requirements.
F
D
D
But
two
of
how
many
like
I
mean
we
consume
mobile
data
and
application
data
front
and
application
data
all
the
time.
Like
I'm
sure
there
are
a
number
of
systems
that.
H
E
H
In
with
the
same
assumptions
and
and
statements
as
yourself
and
everyone,
there
feels
the
same
as
john
from
a
variety
of
different
backgrounds,
so
it
might
be
good
to
have
you
chat
with
them
as
well.
D
Yeah
I'm
happy
to
go
there,
I'm
just
I'm
trying
to
just
make
the
point
that
this
is.
I
feel
like
this
is
coming
in
and
saying
this
isn't
semantically
perfect.
So
we
got
to
tear
it
up
and
I
guess
I'm
advocating
for
the
the
simplicity
of
having
a
single
identifier
yeah.
It's
actually
important.
So
I
think.
D
Yeah,
if
we
want
to
modify
this
so
that
this
some
kind
of
field
gets
constructed
out
of
other
things
that
are
more
semantically
correct,
I'm
not
gonna
say
we
shouldn't
do
that,
just
to
be
clear,
I'm
just
saying
just
because
this
isn't
something
important
for
one
group
of
developers
doesn't
mean
it's
not
important.
That's
that's
what
I'm
trying
to
stress
here,
so
it's
the
elimination
of
having
a
single
eso
identified
field
that
that
I
want
to
push
back
on
that.
That's
that
to
be
clear!
D
I
I
Now
that's
been
the
default
for
a
long
time.
If
you
don't
have
a
schema,
url
we're
going
to
assume
that
you're
a
service.
But
if
you
give
us
a
schema
url,
perhaps
that
schema
url
will
say,
I'm
a
client
telemetry
producer,
and
now
we
know
that
instead
of
service
name,
you
should
see.
I
don't
know
app
name
or
whatever.
C
F
It's
interesting
josh
what
you
what
you
say,
though,
from
the
from
the
api
user's
perspective
from
the
person
who's
actually
acquiring
a
meter
or
a
tracer.
This
totally
makes
sense
right.
The
schema,
ul
url
is
fairly
opaque
and
if
it
had
a
some,
if
it
was
identifying
a
generalized
schema,
I
think
that
that
seems
like
the
viable
approach,
an
interesting
approach.
I
hadn't
thought
about.
C
Yeah
the
difficulty
here
is
that
you
don't
want
to
have
two
completely
different
schemas
for
the
back-end
services
or
for
the
front-end
services.
They
likely
share
vast
majority
of
the
attributes
right,
so
you
want
to
have
some
sort
of
base
schema
based,
open,
telemetry
schema,
on
top
of
which
you
build
like
client-side
schema,
which
was
something
that
I
had
in
my
mind
when
I
was
kind
of
designing
the
schemas,
but
ended
up
not
doing
that
not
having
that
in
the
current
specification,
at
least
so.
C
I
think
that
would
require
just
that
that
concept,
that
enhancement
of
the
schemas,
to
allow
some
sort
of
base
and
build
on
top
of
the
base.
And
then
your
thoughts
will
have
a
family
of
open,
telemetry
schemas,
which
are
related,
which
share
some
some
of
the
attributes.
But
then
there
are
differences.
That's
interesting
to
you
and
I
think,
there's
a.
F
C
F
C
But
yeah,
I
think
the
idea
is
interesting,
but
it's
still
in
the
same
direction
of
not
making
the
service
a
required
thing
right.
That's
that's
only
what
what
josh
you're
saying
is
is
a
different
way
of
making
it
possible
to
not
make
a
service
a
requirement.
It's
just
a
different
way
to
indicate
that.
I
Yeah-
and
I
think
I
can
see
the
other
side
of
this
argument
as
well-
everybody
serves
something
so
your
application
serves
the
user,
it's
a
server
server
for
the
user.
I
don't
know
that's
easy
for
me
too.
I
don't,
I
don't
have
a
problem
and
but
I
also
don't
want
to
go
to
instrument
to
client-side
instrumentation
meeting
to
talk
about
it.
F
Well,
I
mean
again
when
you
at
that
point
you're
just
talking
about
anything
that
emits
telemetry
and
if
we
want
to
define
service
as
anything
that
emits
telemetry
okay,
but
then
it's
really
kind
of
a
meaningless
word.
It's
just
a
generic
word
right
that
has
no
meaning
and
we
shouldn't
try
to
attach
any
meaning
to
it
whatsoever
other
than
just
the
source
of
telemetry
yeah.
I
mean.
F
Because
I
think
it
will
be
confusing
to
people
like
why.
Why
are
you
using
the
word
service?
This
thing
isn't
a
service.
Oh
that's
just
our
generic
word.
That
means
anything
that
admits
to
london.
I
mean
it.
Doesn't
it's
not
a
very
good?
It's
it's,
not
a
very
good,
compelling
reason
for
something.
In
my
opinion,.
I
D
No,
we
we
had
this
debate
again
here
and
the
the
general
feeling
is
that
in
a
microservice
world,
consisting
of
large
heterogeneous
systems,
everything
as
a
service,
including
mobile
services
and
web
services,
like
that's,
that
was
that
was.
D
Services
js
applications
can
be
a
service
like
it's.
That
was
our
feeling
was
that
that
was.
That
was
fine
to
think
of
all
of
these
things
as
service
and
not
not
say
ooh,
because
you're
running
in
the
browser
you're
like
a
lesser
citizen,
you
don't
get
to
be
a
service
like.
So
that
was
that
that
was
the
thinking
just
to
be
clear.
If
we
want
to
change
our
thinking,
that's
okay,
but
it's
not
that
there
was
no
thinking
that
went
into
this
and
we're
just
throwing
the
word
away.
But.
F
H
C
C
There,
which
adds
each
as
a
service
name
there.
G
D
D
F
No,
I
said
that
I
I
said
that
I
have
interacted
with
people
and
worked
on
things
and
I'm
trying
to
provide
my
concrete
direct
evidence
for
something
sure
that
contradicts
yours
yeah.
So
if
your
opinion
is
the
one
that
matters,
that's
fine,
let's
just
write
it
down
and
say
we're
done,
but
I
think
this
is
a
bad
decision.
D
D
Like
I'm
not
saying
we
can't
change
it,
I'm
just
trying
to
emphasize
that
that
there's
there's
a
lot
of
value
that
comes
from
being
able
to
use
this
single
field
as
an
index
right
now.
That's
that's
just
the
main
thing
I'm
trying
to
for
practical
purposes.
That
has
a
lot
of
value.
So
if
we
want
to
change
how
this
works,
that's
fine,
but
we,
I
will
just
want
that
aspect
of
it
to
be
respected.
That's
all.
F
So
so,
josh
certh
had
a
really
good
comment
on
this
a
couple
weeks
ago,
and
that
is
that
there's
also
a
cost:
an
education
cost
for
the
for
the
community,
not
the
people
who
are
working
on
the
spec
and
these
people,
who
are
deeply
deeply
ingrained
in
the
world
of
observability.
But
our
users,
our
end
users,
who
are
not
coming
in
here
with
a
huge
amount
of
expertise
and
experience.
D
D
F
F
I
wonder
whether
we
actually
should
separate
those
things,
because
what
we're
talking
about
here
almost
entirely
is
the
description
of
the
resource,
not
the
telemetry,
that
that
resource
emits
and
maybe
what
we
really
need
is
to
split
split
those
two
schemas
into
a
resource-oriented
schema
and
a
telemetry
oriented
schema.
I
mean,
I
know
the
resources
attached
to
the
telemetry,
but
the
telemetry
that
just
generated
by
a
resource
is
significantly
independent
of
the
description
of
that
resource
via
those
resource
attributes.
F
D
We've
talked
about
schema
and
schema
versioning
and
the
idea
that
the
collector
could
act
as
like
a
kind
of
translation
service
so
that
if
we
did
want
to
virgin
our
schema
because
oopsies
you
know
this
is
an
example
of
a
thing
where
we
would
want
to
version
it
right,
because
we
have
a
deeper
insight
into
how
to
model
something
and
we're
like.
You
know
what
our
old
model
was
too
simplistic
or
whatever,
but
we
don't
want
to
break
the
back
ends.
D
So
when
we
move
forwards,
we
want
to
be
able
to
do
schema
versioning
to
keep
our
new
stuff
backwards
compatible
with
the
old
stuff
and
as
long
as
the
new
stuff
can
be
converted
into
something
that
doesn't
break
the
old
stuff.
That's
a
viable
path
forward.
So
we've
been
looking
at
that
in
the
instrumentation's
sake.
But
the
thing
that
has
made
me
nervous
is
it's
just
theoretical
right
now
we
don't,
we
don't
actually
have
this
capability
built
in
to
the
collector.
We
assume
we
can
do
it,
because
the
collector's.
C
D
It
would
be,
I
would
feel
better
in
general,
tackling
these
kind
of
schema
translation
problems.
If
we
could
then
go
write
a
test
and
and
like
do
it,
you
know
what
I
mean
that
that
would
make
me
that
would
be
helpful,
also
for
the
instrumentation
zig,
because
we're
you
know
we
we're
we're
thinking
about
similar,
similar
issues
for
for
other
domains
like
messaging,
for
example,.
F
So,
just
before
we
move
on
there's
one,
there
is
a
com,
I
don't
know
if
it's
complicating,
but
there
will
be
a
a
consequence
of
choosing
to
say
service
means
anything
that
emits
telemetry,
and
that
is
that
we're
going
to
start
attaching
a
bunch
of
attributes
into
service
name
space,
which
will
make
very
little
sense.
Yeah,
like
browser
version
and
browser
name
and
things
like
that
and
it's
gonna
look.
F
It
will
look
very
strange
to
say
service
dot,
browser
name,
those
those
don't
need
to
go
into
the
service
name
space,
though
do
they.
Well,
we
just.
F
Everything
is
a
service.
Well,
the
service
name,
space,
isn't
the
resource
right.
That's
where
that
the
service
name
space
lives,
is
a
part
of
the
resource.
G
F
Identifies
the
resource
needs
to
be
prefixed
with
service.
No,
but
if
we're
saying
that
everything
admits,
telemetry
is
a
service,
and
this
thing
describes
the
service
describes
the
emitter
of
telemetry,
then
browser
version
and
browser
name
are
going
to
be
in
there.
Otherwise
we're
going
to
have
this
weird
thing
where
we
have
this
other
namespace
that
doesn't
have
a
name
and
then
somehow
we
have
to
look
over
at
service
to
see
what
the
name
of
the
thing
is.
G
E
D
But
but
regardless
I
don't
maybe
get
into
the
bait
of
what
precisely
we
would
put
in
there.
The
point
is,
we
can
have
a
v2
schema
that
we
come
up
with
where
we're
like.
We've
broadened
our
community.
We
have
thought
things
through
more,
and
so
we
have
a
new
version
of
our
schema,
that's
more
complex
and
nuanced,
but
because
we're
actually
versioning
our
schema.
D
Now
there
is
a
way
for
all
the
existing
consumers
of
this
data
to
convert
it
back
to
our
original
schema,
and
so
we
have
some
kind
of
mapping
from
like
app
name
or
whatever,
whatever
it
is,
that
would
make
front-end
people
happy
can
be
converted
into
something
that
the
current
consumers
of
service
name
would
be
like.
D
I
just
I
just
want
to
stress
that,
whatever
way
we
choose
forwards
at
this
point
for
that
stuff,
we
try
to
work
within
the
confines
of
whatever
our
our
schema.
Versioning
scheme
that
that
the
grid
has
come
up
with
can
can
handle
that.
That's
really
really
truly
my
only
requirement,
because
that
that
ensures
we're
not
throwing
a
big
monkey
wrench
at
all.
The
people
who
have
like
already
adopted
open,
telemetry.
D
Yeah
and
it's
not
just
for
front
end
stuff,
I'm
saying
we're
also
actually
looking
at
this
for
for,
like
other
domains
where
we
went
in
and
made
a
bunch
of
decisions
about
like
database,
here's
the
database
stuff
and
now
we're
looking
at
that.
We're
like
is
there
really
database
stuff
at
all,
even
like
are
all
the
databases
the
same
enough
that
we're
gonna
shoehorn
them
into
this?
This
schema
that
we
came
up
with.
So
it's
it's
not
just
here
that
we're
we're
hitting
that
problem.
Yeah.
F
I
think
it
also
is
really
important
that
we
bring
in
people
to
this
conversation
like
I
know
nothing
about
iot.
I
know
nothing
about
network
hardware.
I
know
nothing
about
kind
of
firmware,
monitoring
or
firmware
based
monitoring
whatsoever,
but
it
feels
like
if
we
really
want
to
be
open,
telemetry
and
you
know-
describe
the
world
of
of
computing
telemetry.
F
We
need
to
bring
in
those
people
who
know
about
firmware,
know
about
hardware
and
know
about
iot
and
know
about
these
other
spaces
and
understand
how
people
actually
talk
about
things
there
as
well
yeah.
I
don't
know
anything
about
that
whatsoever,
but
it
feels
like
we're,
probably
also
not
including
those
people
in
this
discussion,
and
it
would
be
very
helpful.
I
think
yeah.
G
I
think
one
advantage
of
the
approach
of
expecting
that
we're
going
to
have
multiple
schemas
to
define
these
different
domains
is
that
it
allows
us
to
defer
those
questions
to
some
extent,
because
if
we
don't
define
them,
but
we
have
a
way
to
define
them
later
on.
We
can
still
then
have
those
conversations
with
the
iot
folks
and
with
the
network
hardware
folks
and
define
a
schema
for
that
domain.
D
But
but
I
think
we
we
need
to
have
that.
I
would
like
to
see
us
just
have
a
single
schema
that
is
versioned
to
jmx
point.
I
don't.
I
don't
necessarily
want
to
see
like
a
different
schema
like
like
the
the
web,
app
schema
and
the
iot
schema,
if
that
makes
sense,
just
just
schema,
v1,
v2,
v3
and.
G
H
H
Database,
it's
very
powerful
because
you
can,
if
you're
sending
data
like
prometheus
or
like
some
open
source
backend
that
hasn't
gone,
it
enabled
the
semantics
for
every
single
potential
type
of
data
source.
It
still
shows
up
in
a
pretty
decent
way.
Yeah.
D
D
We
also
think
about
how
to
backport
it
to
whatever
prior
version
of
that
that
name
space
in
our
schema
we
we
came
up
with
like
I
think
we
just
we're
mature
enough,
even
though
we're
saying
some
of
these
things
are
experimental,
that
we
have
to
start
getting
into
that
that
practice
when
we
go
mucking
about
with
our
semantic
conventions,
but
we're
gonna
have
to
muck
about
with
the
semantic
conventions.
D
Like
there's
no
question
that
we're
gonna
have
to
improve
those.
We
just
need
to
start
thinking
about
when
we
do
that.
How
do
we,
our
one
limitation,
is?
We
need
to
ensure
we
we
back
port
it
since
people
who
are
relying
on
the
current
version
of
the
semantic
conventions,
don't
have
a
way
to
to
not
break
all
of
their
dashboards
and
like
everything
else,
that's
like
currently
consuming
data
and
they
can
progressively
migrate
out
new
schemas
and
things
like
that.
A
Excuse
me,
by
the
way,
for
the
sake
of
time,
I
recommend
we
keep
talking
either
offline
or
after
you
come
to
the
wrong
call
yeah.
I
think
it
will
be
good,
like
you're
rightly
trying
to
answer
your
your
question
here.
We
are
still
trying
to
time
boxed
the
last
20
minutes
of
the
call
to
talk
about
metrics.
A
So
sorry
for
that
guys,
there's
only
so
many
minutes
in
an
hour,
but
before
we
go
there,
my
call,
I
guess
tracy
monty
conventions
for
http
need
reviews
and
approvers.
Michael,
are
you
here.
K
Yes,
so
this
is
more
of
announcements,
so
there's
been
a
reviewers
and
approvers,
but
we
still
need
folks
from
the
tech
council
to
review
so
dennis
isn't
able
to
make
it,
but
I'm
here
just
to
represent.
So
I
know
that
like
yuri
has
commented-
and
I
think
josh
has
as
well-
and
I
understand
folks
on
tech
counselor
are,
you
know,
focused
on
rolling
out
metrics
and
all
that
stuff
makes
total
sense,
but
we
do
want
to
try
to
get
to
a
v1
stabilization
and
we
could
really
use.
K
You
know
a
couple
folks
from
the
tech
council
to
carve
out
some
time
just
to
review
and
then
that
way
dennis
and
the
rest
of
the
work
group
can
make
any
updates
as
necessary.
But
this
right
now
has
been
the
hindrance
from
us
from
progressing
to
trying
to
get
stabilization
with
respect
to
v1.
So
more
of
announcement.
A
B
So,
regarding
the
skin,
I
was
just
referring
to
the
schema
that
microsoft
has
been
using
for
decades,
the
only
common
fields
we
have
like
this.
We
don't
have
anything
specific
to
a
domain,
because
people
keep
fighting
forever
and
if
you
ask
them
to
have
a
unique
idea
across
different
domain,
the
device
people
would
complain
because
they
really
care
about
the
size,
maybe
just
providing
some
additional
context.
B
Okay,
so
my
first
question
for
matrix:
do
we
keep
the
thursday
metrics
sigma
or
not?
My
suggestion
is
no
because
I
I
think
we
don't
have
a
lot
of
topics
to
talk
there
and
if
there's
some
like
metrics
topic,
we
should
use
this
meeting
because
it's
starting
to
become
very
important
for
everyone
in
this
group
instead
of
a
small
group
of
people.
B
So
I
canceled
the
december
meetings
and
seems
it's
fine.
I'm
going
to
cancel
the
the
meeting
this
year
like
moving
forward.
Anyone
disagree
or
not.
B
Okay,
so
this
is
the
project
board
for
matrix,
stable
release.
The
the
only
thing
I
I
think
outstanding
is
the
decision
whether
example
should
be
enabled
by
default,
and
my
suggestion
is
that
we
postpone
this,
so
we
mark
example
as
it's
still
working
progressing,
not
as
stable
and
we
ship
the
initial
metrics
as
decades
back
as
stable
without
example,
and
literally
work
on
it.
Once
we
have
enough
confidence,
we
should
add
it
back
and
and
at
that
point
we
need
to
make
a
decision,
but
not
today.
B
Then
I
have
a
another
question,
so
at
least
to
me
this
seems
to
be
the
only
blocking
issue
for
the
initial
stable
release.
Well,
there
are
many
metrics
issue
here.
I
I
went
through
all
of
them
and
most
of
them
that
don't
seem
to
be
blocking
issue
for
the
ick.
For
example,
there's
some
ask
about:
can
you
clarify
the
api
spec?
Can
you
improve
the
data
model
both
are
stable
already
and
their
additional
ask
like?
Can
we
add
additional
interface
to
existing
spec?
B
So,
instead
of
having
to
spend
additional
time
and
block
the
stable
release,
I
think
it's
totally
fine
that
we
post
upon
all
of
them.
The
only
exception
I've
seen
here,
the
the
instrument
identity,
which
I'm
I'm
not
sure,
so
I
haven't
put
a
tag,
whether
it's
like
it's
for
future
or
not.
This
is
something
I
want
to
discuss.
B
So
the
api
is
already
stable
and
the
api
tells
people.
If
you
have
a
meter
under
that
meter,
you
don't
have
the
same
name
of
the
instrument
is
considered
as
conflict,
but
we
allow
you
to
have
the
same
name
of
instrument
under
different
meter
instances.
The
question
here
is
about.
If
I
got
the
same
instance,
and
also
the
meter
name
is
the
same
like
I
have
three
meters,
all
of
them
have
the
same
name
which
is
allowed
by
the
api
spec,
and
I
have
under
the
three
meters
individually.
I
have
an
instrument
named
the
relay.
B
I
have
three
rightly
and
there's
three
different
meter
with
the
same
name.
What
do
I
do
from
the
ick?
I
think
the
ict
has
the
wording
that
tells
people
what
view
would
do
and
if
there's
no
view
what
the
default
view
would
do.
But
I
agree
it's
not
very
clear,
so
I
I
I
think
we
we
can
make
more
clarification
in
the
sdk
spec,
which
could
help
the
javascript
folks
here.
C
B
So
imagine
if
you
have
two
individual
library
developers
and
they
invent
their
same
name
and
they
put
the
same
thing.
Everything
is
the
same,
but
he
got
two
instances
and
both
of
them
are
reporting
some
data
and
those
data
might
be
incompatible
or
they
might
have
conflict.
So
in
the
exporter.
What
do
you
do.
I
Harley,
can
I
ask
if
there's
a
difference
between
synchronous
instruments
and
asynchronous
instruments?
Here
I
mean,
I
think,
that
with
synchronous
instruments,
there
should
be
no
difference,
whether
you
record
the
observations
on
two
separate
instruments
and
then
merge
them
later
or
whether
you
record
them
on
the
same
instrument.
I
It
should
be
the
same,
but
when
it
comes
to
an
asynchronous
instrument,
you're
going
to
have
the
two
developers
with
the
same
library
register
two
callbacks,
and
I
think
it
would
be
acceptable,
perhaps
to
just
run
both
callbacks
and
take
two
observations
and
you
know
choose
one
of
them,
which
is
what
we
have
to
do
for
correctness
anyway.
That's
been
written
down,
but
I
I
don't
think
that
that's
helping
the
user
it's
going
to
be
very
confusing
when
you
do
have
duplicate
registration
of
those
callbacks.
So
I
think
that
we
we
ought
to
prevent.
I
You
know
multiple
asynchronous
instruments
from
being
registered
because
it
creates
the
appearance
of
multiple
callbacks,
which
just
sounds
like
the
user
doesn't
know
what
they're
doing,
even
if
we
can
define
it
correctly
yeah.
So,
in
the
isd.
B
Case
back,
we
we
already
mentioned
that
we'll
go
through
all
the
instrument
and
if
there's
no
view
we'll
apply
a
default
view
and
we'll
go
through
this
rule
like
it
is
an
imperative
set
of
steps
that
we
run
through
and
if
there's
a
name
duplicate,
we'll
just
drop
the
data.
So
I
I
think
if
we
improve
the
wording
here,
because
the
way
it
was
described
here
like
if
there's
no
view,
then
we'll
just
apply
the
default,
configuration
and
exit.
B
I
B
For
example,
you
can
use
the
type
or
other
any
like
indicator
if
you
have
the
first
one,
which
is
a
synchronous
one,
the
second
one
is
asynchronous.
You
can
do
some
selection.
As
long
as
you
meet
the
criteria
you
can
see.
I
have
asynchronous
counter
and
I
want
to
rename
like
if
that
name
is
the
same,
then
I
want
to
rename
that
to
something
else.
I
I'm
starting
to
understand
riley.
I
need
to
think
about
this
more.
A
B
So
my
argument
would
be:
we
have
the
same
thing
like
we
keep
improving
the
current
spec
after
they
become
stable.
There
they're
always
something
we
can
clarify,
and
maybe
we
can.
We
can
keep
doing
this,
but
to
some
point
I
won't
have
some
clarity
here,
because
you
can't
imagine
like
we.
We
might
use
this
to
hold
the
the
progress
forever
right.
There
are
always
cases,
people
come
and
say
it
will
be
great.
A
I
just
want
to
say
that
I
think
that
clarity
is
more
important
in
the
epa
side,
because
that
affects
users.
The
sdk
can
always
improve.
I
think
they,
just
that's
just
my
opinion
yeah,
but
I
agree
at
the
same
time
in
your
point
that
if
we
keep
on
cleaning
to
spec
forever,
we
will
never
release.
L
Riley,
I
have
a
clarifying
question
about
the
meteor
and
instrument
identity
issue.
So
the
java
implementation,
if
you
ask
for
the
a
meter
with
the
same
name,
you'll,
get
the
same
instance.
You
won't
get
separate
instances
and
that's
the
same.
Behavior
for
tracing
as
well
is
that
allowable
in
the
spec,
or
are
you
required
to
return
separate
instances?
L
E
Yeah,
that's
just
for
metrics
right
now
it
was
more
of
a.
It
was
more
for
convenience.
We
were
trying
to
finish
the
metrics
sdk
as
quickly
as
possible,
and
it
we
could
always
change
that,
but
just
in
the
in
the
interest
of
getting
it
done
quickly,
we,
it
was
easy
to
just
return
a
new
instance,
since
it
was
undefined.
E
M
B
M
M
I
I'm
not
getting
your
question
so
for
the
the,
if
is
what's
the
requirement
for
instrument
should
we
return
the
same
instrument
for
the
same
name
or
not,
if
they're
under
different
meter,
you
can
return
different
instances?
M
M
B
The
other
one
yeah.
So
what
because
these
two
libraries
could
be
developed
by
totally
different
group
of
people,
they
don't
know
each
other,
so
it's
very
likely.
We
introduced
some
problem
and
the
challenges.
If
we
allow
the
like,
if
we
force
the
meter
to
be
the
same,
then
they
will
run
into
conflict
for
sure
the
no
matter
what
you
do
in
the
isdk
you
won't
be
able
to
get
the
the
only
thing
you
can
do
is
to
ask
the
library
developer
to
fix
their
instrument
by
giving
a
different
name,
but
we.
E
B
The
meter
instance
to
be
different
in
this
case.
This
will
be
instance,
one.
This
will
be
instance
two
and
when
you
configure
the
sdk,
if
you
do
nothing
the
default
behavior
is
you
will
you
will
get
all
this
notifying
the
isdk
and
the
first
one
would
win
the
second
one
would
get
doubt,
but
because
there
are
different
instances
you
you
can
doing
some
like.
You
can't
do
some
configuration
by
specifying
the
view
and
take
this
instrument
to
rename
that
to
different
things.
You
don't
run
into
identity
problems,
but
the
default
behavior
is
not.
M
M
B
I
And
this
comes
in
because
of
the
way
views
are
specified,
which
is
what's
new
to
me
here
and
I
hadn't
thought
about
it
much
so
I
said
I
was
going
to
think
about
this
a
little
bit
more
like
until
you
have
views.
This
situation
looks
bad,
but
in
the
presence
of
this
view,
speculation
this
looks
ambiguous
and
what
you're
saying
is
ambiguous
is
fine
and
I
think
it
still
looks
a
little
bad.
M
Right
right,
wrong
place,
riley,
let's,
let's
not
get
with
the
idea
that
this
is
in
two
libraries.
Let's
assume
I
have
two
classes
in
the
same
library
and
intentionally.
I
need
in
two
classes
two
meters,
so
they
are
both
part
of
the
same
library,
not
not
not
different
libraries.
So
I'm
I'm
not
doing
a
mistake.
I
just
needed
two
two
different
meters
in
these
two
classes,
so
I
I
I'm
gonna
call
them
foo,
because
my
library
is
full
or
a
or
whatever
you
call
it
why?
Why
is
this
dropped?
M
I
think
this
should
not
be
dropped.
I
mean
I
know
what
I'm
doing.
I
have
a
counter
shared
between
two
classes.
Maybe
one
class
is
producing
and
one
class
is
consuming,
so
I
want
to
do
a
plus
one
and
a
minus
one
on
an
up
down
counter
to
count
how
many
items
I
have
in
the
queue
or
whatever
I
want
to
do
something
like
that.
M
So
so
you
asked
me
to
pass
the
instrument
instead
of
getting
the
instrument
from
the
library
yeah.
I
think
this
should
be
documented,
as
as
what
we
expect
users
to
do,
because
I
was
not
thinking
this
way.
L
And
furthermore,
the
the
this
relates
to
the
issue
that
I
opened
yesterday.
So
the
java
behavior
is
different
here.
So
if
you
obtain
the
same
instrument
with
the
same
description
and
the
same
unit
and
the
same
type
from
the
same
meter
and
you
you
can
do
that
multiple
times
and
you'll
get
the
same
instrument
back
and
you
can
report
like
values
against.
You
know
it's
the
same
instrument,
but
you
you've
obtained
it
multiple
times.
L
M
Yeah
here
we
are
talking
about
the
counter
like
doing
plus
one
minus
one
sure
we
can
discuss
for
asking,
but.
I
L
Don't
agree,
that's
an
error.
I
think
no.
M
I
Yes,
but
I'm
referring
to
the
conflict
case
that
riley's
text
on
the
screen
is:
we
have
two
classes
with
the
same
library
and
meter
name
and
they
both
created
the
same
counter
named
bar.
What
what's
wrong?
There's
nothing
wrong
at
this
point
you
can
count
and
aggregate
together.
If
you
return
the
same
instrument,
it's
going
to
be
great,
but
if
you
don't
return
the
same
instrument,
the
sdk
is
probably
required
to
do
the
aggregation
anyway,
to
avoid
breaking
the
single
biter
rule.
M
I
I
know
I
know
so:
that's
that's
what
I'm
referring
is
this
case
valid
or
not?
Again,
I'm
not
talking
about
the
conflict
here.
The
developer
intentionally
wanted
to
share
the
instrument,
but
he
was
lazy.
He
did
not
pass
the
instrument
around
as
constructor.
He
was
just
getting
the
new
new
instrument
from
the
library.
I
M
B
So
for
languages
who
decide
to
return
the
same
instance
of
meter,
if
the
name
is
the
same,
then
they
don't
have
the
problem,
because
you
always
get
the
same
thing,
then
you
can
use
in
multiple
classes
for
languages
which
decided
to
return
different
meter
instances
for
the
given
name.
Then
they
have
to
they
have
to
clarify.
What's
the
behavior
and
according
to
the
spec,
the
behavior
is
your
job.
If
you
hit
the
same
name
the
second
time,
but.
M
B
L
L
So
we
got
we
got
to
sort
that
out
and
it
seems
kind
of
strange
that
you
can
like
this
ability
to
either
get
you
know
the
instrument
multiple
times
or
not
is
based
on
the
implementation
detail
of
whether
the
same
literal
instance
is
returned
or
not
so
like,
isn't
that
an
implementation
detail,
whether
we
return
instance,
one
and
instance,
two
or
just
instance,
one
twice.
M
E
Yeah
should
we
actually
make
that
encouraged
behavior?
Actually
so
right
now,
it
seems
like
the
the
issue
is
that
it's
unspecified
whether
the
same
meter
is
returned.
I
don't.
I
wasn't
a
part
of
the
conversations
around
why
that
is
unspecified,
but
should
we
change
that
wording
to
say
if,
if
a
meter
with
the
same
name,
you
know
if
you
get
two
meters
with
the
same
name?
It
should
be
the
same
instance.
L
That
goes
back
to
the
fact
that
that
language
was
like
copied
from
tracing,
so
we
don't
want
to
diverge
there
right.
That's
that's
what
riley
brought
up
at
the
beginning.
E
F
E
L
B
L
So
that
would
require
changing
the
api
spec,
though,
because
that's
that's
spec
in
the
api.
That
meters
must
return
an
error
when
they're
registered
under
the
same
when
an
instrument
is
registered
under
the
same
meter
instance
with
the
same
name.
Is
the
api
stack
spec
stable?
Yes,.
M
But
it
doesn't
say
it's
an
error.
It
says
if,
if
the
type
is
different,
I'm
gonna
check
right
now,
pretty
sure
that
was
accepted
like
if
you
have
everything
the
same
again,
if
you
have
different
type
like
one
is
counter,
one
is
histogram,
I
it's
a
different
discussion.
L
I
M
I
I
see
jack,
it
seems
to
be
an
error
correct
based
on
the
current
description,
but
I
think
I
think,
relaxing
that
it's
backwards
compatible.
Okay,
because
from
an
error
you
get
to
a
non-error.
So
you
are
extending
the
pull.
I
may
be
wrong,
but
that's
how
I
see
the
the
the
phrasing
there
that
allowing
more
cases
it's
backwards,
compatible.
L
So
that
would
be
a
fine
explanation
for
me,
but
then
you
know
this
relates
to
the
issue
that
I
brought
up.
So
does
the
behavior
change
change
based
on
whether
it's
synchronous
or
asynchronous
instruments,
because
it's
less
obvious
what
to
do
in
the
async
case,
when
you
have
multiple
callbacks
registered.
I
Yeah
I
was
saying
calling
both
is
like
probably
can
be
made
correct.
Technically
I
just
we
just
merged
a
long
rant
about
how
to
merge
asynchronous
observations
in
a
view,
for
example,
but
I
don't
think
it's
helping
the
user.
I
think
it's
it's
like
working
around
a
mistake,
and
I
don't
know
that
we
should
do
that.
M
And
valid
use
case
by
the
way
josh
for
that
is,
I
saw
I
heard
people
complaining
that
they
want
to
have
some
dimension
set
reported
by
one
callback
and
another
dimension
said
reporting
by
other
callbacks.
M
I
Like
I,
I
also
am
prepared
to
accept
that
that
it's
fine
to
have
multiple
arguments
callbacks.
I
I
just
think
we
should
be
very
deliberate
about
this
yeah.
I
was
just
giving.
M
You
an
example
anyway,
I
think
we
should
continue
the
metrics
seek.
Then.
B
We
have
the
thursday
one
correct.
The
problem
is
what
what
a
small
group
of
people
aligned
might
turn
into
a
surprise
for
bigger
group
of
people
and
given
we
don't
have
many
issues
that
block
the
spike
release.
I
I
think,
having
like
eating
more
people's
time
here,
makes
more
sense
anyway,
we're
running
over.