►
From YouTube: 2021-04-02 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
One
of
the
challenges
I
have
is,
for
example,
if
you
have
a
if
you
have
two
observable
printers:
one
is
the
user
time.
Another
is
the
system
time,
but
the
only
thing
it's
called
that
you
can
both
I
was
trying
to
find
out
an
efficient
way
that
that
we
can
make
only
one
six
call
and
push
that
there
might
be
other
other
ways,
but
I
I
have
some
idea:
okay,.
B
B
B
A
So
there's
one
non-blocking
comment
in
the
previous
pr
that
I
merged.
I
think
it
was
brought
by
noah
and
the
question
is
in
the
in
the
instrument
creation,
the
like
the
the
current
approach
that
I
already
merged.
We
suggest
that
when
people
create
the
instrument,
they
can
optionally
provide
a
list
of
attribute
names
and
types,
but
we
didn't
see
anything
about
the
value
and
we
know
I
was
trying
to
compare
what
we
have
in
open
climate
versus
what
promises
client
has,
it
seems.
Permissive
client
has
has
multiple
ways
of
put
like
people
putting
static
labels.
A
They
can
put
that
on
a
higher
level
similar
like
the
meter
provider
level.
They
can
also
put
that
meter
level
and
also
instrumentation
level.
That
brings
the
question.
If
we
have
a
goal
to
be
able
to
cover
the
premises
scenario,
do
we
think
we
want
to
provide
the
same
static
attributes
capability,
and
then
that
brings
to
more
questions
here.
So
is
that
a
static
thing
that
that
will
act
as
a
constant?
We
never
change
or
it's
something
we
up
like.
A
We
just
give
a
default
value
and
people
can
still
like
override
that
that
thing,
so
I
want
to
bring
this
topic
here
and
see
number
one.
What
people
think
that's
a
blocking
issue
number
two.
What's
the
preference
here
so
instead
of
making
this
very
abstract
conversation
I'll
I'll,
try
to
show
what
we
need
here.
A
B
I
I
mean,
I
think
my
my
most
immediate
suggestion
was
that
the
spec
already
has
a
line
in
it.
That
says
that
that
there's
a
parameter
that
takes
a
list
of
names
and
types,
and
so
my
my
most
immediate
suggestion
is
until
we
have
defined
a
behavior
for
the
thing,
then
we
shouldn't
put
it
in
the
spec,
because
at
the.
C
B
A
Yeah,
it
makes
sense,
so
I
I
can't
explain
what
what
was
in
in
my
mind
when
I
pulled
this
up
and
then
we
can
talk
about
whether
people
think
that
makes
sense,
or
we
should
remove
that
or
we
want
to
remove
that
for
now
and
literally
add
it
back
or
we
want
to
clarify
the
semantic.
So
what
I
was
thinking
is
for
for
the
matrix
api
in
some
situation,
people
want
to
have
better
performance
in
this
way.
They
might
want
to
give
some
hint
while
they
create
this
instrument.
A
So
the
example
I
give
here
is
when
people
create
the
counter,
they
can
actually
say
hey.
I
want
this
counter
to
be
a
double
value
and
I
can
provide
some
information
here.
So
you
know
I'll
have
like.
I
must
have
one
dimension,
which
is
the
the
customer,
and
this
is
the
attribute,
so
the
name
is
customer
and
the
value
is
a
string,
and
I
also
can
put
some
additional
things
say
this
is
high
cardinality.
So
if
you
want
to
do
some
aggregation
index,
you
have
to
prepare
for
plenty
of
memory.
A
A
A
A
If
not
at
all,
then
everything
will
be
run
time
so
for
every
individual
counter
call.
When
you
try
to
call
the
contents,
you
add
something
you
provide
the
the
attributes
and
everything
is
dynamic.
There's
nothing
predefined
there.
But
if
you
have
this
optional
list,
you
can
see
hey.
I
want
to
create
this
counter
and
I
can
tell
the
counter
ahead
of
time.
A
I'll
have
three
dimensions,
although
that
doesn't
mean
you
cannot
provide
extra
dimension
later,
but
it
actually
gives
you
better
performance
and
also
you
can
put
some
enforcement
saying
hey
this
dimension
like
the
customer,
is
a
string.
So
if
someone
is
passing
a
known
string,
you
might
make
some
language
trick
to
prevent
them
from
doing
that.
Yeah.
D
So
when
I
first
saw
this,
I
was
imagining
in
my
mind
that
this
would
be
our
way
in
to
replace
the
bound
instruments
that
was
in
the
previous
spec,
where
in
the
bound
instrument
in
the
previous
spec,
you
actually
have
to.
You
know
make
another
call
to
do
the
binding.
Whereas
my
impression-
and
here
is
that
when
you
create
the
counter,
you
already
pre
provided
quote
a
set
of
bound
labels.
D
C
So
I
would
like
to
understand
a
bit
victor
to
your
point.
What
exactly
is
these
attributes
for
right
now.
C
D
You
know
similar
to
how
we're
doing
the
bound
instruments
today
or
in
the
previous
spec
or
whatever
spec
we
have,
and
here
is
that
when
you
create
your
counter,
I
already
have
some
set
of
known
key
value
pairs
that
I
want
to
always
include
so
that
when
I
do
that
when
I
create
the
instrument
then
later
on,
when
I
add
the
measurements,
I
don't
have
to
provide
that.
So
this
is
akin
to
what
noah's
thinking
about
the
static
you
know,
labels
yeah.
C
I
was,
I
was
under
the
impression,
the
same
more
of
like
this
is
a
list
of
constant
labels
that
apply
to
all
the
recordings,
but
not
limited
to
that.
So
there
are
other
attributes
or
labels
coming
while
you
are
doing
the
recordings.
This
is
just
on
top
of
the
that.
I
do
believe
that
we
better
remove
this
smaller
api
is
better,
I
would
say-
and
maybe
maybe
we
can
discuss,
adding
it
later.
My
two
cents
on
this.
A
So
so
my
worries,
we
add
that
later.
That
might
surprise
a
lot
of
implementations
like
when
people
make
nice
so
so
I
I
would.
Rather
we
have
a
clear
thinking
if
we
remove
that
we're
not
going
to
add
it
at
least
this
year
before
we
stabilize
the
matrix
api
or
we'll
remove
that
for
now
and
after
we
finish
the
sdk
like
the
spike,
we're
going
to
come
back
so
just
have
some
idea
about
that
would
help
so
right
now
what
I
would.
C
Do
right
now,
I
would
remove
it,
but
I
would
add
a
sentence
there
that
the
api
must
be
designed
in
a
way
that
allows
us
to
add
extra
options
optional
things
in
the
future,
so
that
that
makes
things
clear
for
for
the
way
how
you
design
the
api
in
different
languages
that
you
either
use
a
builder
or
you
use
a
var
args
things
in
golang
or
whatever
you
do.
But
the
way
how
it
is,
it
should
be
backwards,
compatible
the
capability
to
add
extra
arguments
to
that
constructed.
A
That
makes
sense,
then
the
next
level
question
is:
do
you
think
we
remove
that
we're
going
to
need
that
very
soon
I
mean.
C
Not
very
soon
not
very
soon,
I
don't
think
we
had
it
in
our
api
in
the
previous
api
definition
and
we
survived
pretty
well
a
bunch
of
times.
A
lot
of
these
things
were
added
as
as
resources
or
or
or
what
we
have
in
the
instrumentation
library,
name
and
stuff.
So
a
bunch
of
times
what
I'm
trying
to
say,
majority
of
the
use
cases
it
may
they
may
be
covered
by
the
current
resource
and
and
the
instrumentation
library
name.
A
B
Yeah
I
mean
I'm
I'm
fine
with
what
bogdan
just
proposed
there.
I
I
might
caveat,
I
mean
how
how
would
people
feel
if
we
added
a
sentence
that
said
language
implementers
are,
you
know
basically
allowed
to
create
performance
optimizations
if
it
doesn't
constrain
the
ability
to
specify
you
know
the
labels
dynamically
at
the
call
site?
I
don't
know
if
that's
too
vague
language
or
what
what
do.
C
E
B
B
This
was
more
me
trying
to
facilitate
what
I
think
riley
was
aiming
for,
and
I
and
I
think
what
riley
was
aiming
for,
was
if
the
api
gives
users
an
option
to
declare
in
advance
the
shape
of
their
dimensions
or
a
subset
of
their
dimensions,
and
the
users
opt
to
make
use
of
that
facility,
then
they
might
be
able
to
have
faster
performance
when
they
log
measurements.
I
see.
C
E
C
Add
only
the
the
values
when
you
record
and
and
have
a
index
matching
like
first
value,
belongs
to,
and
so
on
that
that
keys
is
what
I
meant.
Okay,
so
that
is
different
than
having
a
full
of
all
the
artwork
agree.
E
C
C
Yeah,
so
so
what
you
want
actually
here
is
not
attribute
names
and
types,
because,
as
I
read
it
initially,
I
read
it
as
being
attributes
fully
full
attributes,
like
maybe
maybe
my
mistake
on
how
I
read
it,
but
the
way
how
I
read
it
was
you
you
want
to
declare
the
full
attributes
like
foo
equals
bar
and
that
will
be
added
to
every
point
on
top
of
whatever
you
define
during
the
add
operation.
C
So,
for
example,
you
have
you
define
here
full
bar
and
during
add,
you
have
bar
equals
buzz,
so
you
end
up
with
two
dimensions
instead
of
yeah
this
okay.
So
if,
if
this
is
your
goal,
this
is
a
bit
different
than
what
I
believe.
B
A
A
So
they
can
only
specify
the
value
without
putting
the
name
over
and
over
again
and
that's
for
performance
reason.
Okay
and
victor's
goal
is
different
and
it's
not
in
the
spec
at
all.
It's
an
optional
list
of
attributes.
That
means
the
names
and
the
values.
So
it's
more
like
something
applied
to
all
the
subsequent
calls
which
is
not
here
and
I'm
willing
to
explore.
Both.
I
think
we
just
talked
about
we.
Don't
we
don't
need
either
of
them.
A
C
C
Just
we
got
a
lot
of
feedback
about
that
being
very
confusing
for
for
users,
so
that
this
optimization,
by
the
way
with
the
predefining,
the
keys,
predefining,
the
keys
and
in
order
to
allow
you
to
specify
only
the
values
and
avoid
constructing
complicated
objects
and
maybe
maybe
deal
with
with
a
bunch
of
things.
I
think
it
will
be
an
interesting
optimization
that
we
may
achieve
good
things.
C
A
So
one
example
I
put
here
you
can
see
like
imagine
a
strong
type
language.
I
can't
even
define
some
some
structure
here
and
just
use
that
when
I
create
the
contour
and
gives
you
the
semantic
like
the
type
which
one
is
required,
which
one
is
not
and
you
can
simply
like,
you-
can
simply
create
this
strong
type
and
pass
in
the
counter,
which
is
very
convenient.
Not
necessarily
disagree
with
me,
like
donald,
probably,
would
never
do
this,
but
but
certain
certain
situation,
people
might
find
it
helpful.
E
Can
I
have
a
question
around
this
so
instead
of
like
letting
the
users
to
basically
provide
any
any
type
for
the
attributes
of
the
counter,
for
example,
in
this
case,
the
power
consumption
object,
would
not
it
be
easier
to
just
define
the
the
attribute
object
and
also
let
the
the
instruments
or
the
meters
basically
receive
a.
E
I
don't
know,
attribute
provider
so
that
you
will
be
able
to
have
any
arbitrary
object
that,
basically
you
can
like
say
that
hey
I
have
this
object.
You
can
have
a
builder
for
that
and
so
on,
and
you
can.
You
can
convert
that
into
this
list
of
attributes,
because
you
need
to
implement
the
I
don't
know
attribute
provider,
interface
or
somewhat,
but
on
the
api
side
it
will
never
know
about
like
what
is
it
under
the
hood.
It
will
only
know
that
it
is
something
that
will
provide
me
attributes.
C
E
E
C
And
those
should
be
comparable,
sure
sure
sure,
okay,
so
you
you
kind
of
have
a.
E
That
which
basically
prevents
the
api
or
protects
the
api,
knowing
about
anything
else
than
just
hey,
I
need
a
set
of
attributes
and
it
doesn't
really
matter
how
the
user
will
provide
that
to
the
api.
The
api
will
never
know
anything
else.
Just
a
list
of
attributes
or
set
of
attributes
and
having
having
like
this
provider
interface
will
make
the
user
able
to
do
this,
that
they
have
a
a
type
object
or
a
like
a
type
class,
and
they
will
be
able
to
like
fill
it
out.
E
Do
some
validation
on
top
of
it
and
so
on
and
at
the
end,
then
they
will
pass
this
provider
to
the
to
the
api.
It
will
just
get
the
the
list
of
attributes
out
of
it
and
it
will.
It
will
work
with
that.
Afterwards,
oh
and.
D
A
Start
different
versions
performance.
My
starting
point
is
that
you,
if
you
know
some
dimensions
ahead
of
time,
you
specify
the
names,
then
the
the
actual
implementation
can
do
a
lot
of
optimization.
They
might
say.
Oh,
this
is
a
three-dimensional
thing,
I'll
just
pre-allocate
this
memory.
For
you.
If
I
see
anything
else,
I
can
do
the
run-time
dynamic
thing,
but
by
default
I'll
optimize
for
this
fixed
value.
C
Yeah,
so
you
can
do
a
lot
of
optimization,
but
I
don't
think
you
can
do
unless
we
require
that
if
you
define
three
dimension
names
types
or
whatever
you
define
there,
you
only
accept
fee.
So
I
think
I
think
I
think,
if
you
have,
if
you
allow
people
to
pass
you
more
than
just
the
three
that
you
you
you
get
into
the
constructor,
you
need
to
give
them
another
way
to
pass
these
extra
things.
And
then
you
lose
a
lot
of
the
performance
that
you
gain.
A
D
D
Is
whether
or
not
we
allow
people
to
provide
a
set
of
values
when
they
create
the
metrics,
and
if
we
don't
do
that,
then
it
actually
has
ramifications
in
how
people
instrument
their
code
and
to
noaa's
point
and
others
point
before-
is
that
if
you're
coming
from
prometheus,
the
code
pattern
that
you
put
in
has
always
been
based
on
the
availability
feature.
Is
that
some
portion
of
your
code-
you
know
some
context,
so
you
could
create
a
meter
based
on
that
context.
D
C
But
it's
not
created
with
the
content,
so
I
think
there
is
a
small
difference
between
our
instrument,
counter
versus
versus
prometheus,
so
prometheus
has
this
notion
of
counter-vec,
I
think
is
called
or
something
like
that
that
that
is
a
bit
different
than
the
con.
So
the
counter
is
just
the
the
definition
of
the
metric:
no
labels,
no,
no
nothing!
So
here
it
is
now
from
this
counter.
You
can
have
an
add
method
or
we
can
build
extra
things.
Let's
say
partial.
C
We
we
have
in
the
previous
definition
of
the
api
we
have
bind
which
is
fully
bind.
You
cannot
have
anything,
but
we
can
have
a
partial
bind,
for
example
that
resolves
your
your
stuff
correct,
but
you
still
need
victor
in
this
case.
This
is
something
that
I
I
don't
know
why
prometheus
does
this
way,
and
maybe
you
can
give
me
some
example.
C
Is
you
still
need
to
to
pass
that
partial
or
or
or
partial,
resolve,
meter
or
or
or
counter
vect
in
prometheus
between
the
moment
when
you
have
the
context
and
the
moment
when
you
do
the
measurement?
So
why
why
why
you
cannot
pass
the
context,
but
you
can
pass
that
the
other
object
it
feels
to
me
like.
C
A
Go
ahead
so
so
I
believe
what
you
described
is
exactly
what
josh
asked
and
he
asked
like
some
places
like
the
api
must
allow
the
callers
provide
flexible
attributes,
because
the
argument
here
is,
we
allow
contacts
and
baggage
and
other
stuff.
We
shouldn't
limit
the
functionality.
So
here
I'm
giving
example,
you
have
the
predefined
this
type
that
you
can
report
that
efficiently,
but
you
still
have
the
flexibility
here.
You
can
put
whatever
key
value
pair
and
this
is
what
what
he
tried
to
like
improve
based
on
premises,
api,
so.
C
So
so
that's
that's
cool,
but
I
think
what
we
can
do
and
how
I
would
think
about
this
api.
So
we
have
a
counter
and
now
on
the
counter
you
can
create
but
bindings
or
bounds
things
that
are
fully
fresh.
So
you
you
tell
me
all
the
label
key
label,
sorry
all
the
attribute
key
values
or
the
attributes,
and
you
can
just
do
add
and
decrement
in
case
of
the
other.
But
let's
say
we
just
do
add
for
the
moment.
A
Is
becoming
too
complex,
you
think
you
think
I
I
I
think
this
is
already
like
very
very
hard
to
understand
and
if
we
go
down
this
path,
this
will
be
like.
We
haven't
seen
that
in
the
other
very
successful
matrix
api.
So
that's
why
I'm
a
little
bit
scared,
so
so
how
about
this?
So
we
decided
like
the
performance
thing,
can
be
added
like
both
the
emulation
previously.
If
we
allow
this
optional
input,
we
can.
We
can
add
that
later
it's
additive
change
not
going
to
break
the
existing
apis.
A
C
A
C
C
C
We
and
we
can
do
the
same
trick
if
we
want
to
not
add
new
concepts
and
stuff,
but
that
object
now
whenever
you
call
add,
if
you
add
extra
labels,
because
it's
they
call
them
labels,
I
think
in
prometheus
yeah.
It
inherits
the
five
plus
the
extra
that
you
have
so
so
so
it
is.
It
is
a
common
pattern
in
prometheus
and
we
we
can
always
add
that.
C
But
let's
start
with
just
a
simple
ad,
even
not
bound
yet
because
as
we
as
we
proven,
we
can
add
them
later
and
we
can
have
a
debate
on
how
to
do
that
nicely
for
the
users
and-
and
I
would
like
to
see
very
good
performance
comparisons,
for
example,
for
for
the,
for
the
only
provide
me
keys
and
then
you
have,
let's
say
optimize
optimize
counter
or
whatever
you
call
it
that
you
get
from
a
counter
by
providing
just
the
keys
and
the
new
api
that
this
one
has
allows
you
to
provide.
Only
the
values.
C
So,
let's,
let's
stick
with
minimal
minimal,
is
always
better.
We
can
always,
but
please
make
sure
you
add
that
sentence
that
I
mentioned
to
you,
that
we
need
to
especially
the
creation
of
the
the
instruments
to
be
flexible,
that
in
the
future,
if
we
may
need
to
add
new
options,
the
apis
and
sdk
should
not
be
surprised
and
should
be
able
to
add
a
new
optional
parameter
to
that.
C
Yeah
but
just
make
sure
the
way
how
we
design
the
apis
and,
for
example,
as
I
said
in
java,
that
will
be
a
builder.
So
I
can
always
add
a
new
method,
a
new,
a
new
argument,
but
I
don't
know
what
others
will
do,
but
just
make
sure
we
can
add
optional
things
not
required
because
required
will
be
breaking
a.
A
B
C
A
C
Discussed,
I
don't
think
we
need
to
do
that
so
for
for
prometheus
style
thing,
we
can
easily
have
a
method
that
says
bound
some
attributes
and
return
the
same
object
and
we
just
implement
the
same
concept
that
is
in
prometheus
for
the
keys
stuff.
We
can
have
a
new
type
that
is
created
as
part
of
the
counter,
and
it's
simple,
so
I
don't
think.
A
Anything
is
wrong
cool.
I
I
think
we're
done
here
so
I'll,
follow
up
on
that
thanks,
alright,
and
any
other
thing
that
you
want
to
quickly
mention
before
we
move
on.
D
Yeah
so
quick,
quick
things
and
I'm
just
clarifying
so
the
statement
that
we're
saying
that
bogdan
is
saying,
am
I
right
to
just
say
that
the
spec
is
is
to
specify
the
the
minimum
required
for
a
stable
api,
but
depending
on
which
language
you
are,
you
may
be
able
to
add
additional
idiomatic,
no
okay,
so
you're
not
we're
not
saying
that.
Okay,
unless.
C
So
victor
our
goal
is
to
to
bring
the
entire
community
and
everyone
to
a
very
minimal
and
stable
level
that
we
can
collect
feedback,
and
then
we
let
creativity
comes
into
place
and
say:
okay,
we
discovered
that
our
users
have
these
problems
a
and
b
and
c.
Let's
be
creative
and
solve
these
problems
together
and
come
up
with
more
more
smarter
apis.
On
top
of
what
we
have
does
it
make
sense.
D
C
C
May
play,
but
not
by
adding
completely
new
concepts,
so
I
agree
and
functionalities.
So
so
that's
that's
the
whole
thing
like
when
it
comes
to
new
functionality.
I
don't
think
that's
where
we
say
language
has
the
freedom.
We
say
language
has
a
freedom
of
following
using
an
option
or
settings
pattern
for
creating
things
or
builders
or
or
returning
generic
versus
returning
names
with
with
the
type
because
java
is
stupid
and
cannot
have
primitives,
boxed
and
unboxed
things.
C
So
a
lot
of
these
things
are
are
language
specific,
but
not
when
it
comes
to
functionality.
We
want
that
party
to
be
defined
here,
and
so,
unless
you
add
new,
so
unless
you
don't
add
new
functionality,
then
you
can
be
creative,
but
when
it
comes
to
new
functionality,
we'd
like
to
have
everyone
on
the
same
level,
because
the
problem
that
we
are
trying
to
raise
here
is:
if,
if
we
allow
everyone
to
be
creative,
we
will
end
up
with
functionality.
C
A
Okay,
so
moving
on
so
the
next
one
is
the
async
contour
pr.
So
last
time
we
have
the
counter
synchronous
one
got
merged,
so
I'm
working
on
the
asynchronous
one.
Please
take
a
look
and
my
biggest
struggle
is
the
the
prior
art.
When
I
look
at
the
observer
from
this
old
type
and
the
the
current
like
the
api,
we
have
a
observer
function
in
the
callback
where
people
can
call
the
observer
and
keep
sending
this
thing.
A
What
I
I'm
taking
a
little
bit
different
approach
here
by
making
sure
the
function,
the
callback
function
is
returning
a
list
or
whatever
the
language
idiomatic
way
a
collection
of
the
value
and
the
attributes.
So
this
might
be
a
little
bit
different.
I
want
to
get
people's
idea
and
I
don't
have
a
strong
opinion
on
either
way.
So
if
you
see
a
strong
reason
why
you
prefer
this
way
versus
the
other
way,
please
comment
I
I'm
trying
to
like
like
break
through
the
conversation
history.
A
Yeah,
the
yeah-
this
is
very
different
and-
and
my
my
major
challenge
here
is:
if
someone
like
the
they
store
the
results
to
a
global
variable
and
they
call
that
outside
this
function.
What's
the
result,
I
find
it
very
hard
to
explain
the
side
effect
or,
if
we
we
can
just
ignore,
like
we
tell
people
if
you
just
store
this
value
somewhere
else,
and
you
call
that
outside
the
function
then
screw
up
his
whole
problem,
I'm
totally
fine
with
that
which,
which
value?
Sorry?
Can
you
repeat
this
result.observe.
A
A
Sure
it
may
happen
yeah,
so,
for
example,
if
that
function
finished,
but
the
user
is
having
some
asynchronous
call,
that
is
still
reporting
the
number.
What
do
we
do
here
and
we
expect
this
to
be,
for
example,
if
the
observer
function
is
going
to
call
some
asynchronous
like
they
call
some
sensor
like
temperature
sensor,
it's
going
to
take
time
and
they
have
a
callback.
What
do
we
do
so?
I
found
this
part
for
javascript,
it's
very
hard
to
explain:
okay,
okay,
let.
C
Me
give
you
background
why
we
choose
this
way
versus
returning
thing
and
then
we
can
discuss
if
one
is
better
or
the
other.
So
this
pattern
was
very
nice
for
us
because
we
actually
were
giving
you
a
a
fake
or
an
object
that
actually
was
embedding
directly
our
sdk
implementation
thing
and
then
and
then
every
time
when
you
call
us,
we
just
update
the
value
directly
into
our
maps
and-
and
we
do
a
lot
of
things
so
we
allow
we
avoid
it.
C
Essentially,
we
avoid
creating
lists
or
maps.
As
a
result,
we
just
directly
whenever
you
pass
us
the
result.
We
update
our
internal
map
that
we
have
to
produce
anyway,
so
you
don't
give
us
a
map
that
will
then
transform
in
our
internal
map
and
so
on
so
forth.
So
it
was
very
interesting
and
yeah.
It
makes
sense
for
for
this
reason
now
I
understand
your
problem
and
I
don't
know
what.
A
Is
better
I'm
just
and
yeah,
so
I
I
guess
it
might
not
be
a
problem,
because
I
I've
seen
this
pattern
somewhere
else
just
want
to
see
like
if
anyone's
seeing
problem
here,
because
it
seems
to
be
fine.
I've
seen
that
in
python
sitar
people
implement
this
pattern
with
no
problem,
so
privacy
is
just
my
like,
like
my
personal
belt
here,
yeah.
B
This
I
mean
this
would
only
apply
for
c
sharp.
It
wouldn't
necessarily
apply
elsewhere.
You
know
like
we
could
make
that
result
be
what's
called
a
refstruct,
which
are
things
that
are
only
you
can
only
have
them
on
the
stack
and
thus
it
would.
It
would
literally
be
impossible
for
them
to
assign
it
into
a
global
value.
The
language
wouldn't
let
them
do
it,
but
that's
specific
to
c
sharp.
I
don't
think
all
of
our
languages
have
those
sorts
of
tools
in
their
tool
bag,
but
but
to
be
honest,.
C
There
are
things
that
users
can
do
stupid
if
they
store
sure
references
to
things
that
they
shouldn't
store
reference
to
things
yeah.
So
that
being
said,
I
do
understand
the
the
reason,
for
example,
for
something
like
javascript,
where,
where
maybe,
is
better
to
to
return
something
than
than
than
updating.
But
I
I
also
don't
understand
why
it's
better
to
return
something
than
than.
A
A
Functions
are
like
asynchronous
by
nature
right.
You
can
hardly
make
a
blocking
api
call
in
this
way.
They
want
to
access
some
sensor
and
that's
a
callback
function.
They
might
want
to
change
the
entire
metric
callback
function
to
be
asynchronous
call,
and
what
does
that
mean?
So
it's
very
hard
for
me
to
think
about
that,
but,
but
even
even
the
one
that
you
propose,
which
returns.
C
A
C
A
C
A
C
C
Thing
I
would
just
clarify
if
that
should
be
a
list
or
a
map,
that's
the
only
interesting
part
and
if
that's
a
map
on
what
is
a
map.
So
so,
yes,
I
I'm
happy
to
give
this
flexibility
and
I
think
it's
right
to
do
it,
but
the
return
here
is
that
a
dictionary
or
a
list.
A
Yeah,
and-
and
I
want
to
understand
why-
why
do
you
see
mentioning
a
dictionary,
is
important,
I
mean
from
semantic.
It
doesn't
make
sense
for
people
to
report
the
same
the
same
attributes
but
different
value
like
if
they
do
that
it's
an
indication
of
a
bug,
but
with
the
observer
they
can
call
this.
They
can
call
the
observer
several
times
by
passing
the
same
value
again
again,
which
is
also
a
bug,
so
it
seems
there's
no
there's
no
real
way.
We
can
prevent
them
from
from
doing
that.
C
No,
so
the
one
thing
that
I
want
is
who
handles
the
error,
so
I
want
to
be
consistent,
somehow
of
who
handles
the
error
in
this
case.
So
in
case
of
a
result,
pattern
is
the
rsd
key
that
has
to
handle
the
error
correct
in
in
the
case
of
of
dictionary,
if
you
accept
dictionary,
is
the
user
who
has
to
handle
the
error.
C
A
I
I
don't
know
okay,
so
the
reason
I
put
a
list
here
is
because
I
I
want
that
to
be
the
same
as
the
observer
semantic.
The
isdk
should
be
responsible
and
the
idk
can
decide
either
duplicate
the
thing.
It's
the
error,
I'll
drop,
the
entire
data
or
the
ic
code
can
last
one
yeah,
the
last
one
wins
or
whatever
or.
C
We
can
do
some
some
some
if
this
is
a
sum
or
we
can
do
some
tricks
yeah
right,
I
think
I
think
I
like
the
fact
that
it's
at
least
because
it's
very
very
similar
with
the
results
like
we
don't
have
any
dictionary
pattern
involved.
That's
why
I
asked
this
question.
I
didn't
not
asked
to
to
change
it
to
a
dictionary.
A
B
Just
fyi
the
the
c-sharp
prototype
at
the
moment
it
kind
of
does
both
of
those
things
it
has.
I
mean
I
just
had
two
different
overloads
of
the
constructor
that
take
two
slightly
different
callbacks.
One
callback
has
that
result,
object
that
lets
you
specify
as
many
as
you
want
and
the
other
one
just
lets
you
return.
B
B
C
Yeah,
definitely,
I
think,
allowing
or
specializing
for
this
one
case
is
it's
okay
for
for
me,
I
I
don't
see
a
problem,
but
I
would
like
to
if
those
if
that
was
the
decision
I
would
like
to
to
maybe
have
a
number
of
calls
of
that
versus
the
other,
if
possible.
Just
for
for,
for
my
knowledge
and
for
my
like
to
learn
new
things.
C
B
B
A
Okay,
cool
so
moving
on
now
about
the
the
product
tracking
sorry,
I
have
too
many
types
so
so
for
the
api
just
want
to
make
sure
once
we
have
this
asynchronous
counter,
so
sorry
for
the
asynchronous
counter.
Another
thing
I
want
to
call
it
currently.
A
E
So
so
here
in
micrometer
there
is
a
functional
counter.
That's
the
asynchronous
counter!
That's
that
that
that's
not
the
gauge.
So
in
micrometer
the
counter
can
only
go
up
and
the
asynchronous
counter
is
called
functional,
counter
yeah
the.
A
A
C
Is
from
josh
no
gauge
in
prometheus
is
very
similar
with
gauging
micrometer,
if
I'm
not
mistaken,
both
both
of
them
have
an
operation
to
say,
plus
minus
and
the
set
operation
on
it.
I'm
pretty
confident
that
both
so
micrometers
gauge
and
prometheus
gauge
are
very
similar.
That's
why
we
don't
want
to
use
gate
in
our
api,
because
we
will
confuse
hell
out
of.
A
I'm
trying
to
call
this
observable
counter
just
try
to
make
sure
it's
an
asynchronous
counter.
We
call
this
some
observer,
some
observer
yeah,
I'm
trying
to
make
some
correlation
people
can
understand.
This
is
the
counter.
This
is
the
asynchronous.
Instead
of
this
is
the
contract
sum
is
over
and
they
don't
share
any
common
name.
So
this
is
this
is
the
trick
I'm
trying
to
do
once
I
get
back,
it's
very
subjective.
I
understand
I
do
understand
this.
The
the.
C
Reason
by
the
way,
telling
you
the
reason
why
we
choose
this
was
because
counter
is
the
instrument
of
counting
things,
but
you
are
here
not
observing
a
counter
doing
things.
You
are
actually
observing
the
result
of
a
counter
with
the
sound.
I
understand.
So
that's
that
was
the
the
reasoning
behind
us
calling
things
some
there.
It
was
more
grammar,
nutty
and.
A
So
so
that
part
is
very
subjective
and
I
want
want
to
find
a
way
how
people
can
give
feedback.
So
everyone,
please,
please,
comment
and
see
why
you
prefer
this
and
and
I'll
I'll
try
to
push
for
simplicity
so
for
people
who
don't
understand
the
metrics
they're,
not
expert,
they
come
here
once
they
understand
counter
they
have
idea.
I
have
something
that's
similar
to
counter,
but
it's
asynchronous.
What
should
I
do
immediately?
They
can
translate
that
to
observable
content
once
they
learn
that
people
have
other
stuff
there's
a
pattern
for
them.
A
D
The
user
not
for
us
so
question,
question
in
at
least
in
c
sharp
I
mean
we
keep
on
talking
about.
You
know
async
count
async,
whatever,
whatever,
why
not
literally
just
call
it
async.
I
I.
A
C
Not
necessarily
a
non-blocking
by
the
way,
it's
not
an
asynchronous
execution
of
things.
It's
just
like
the
counter
is
calculated
somewhere
else
and
you
are
literally
observing
it
whenever
you
want,
so
you
are
literally
going
and
get
a
snapshot
of
that
counter.
That
happens
and
is
calculated
somewhere
else,
and
you
are
going
to
observe
it.
C
The
ascii
part,
I
don't
think
we
are
executing
anything
as
seen
because
in
the
end
from
our
sdk
will
execute
that
synchronously,
yes
and
at
a
undefined
time
or
whatever,
whenever
we
want
or
something
like
that,
but
but
I
don't
think
it's
we
are
scheduling
any
asking
work,
maybe
maybe
maybe
I'm
wrong,
but.
E
E
A
C
A
There's
too
many
questions
about
that:
okay
cool,
so
so
we
can
move
on
so
so
project
tracking.
It
has
been
a
incomplete
list
of
all
the
metrics
and
sdk
spike
issues.
So
I'm
I'm
trying
to
make
sure
at
least
if
there's
api,
spec
blocking
issue
it
should
show
up
here,
and
if
it's
not
here,
then
that
means
it's
not
a
problem
we're
trying
to
solve
in
the
api
spec.
So
these
are
some
questions.
A
I
want
to
have
a
quick
like
like
answer
from
you
guys
so
after
this
is
like
the
observable
counter
pr,
I
believe
the
next
thing
is,
we
just
want
to
figure
out.
What's
the
rest
and
this
it
should
be
straightforward,
just
copy
the
existing
thing
and
we
change
the
name,
and
we
give
some
example.
Then
we're
done
right.
So
I
I
believe
if,
if
this
observable
counter
pr
is
merged,
then
the
next
meeting
we're
going
to
figure
out
what
about
the
rest?
And
it's
just
about
the
names.
A
That's
the
only
remaining
thing,
and
I
want
to
make
sure
the
other
items
are
not
part
of
the
api
spike
focus
so,
for
example,
this
this
one.
Currently
it
is
under
the
matrix
api
standardization
of
unit.
I
believe
we
already
clarified
that
the
api
and
isd
has
no
idea
about
the
unit.
It's
just
opaque
string,
so
this
shouldn't
be
a
blocking
issue.
So
what
I'm
going
to
do
is
I'll
remove
this
from
the
project
tracking
and
park
this
under
semantic
conventional
data
model.
I
need
to
work
with
josh
to
figure
out.
A
The
only
remaining
thing
for
the
api
is
we
sort
out
the
names
and
there's
one
known
issue
about
the
hint
like,
and
we
agreed
last
meeting
that
hint
is
not
something
we
want
to
work
on
right
now,
we're
going
to
proceed
to
the
isdk
spec
and
after
the
sdk
is
back
in
there.
We
already
know
if
people
want
to
provide
the
bucket
size
and
like
specify
which
dimension
they
want,
we
can
take
the
learning
and
come
back
to
the
hint
api.
C
And
I'm
still,
I'm
still
not
sure
if
the
hint
api
should
be
part
of
creation
or
can
be
separate
objects
associated
with
that
thing.
One
thing
that
we
did
in
open,
sensors
and
at
least
in
sensors
internally
in
google,
was
very
useful.
C
We
had
these
views
associated
with
every
instrument,
but
they
were
completely
different
objects
and
different
things,
and-
and
nobody
complained
about
that-
and
they
had
a
very
nice
yaml
serialization,
so
people
can
define
them
in
a
yaml
file
instead
of
defining
them
in
code
and
much
easier
to
change
and
propagate
and
so
on.
So
anyway,
we
can
discuss
later,
but
I
think
it's
it's
something
that
we
can
postpone.
E
A
quick
question
so
for
the
for
the
rest
of
the
instruments,
do
you
also
want
to
consider
having
a
time
obstruction
like
a
timer
or
something.
C
I
think
that's
probably
after
we
deal
with
up
down
things
and
then
after
we
deal
with
the
gauge
thing
but
yeah.
I
I
think
at
one
point
will
come
on
the
beast:
okay,
cool.
Is
it
required
before
one
zero
or
stability
of
the
api?
I
don't
think
so.
I
think
we
can
declare
stability
stability
in
a
word
that
we
know
for
sure
this
api
will
be
stable
before
before
having
that,
because
that's
an
addition,
if
I'm
not
missing
correct
like
I,
I
I'm
trying
to
split
things
into
what
is
required.
C
We
need
a
full
story
for
counter
and
maybe
for
for
up
down
counter
and
in
the
histogram
thing
that
we
had
before.
If
we
have
these
notions,
then
probably
we
are
done
with
with
90
percent
of
the
use
cases.
Then
we
have
timers.
We
people
were
asking
about
instruments
to
count
not
only
durations,
but
also
what
what
was
that
exceptions
think
they
want
to
have
something
like
language,
specific
stuff,
but
anyway
we
can
discuss.
A
Okay,
cool,
I
think
we're
on
time
just
one
quick
question.
So
so
is
there
any
recommendation
where
we
should
park
the
unit
thing?
Okay,
do
you
think
this
is
semantic
convention,
or
what
do
you
mean
like?
I?
I
don't
understand.
Why
do
we
want
to
solve
this
in
the
api?
I
thought
we
already
agreed
that
api
and
isdk
just
treat
unit
as
opaque
stream.
So
then,
I'm
trying
to
give
this
to
some
other
sig,
and
I
I
have
hard
time
finding
out
should
should
I
put
this
on
josh's
plate
or
someone
else.
C
I
think
I
think
we
we
will.
We
can
park
it
for
the
moment,
but
I
think
we
will
end
up
having
something
like
what
they
have
there:
a
list
of
constants
of
different
units
for
time
units.
For
for
for
a
bunch
of
other
things,
we
will
provide
a
list
of
constant
units,
a
string,
constant
strings,
essentially
that
people
can
use
easier
instead
of
typing
them
and
making
sure
they
don't
do
mistakes,
but
that's
about
it.
I
don't
think
we'll
do
more
than
that.
A
Okay,
so
now
I'll
put,
this
are
part
of
the
isdk.
This
is
a
semantic
convention.
It's
many
conventions.
Okay,
I
okay
cool
I'll
I'll.
Do
that?
Thank
you.
Thank
you.
Okay,
thanks
everyone
bye,
everybody.
Thank
you.