►
From YouTube: 2023-04-06 meeting
Description
Instrumentation: Messaging
B
A
You're
back
in
Austin
right
there
yeah.
B
Yeah
Robert
yesterday
the
high
was
about
27
here
and
today,
the
low
or
today
the
high
is
probably
around
nine,
eight
or
nine.
Let's
see
what's
50
degrees,
Fahrenheit
converts,
yeah.
C
A
B
A
A
Cool
it
looks
like
we're
three
minutes
in.
We
could
probably
get
started.
We
have
four
people
here,
although
I
think
it's
quoramish
not
really,
but
I.
Think
that's
just
gonna
be
what
it
is
today.
Let
me
start
sharing
my
screen.
Gotcha
cool.
Well
welcome.
Everyone
looks
like
everyone's
already
added
their
name
to
attendee's
list.
If
that's
something
you
want
to
talk
about,
please
add
them
to
the
agenda
and
notes.
A
I
only
have
one
thing
on
here,
although
it's
a
doozy,
so
you
know,
if
you
have
something
else
you
want
to
talk
about.
Please
add
it
here,
maybe
just
well,
no
I!
Guess
everyone,
maybe
just
for
posterior
on
the
call
like
the
embedded
package
was
added
last
week
as
well,
so
we
did
decide
on
a
way
to
handle
versioning.
So
we're
moving
forward
with
that.
Just
for
a
heads
up,
people
that
weren't
paying
attention
to
get
merged
this
week,
I
think
so
yep.
A
The
next
thing,
then,
for
the
metrics
API
is
the
measurement
method
itself.
So
this
is
the
ad
record
and
observe
methods.
There's
an
issue
opened
and
the
last
week
and
it
talks
about
ad
not
being
thread
safe,
and
so
one
of
the
things
that
comes
from
it
is
the
fact
that
I
don't
know
where
ad
is
anyways
ad
takes
a
variatic
argument
of
attribute
key
values,
and
because
of
that,
the
method
then
converts
it
to
a
set.
It's
the
new
set
method
itself
is
not
concurrent
safe.
A
It
never
was
specified
to
be
current
safe.
In
fact,
it's
specified
to
modify
the
input
attributes
argument.
So
if
you
provide
the
same
sliced,
multiple
invocations
of
AD,
the
concurrency
non-guarantee
of
new
set
conflicts
with
the
concurrency
guarantee
of
the
ad
method,
or
this
applies
to
record
and
all
the
other
methods
as
well.
A
But
underlying
there's
there's
an
issue
for
concurrency
safety
like
currently,
our
API
is
not
concurrent
safe,
I
think
is
pretty
safe
to
say,
and
on
top
of
that,
like
there's
a
it,
was
you
know,
kind
of
digging
into
this
like
a
reuse
issue
So
currently,
the
attributes
that
are
passed
are
always
turned
into
a
set,
and
then
that's
every
single
call
there's
allocation
concerns
for
new
set,
because
it
does
still
require
an
allocation
when
it
copies
it
into
some
sort
of
static
array
and
I
do
say,
array
not
a
slice
there,
because
it
copies
it
into
a
fixed
size
array,
and
so
that
itself
is,
you
know,
an
overhead
of
using
the
new
set,
and
it's
done
every
single
time.
A
An
ad
is
added.
The
thing
is,
though,
like
I
think
this
might
be
one
of
the
situations
yeah
like
there's
a
there's
like
really
common
situations
where
people
have
a
set
of
attributes
and
they
want
to
update
a
bunch
of
different
things
and
they're
all
the
same
attributes.
So
there's
really
no
reason
they
need
to
be
allocated
twice
if
you're
going
to
use
the
same
set
at
the
end
of
the
day
and
I
think
that's
kind
of
the
takeaway
is
like.
A
Currently
we
require
you
to
pass
the
attributes
and
then
we
create
the
set.
So
we
require
you
to.
You
know
essentially
allocate
something
each
time
and
don't
let
you
optimize
how
you
want
to
pass
that
and
I
think.
That's
like
a
fundamental
issue
here.
There's
questions
from
Josh
about
this,
though,
because
in
his
implementation
he's
done
a
lot
of
this
optimization
for
the
user.
A
I
think
it
was
recognized
that
this
new
set
after
you
know
every
single
time
that
you
pass
it
to
add,
is
going
to
incur
an
allocation
and
there's
memory
overhead
as
well.
So
he's
built
some
sort
of
hashing
scheme
on
top
of
that
and
only
creates
the
sets.
You
know,
essentially,
he
does
this.
He
realizes
that
you
know
the
user's
passing
the
same
attributes
and
then
he
creates
the
sets
afterwards.
A
Only
only
once
is
what
he
tries
to
do
during
the
the
processing
of
those
in
this
SDK
and
I.
Think
that's
a
great
optimization
but
I
think
that
there's
a
design
choice
that
we
can
make
here.
That
has
the.
C
One
thing
which,
like
concerned
me
in
the
SDK
like
blight
step,
was
as
far
as
I
understood,
there
was
some
like
option
like
ignore
collisions
or
something
like
that,
and
so
there
were
like
two
modes
and
if
the
by
I
do
not
remember,
which
was
by
default
but
I,
think
by
default,
I
think
it
was
like
false
and
then
I
think
there
was
a
lock
during
each
time.
Basically
I'm,
not
sure.
If
each
time
an
ad
was
added,
but
I
think
it
was
the
way
that
it
was
making
concurrence
safe.
A
C
A
I
want
to
point
out
is
that
there
was
an
optimization,
and
that
was
that
the
the
reason
that
you
know
Josh
was
saying
like.
Maybe
we
can
still
continue
to
pass
these,
but
the
point
is:
is
that
there's
an
optimization
that
optimization
can
be
handled
by
the
user
as
well
and
I?
Think
there's
more
optimizations?
The
user
can
also
handle
here.
So
really
the
takeaway
I.
Think
of
in
this
discussion
was
you
know
we
really.
A
We
want
to
try
to
provide
a
way
for
the
user
to
optimize
themselves
out
of
having
allocations
so
providing
some
sort
of
way
to
have
a
set.
I
think
was
approach
last
week,
Aaron
suggested
this
ads
and
then
add
with
attributes,
alternative
I
I
think
this
is.
This
is
cumbersome
and
I.
Think
Robert
was
also
kind
of
pointing
out
that
having
multiple
methods
here
can
be
a
little
bit
confusing
to
users.
A
It's
kind
of
a
moot
point
now,
because
I
think
we're
going
to
move
on
to
the
with
options
which
also
solves
this
problem
in
a
different
way,
but
just
kind
of
like
recognizing
that
it
did
exist.
There's
a
bunch
of
different
proposals
as
well.
You
know
this
there's
a
lot
of
evaluation
that
happened
in
this
issue,
as,
as
you
can
kind
of
see
it's
it's
pretty
extensive.
A
There's
this
idea
of
this.
Like
other
interface,
instead
of
a
set,
we
could
add
a
new
set
then
use
these
new
sec
to
be
a
lazy
set.
I
just
don't
think,
there's
a
real
value
in
it,
because
there's
still
allocations
that
would
have
to
happen.
Another
was
the
default
being
that
you
have
to
have.
A
A
So
there's
a
lot
of
different
things
that
were
explored
here,
but
at
the
end
of
the
day,
I
think
that
there
was
this
is
where
it
went
to
is
you
know,
ad
was
never
anticipated
to
have
another
option
added
to
it.
It
was
kind
of
thought
as
not
sealed
itself
but,
like
you
know,
there's
nothing
really
you're
gonna
add,
and
then
this
issue
came
I
I.
A
You
know
it's
like
it's
almost
a
blessing
in
disguise,
because
it
did
kind
of
point
out
that
there's
not
agreement
across
otel
that
we
won't
be
adding
methods
to
these
measurement
methods
or
adding
options
to
these
measurement
methods.
Things
like
count
in
the
situation
where
there's
a
histogram
and
you
want
to
record
you
know
five
I,
don't
know
a
thousand
times
or
something
like
that.
A
You
do
a
for
Loop,
but
there
may
be
optimizations
under
the
hood.
If
you
just
wanted
to
say
like
record
this,
a
thousand
times
or
I,
don't
know
and
number
of
times,
and
so
with
that
being
said,
I
think
that
this
proposes
an
interesting
solution
to
not
only
the
concurrency
safety
option
but
just
to
the
extensibility
of
these
methods
themselves,
and
in
that
it
would
be
something
where
we
would
want
to
extend
all
of
these
recording
methods
with
options
in
our
option
pattern
itself.
A
So
I
have
this
proposal
here,
but
I
just
want
to
pause,
because
I
did
jump
through
a
lot
of
sets.
If
there's
any
questions
around
the
set,
because
it's
kind
of
a
foundation-
and
maybe
we
want
to
talk
about
that-
there
is
a
lot
of
ideas
from
that
that
are
carried
forward
into
this
new
proposal.
So
I'll
just
pause
here
and
double
check
who
has
their
camera
on?
Okay,.
B
The
the
only
thing
that
I
think
is
not
incompatible,
but
we
probably
want
to
have
as
kind
of
a
goal
is:
how
does
the
user
easily
cache
their
sets,
because
if
we're
saying
that
the
way
to
get
performance
is
that
you
don't
want
to
allocate
sets
every
time?
B
Thinking
like
if
user
is
stored
in
the
set
or
is
is
part
of
the
attributes
that
won't
be
known
until
the
very
end
of
the
like,
basically
at
the
call
site,
so
you
can't
necessarily
pre-cache
that
set
I
think
that
it
is
possible
like
what
what
has
been
done
in
the
light
step
repository
underneath
the
hood
is
possible
to
do
out
in
the
open
and
let
the
user
like
take
on
that
responsibility
and
that
burden
so
I
don't
think
these
are
incompatible,
especially
with
just
as
passing
in
a
set.
A
Yeah
and
I
I
recognize
that
and
I
think
that's
kind
of
how
I
see
it
is
I.
Think
not
only
are
there
opportunities
to
do
some
unique
and
helpful
caching
methods
to
sets
and
and
like
constructions
of
sets
that
are
included
in
the
livestep
SDK,
but
also
I,
think
there's
other
I
think
there's
other
opportunities
there
and
so
I
just
want
to
say,
like
we
could
always
add
in
the
future.
A
If
we,
if
we
accept
the
right
value
here,
I
think
the
right
value
here
is
the
key
wording
right
because
yeah
like
what
you're
saying
is,
if,
if
you
have
like
say
like
like
this,
is
actually
an
interesting
problem
like
this
is
maybe
a
little
nerd
sniping
me,
but
a
little
bit
because,
like
originally,
there
was
a
thing
called
like
a
bound
instrument
and
that
bound
instrument
always
had
like
a
you
know,
a
set
of
attributes.
A
It
always
recorded
with
and
you're
kind
of
getting
that
for
free
here
right,
like
you're
you're,
saying
like
well,
the
bound
instrument
is
essentially
like
the
set
that
I
have
to
just
pass
around
so
I
kind
of
like
it
can
construct
it
all.
At
once,
but
the
bad
instrument
was
great
because
you
get
ad
sets
or
add
attributes
to
it
after
the
fact,
and
it
would
annotate
like
the
base
set,
and
so
if
there
was
a
way
for
like
a
set
construction
to
do
similarly,
I
think
that
could
be
really
useful.
A
The
I
have
looked
into
this
a
little
bit
and
I
think
it's
possible
to
extend
the
existing
set
with
a
new
method,
something
like
with
attributes,
and
you
know
that
would
essentially
just
extend
the
set
and
return
a
copy
of
it
right.
But
the
problem
is
like,
if
you're
already
doing
a
copy
of
the
the
set
like.
Are
you
really
optimizing,
because
you're
going
to
have
to
do
another
allocation
in
that
process
so
like
if
the
cost
of
a
new
set
is
one
allocation?
A
A
So
I
don't
know
if
we
want
to
include
it
right
at
this
point,
but
yeah
I
think
it's
it's
like
something
we
can
discuss
as
long
as
we
accept
the
right
value
type
is,
is
kind
of
the
key
and
I
think
that's
where
this
options
pattern
is
is
going
to
go.
Is
there's
a
open
question
here
as
well,
so
I'll
I'll
jump
into
but
yeah
thanks
Aaron
for
pointing
that
out.
D
Yes,
what
I'm
thinking
is
is:
if
we
accept
options,
we
could
accept
the
with
attributes
or
with
set
multiple
times
right
or
some
combination
thereof,
which
would
allow
a
user
to
to
create
a
set.
That
represents
what
would
be
a
netbound
instrument,
provide
that
every
time
and
also
provide
an
additional
option
with
here's.
The
argument
or
the
the
attributes
that
are
for
the
specific
invocation.
D
B
The
goal
like
the
way,
the
light
step,
one
the
light
step
implementation
does
it
is,
it
doesn't
have
it
has
just
the
one
array
that's
passed
or
the
one
slice
that's
passed
and
it
does
a
fingerprint
look
up
and
then
caches
that
array.
So
if
you
pass
the
same
bag
of
attributes,
potentially
in
the
same
order,
then
you
end
up
with
the
same
the
same
set
essentially.
A
Yeah
I
mean,
but
then
there's
also
this
issue
of
duplication
right
and
so
like
duplicate
values
and
attributes
that
you're
actually
passing
and
there's
a
deduplicate
side
there,
and
it
also
then
requires
that
that
slice
is
copied
in
the
process
as
well,
which
again
is
another
allocation,
underneath
the
hood
and
and
I
think
it
there's
like.
B
A
Here's
the
thing,
though,
is
that
if
we
have
a
set
extended,
so
it
itself
has
a
fingerprint,
then
you're
already
doing
the
same
thing
right,
and
this
is
something
I
can't
find
the
local
branch
I
think
I
might
have
even
deleted
it.
But
I
have
done
this,
so
you
take
the
Set.
This
is
back
when
we
thought
that
there
was
a
bug
in
the
Set.
That's
right,
where
this
set
wasn't
actually
comparable.
A
So,
like
yeah,
there's,
there's
the
option
to
have
that
distinct
value
that
is
underlying
the
Set
itself,
have
a
hash,
and
so,
if
you
have
the
set
itself
present
itself
with
a
hash
like
passing
the
same
set
multiple
times
is
not
really
going
to
be
too
much
of
a
burden
there
and
I.
Think
you
could
you
could
then
similar
to
the
with
attributes
compute
this
compute
the
hash
the
same
way,
and
so
you
could
do
you
know
this
optimization
could
be.
A
You
know,
included
based
on
this
API,
where
you
accept
a
set
where
you
accept
these
attributes.
I,
guess
is
another
way
to
say
it,
but
it
also
means
that
like
Upstream,
because,
like
the
problem
with
this
hashing
scheme
is
great,
but
then
in
a
collection
cycle,
it's
cleared
out.
So
what
happens?
The
next
collection
cycle
you
allocate
another
set
on
that
on
that
new
hash
right.
C
A
So,
unless
I'm
saying
like
there's
more
optimizations
outside
of
just
like
reusing
during
your
collection
cycle,
that
a
user
is
presented
with
and
I
think
that's
like
really
valuable
to
highly
optimized
systems
and
I
think
that
if
the
API
allows
it
for
systems
that
don't
care
about
optimization
nearly
as
much
to
be
useful,
then
it's
like
well
whatever
right,
like
that's,
that's
fine.
It's
kind
of
a
point
there
and
I.
A
Think
that,
like
that's,
that's
kind
of
the
key
is
like
it's
just
all
about
what
are
the
things
that
you're
actually
accepting
is
is
going
to
be
the
the
right
question
here,
and
so
with
that
with
that
kind
of
in
mind,
it's
Anthony's
point
earlier
is
like
currently
this
proposal
has
this
function.
I'm.
Sorry,
this
option
function
here
which
just
accepts
a
set
right,
but
there's
nothing
saying
that,
like
you
couldn't
just
accept,
you
know,
variatic
attribute
type,
attribute
key
values
here
and
construct
the
set
for
the
user.
A
Underneath
the
hood
similar
to
what
Aaron's
talking
about,
we
could
even
Implement
some
sort
of
well.
You
could
Implement
some
sort
of
hashing
scheme,
but
then
the
problem
then
becomes
like
again
that
comes
back
to
the
unbounded
nature
right,
like
there's
I,
don't
know,
I
think
that
I
think
the
answer
here
is
like
you
have
something
that
accepts
a
set.
You
have
something
that
accepts
a
very
attic.
A
You
know
slice
of
attribute
key
values,
and
it's
unoptimized
like
that
is
just
gonna
straight
up,
create
a
new
set
right
off
the
bat
like
you're
just
going
to
get
a
new
set
immediately
after
it
copies
the
attributes
as
well,
so
there's
no
race
condition
in
there,
and
so
it's
like
it's
gonna,
be
a
very
unoptimized
method.
A
But
there
was
also
this
third
option
here
right
and
that's
kind
of
like
comes
back
to
this
other
question
of
like
what's
the
right
value
to
accept
and
like
there's,
this
thing,
I
was
playing
right
around
with
during
this
process
and
there's
like
there's
something
I
was
thinking
about
was
like
having
a
new
interface
type
called
the
distinct
sitter
here
and
like
naming,
is
not
settled
by
any
means,
but
the
the
idea
is
that,
like
this
is
this
is
your
hash
right.
A
This
is
something
that
you
would
do
the
hashing
that
we've
talked
about,
and
then
this
is
like
just
an
iterator
because
it
comes
from
the
attributes
package
right
and
what
this
would
do
is
allow
you
to
redefine
whatever
you
want
so
like,
if
you
can,
if
you
can
construct
something
outside
of
what
a
set
currently
is,
which
I
thought
a
set
and
implemented
this
interface.
But
technically
this
needs
to
be
called
equivalent,
but
just
kind
of
a
minor
detail.
A
It's
intended
that
this
interface
is
implemented
by
the
current
Set
pointer
set,
which
is
another
Point,
but
anyways.
So
so
say
you
want
to
do
something
like
this,
where
you
created
some
sort
of
like
lazy,
set.
I,
think
that
you
should
be
able
to.
You
know,
pass
that
and
if
we
accept
an
argument
here,
that
was
just
a
distinct
enter
and
that's
going
to
be
kind
of
the
key,
because
whatever
accepts
or
whatever
our
final
data
model
representation
of
these
attributes
are
it's
going
to
be
in
in
the
config
and
I.
A
Think,
that's
kind
of
the
key
thing
is
like
how
this
data
model
is
stored,
is
is
I,
think
something
we
need
to
talk
about
and
have
some
sort
of
like
understanding
on
at
this
point,
because
you
know
right
now
in
this
PR,
like
they're
stored
as
an
attribute
set.
But
if
you
know
we
wanted
to
go
this
route
and
have
some
sort
of
like
other
interface
type,
that
was
like
a
superset
or
something
that
wrapped
the
attributes
I
think
if
there's
it's
worth
exploring
it.
A
You
know
one
of
the
first
things
that
came
to
mind
is
like,
since
this
is
an
interface
type,
let's
just
add
another
allocation
and
through
you
know
just
some
testing,
it
doesn't
look
like
it
will,
given
it's
wrapped
in
a
definite
type
structure.
So
you
know
these
kinds
of
questions.
I
think
are
still
need
to
be
answered
at
this
point.
A
A
Exactly
yeah
I
think
exactly
that
I
just
want
to
like
Let
It
soak
for
a
second
but
yeah
I.
Think
it's
worth
I'd
love
to
get
feedback
on
this,
and
also
like
design
feedback
on
just
the
attribute
structure
like
I.
Didn't
I
copied
this
really
quickly,
but
I
didn't
put
an
example
of
like
the
width
attributes
with
you
know
a
very
attic
argument,
but
I
think
we
could
do
something
that
there
as
well.
So
any
sort
of
feedback
could
be
great.
A
C
Maybe
have
you
checked
photos
of
how
Java
implements
this
interface?
They
have
multiple
implementations
for
this
interface.
They.
A
Have
I
think
three
three
or
four
yeah
and
it's
and
it's
just
method
overloads,
so
you
know
they
have
one
that
has
nothing
and
then
they
have
I.
Don't
remember,
there's
yeah
I
mean
there's.
There's
a
few
in
there
I
think
there's
an
actual
Builder
one
I
think
there's
a
distinct
list.
One
I
think
there's
yeah
yeah
I
have
to
go
look
again.
The.
C
A
I
wonder
the
value
on
that
one
though,
because
of
the
intricacies
in
the
like
the
the
peccadillos
of
go
I,
don't
there's
another
word
for
pecadillos
there,
but
the
the
I
don't
know
the
uniquest
go
right
like
like
there's
I,
think
there's
a
lot
of
issues
because,
like
they,
they
obviously
have
difference
like
in
Persistence
of
the
memory
of
their
data
types.
A
The
difference
in
the
ability
to
you
know
the
syntax
of
the
language,
how
they
can
do
method,
overloads
and
and
all
of
these
sort
of
things,
and
so
like
yeah
I
mean
I
agree
like.
Maybe
we
could
look
into
something
like
that,
but
it
also
is
I.
Think
limited,
like
you
were
showing
me
earlier,
like
dot
net
has
like
four
or
five
or
something
like
that.
Like.
C
A
Agree
but
then
there's
also
the
overhead
of
having
to
reference
dereference
the
interface
there's.
Also
the
overhead
of
the
fact
that,
like
you
can't
like
you
can
extend
it
through
our
approach.
But,
like
you
know
technically
this,
you
know
if
we
wanted
to
extend
this
interface
like
we'd,
have
to
be
very
careful
how
we
do
it,
maybe
it
might
even
include
adding
a
new
interface.
This
probably
would
include
adding
a
new
interface
instead
of
extending
this
one
versus.
D
Like
this,
we
would
have
to
because
that's
something
that
could
be
implemented
by
the
user
right.
That
would
be.
You
know
what
is
what
we
call
a
plug-in
interface
or
extension
interfaces.
It's
not
an
SDK
implemented
interface,
so
we
can't
extend
it.
A
So
adding
a
new
method
is
backwards,
compatible
right,
so
like
yeah
I
mean
I,
yeah
I
think
there's
there's
value
in
having
something
like
this
because,
like
exactly
like,
you
said
Robert
like
the
ability,
for
you
know
somebody
who
comes
along
and
says
like
what
you
are
offering
me
is
not
what
I
want
I'm
going
to
give
you
something
that
I
want
is
great,
but
it
also
has
like
some
pretty
big
downsides
as
well.
I
think.
A
Yeah
I
mean
we
do
I
I
would
I
would
see
like
if
we
accepted
something
like
this.
We'd
have
to
do
a
refactor
where
we
use
distinct,
which
was
the
original
intention
to
use
that
as
the
key
and
then
yeah
make
sure
that
that's
you
know
appropriately
refactor.
C
Like
also
like
me
for
me,
if
you
have
a
concrete
type,
it's
it's
not
giving
another
like
abstraction
layer
for
the
consumer.
He
do
not
need
to.
You
know,
think
which
interface
you
need
to
use.
It's
just
clear
that
you
know
sometimes
simpler
is
better
if.
C
B
A
Agree,
but
at
the
same
time,
like
I
was
also
thinking
like.
If
we
have
this
options
pattern,
there's
nothing
to
say
that
we
couldn't
still
offer
you
know
this
option
and
and
other.
B
A
C
C
I'm
not
sure
if
I
understood,
Anthony's,
question
I
think
maybe
not
if
not,
then
maybe
I
have
a
question.
What
how
we
would
like
to
like
react
if
the
if
the,
if,
if
with
attributes,
will
be
called
twice
in
an
ad,
we
would
like
to
join
those
two
attributes.
That's.
A
That's
a
good
question:
I
think
I
think
you
got
to
do.
The
slow
thing
right,
like
you'd,
have
to
use
a
merge,
iterator
and
merge.
The
two
sets.
C
A
A
Yeah
so
I
mean
like
it's:
it's
yeah.
A
Right,
like
keep
that
in
mind
yeah.
This
is
something
that
would
be
satisfied
by
the
the
new
config
methods.
Yeah
herb
functions,
but
yeah,
okay,
I'm
gonna
pause
here,
because
I
wanted
to
make
sure
we
touched
on
something
else
with
this
PR,
because
one
of
the
other
things
that
like,
if
you,
if
you
go,
take
a
look
at
this
like
there
is
there's
a
lot
of
new
configuration
and
option
that
is
added
here
and
there's.
A
There's
two
issues:
I
can
see
like
how
this
was
added
to
the
actual
instruments
is
each
method,
so
each
method
in
the
number
type
is
the
thing
that
the
options
are
built
off
of
there's
an
open
question
like
should.
This
also
include
the
instrument
type
in
this
so
similar
to
back
before
we
looked
at
options
and
we
split
all
of
our
instrument
options
off
of
the
instruments
themselves
like
we
used
to
have
like
synchronous
options,
and
then
we
split
them
all
that
onto
the
this.
A
Just
so
we
have
the
most
fine-grained
configuration
going
forward
right,
I.
Think
there's
there's
an
interesting
problem:
that's
going
to
arise
if
you
don't
so
like,
if
you,
if
you
split
off
of
all
of
these
so
like
instead
of
a
float,
64
ad
option,
we
do
a
float64
counter.
Add
option
here.
A
I
think
that's
that's
great,
because
it
provides
a
lot
of
fine-grained
tuning.
But
then
you
come
into
this
problem
where
an
observer
is
the
the
thing
that
the
actual
observed
method
is
defined
on
not
the
instrument.
A
So
yeah,
let
me
see
if
I
can
explain
that
a
little
better
so
like
here
instead
of
having
a
float64
ad
option,
it'd
be
a
float64
counter
ad
option
instead
of
here
having
a
flip
64
ad
option
would
be
a
float
64
up
down
counter
option
instead
of
having
a
float,
64
record
option
would
be
a
float64
histogram
record
option
here,
and
that
means
that,
like,
if
there's
ever
some
sort
of
method
option
that
is
going
to
be
specific
only
to
a
float64
histogram,
we
have
the
Ford
ability
to
actually
provide
only
that
option
to
that
particular
method.
A
You
know
like
if
I
mean
I,
don't
ever
see,
we
want
to
give
different
options
for
float64
versus
an
N64,
but
currently
this
option
structure
would
allow
it
right,
like
you,
could
provide
a
different
option
for
the
N64
versus
the
flow
64.,
but.
A
Where,
like
in
here,
this
is
the
one
that
kind
of
sticks
out
to
me
where
you
want
to
provide
a
different,
you
know
ad
option
for
a
counter
than
maybe
for
an
up-down
counter
like
we
couldn't
provide
those
different
options
at
this.
This
current
design
right
here,
I,
don't
know
if
that's
ever
going
to
be.
The
case
is
the
problem.
Yeah.
A
Got
you
so
the
thing
is
with
observable:
is
that
it's
it's
like
all
of
the
observable
types
themselves
are
not
defined
with
the
method
that
they
actually
Implement
right.
So
sorry,
so
like
so
see
that
here,
the
counter
itself
is
just
like
it's
an
instrument
type
but
there's
no
actual
methods
on
it.
We
took
this
away
because
there's
never
a
reason
that
the
user
needs
to
be
calling
some
sort
of
recording
method
on
the
Observer
I'm.
Sorry
on
the
instrument,
the
observable
instrument
itself
right.
A
The
way
that
you
make
a
measurement
for
an
observable
is
it's
through
a
callback
and
that
callback
it
gets
an
observer
right
and
that
Observer
is
something
that
it
can
actually
do.
The
observation
for
the
problem
is
is
like
you
can't
then
split
this
right,
so
this
is
there's.
Only
one
option
for
an
observer
here
is
is
like
so
there'd
be
right:
yeah,
okay,.
D
A
Yeah
yeah,
okay,
yeah,
that's
exactly
it
yeah,
and
so
you
know
with
that
in
mind,
I
was,
like
you
know,
I
don't
ever
know
like
the
only
one
that
really
stuck
out
was
this.
This
counter
up
down
counter
difference
like
I
would
never
expect
effects
there
to
be
a
situation
where
like
well
there's
only
there's
only
like
one
record
method
for
histograms.
A
You
know
you
split
across
numbers,
but
that's
a
whole
other
question,
but
like
the
only
thing
I
could
think
of
is
like
for
the
up
down
counter
is
like
maybe
there's
a
future
option.
They
want
to
provide.
That
also
says
like
hey
by
the
way.
I
know
this
is
an
uptown
counter,
but
just
can
treat
it
monotonic.
You
know
it'll
just
be
a
negative
monotonic
count
or
something
like
that.
Like
that's,
the
only
thing
I
could
think
about,
but
I
also
was
like
well.
If
that's
the
case
like,
why?
B
A
D
Should
be
the
same
instrument
right?
Okay,
my
attention
all
along
is
but
there's
one
instrument,
it's
a
value
recorder,
you
record
values,
and
then
you
figure
out
how
to
aggregate
it.
Yeah
yeah
the
exponential
histogram
shouldn't,
be
a
new
instrument.
A
I
know
that's.
The
thing
is
it's
like
this
issue
that
is
raised
is
like
kind
of
blind
side
of
me,
because
I
never
even
consider
something
like
this
and
so
I'm
on
Shaky
Ground.
As
to
what
my
my
ability
to
predict,
what
the
hotel
Community,
where
it's
going
to
actually
want
here,.
D
I
think
in
that
regard,
adding
options
is
the
appropriate
response
right.
It's
the
pattern.
We've
used
to
give
us
method,
level,
extensibility
and
flexibility.
D
A
Yeah
I
mean
we
were
already
pretty
borderline
of
adding
the
embedded
package
on
yeah
I.
Think
that's
a
I
think
that's
a
fair
question.
A
A
Yeah
exactly
yes,
if
you're,
let's,
let's
jump
into
it,
then
so
the
the
other
thing
is
like
you
know,
if
you
can
kind
of
see
already
here
like
we
were
talking
about
like
you,
have
these
options,
they're
all
split
on
number
and
I
kind
of
just
hinted
at
it,
but
like
I,
never
see
a
situation
where
we're
actually
going
to
provide
a
different
option
for
a
float,
64
observe
versus
an
N64
like
that.
I
like
that.
A
Just
does
not
make
sense
to
me
as
to
why
that
would
happen,
and
if
it
does
I
don't
see
how
we
couldn't
address
that
via
generics
and
I
wanted
to
just
I
wanted
to
bring
the
question
up
again
and
I'll
just
run
through
some
of
the
ideas
I've
had.
The
first
idea
is
like
God,
we're
really
far
along
for
redesigning
with
generics.
A
At
this
point,
that
was
something
that
I
just
want
to
make
sure
it's
understood
like
I
I,
understand
that
like
that
is
something
that
I'm
like
well
we're
well
aware
of,
but
I
was
also
looking
the
project
currently
like
the
hotel
itself,
like
you
can't
build
it
with
anything
less
than
go.
117,
currently,
the
logar
dependency
requires
go,
116,
I
think
as
a
minimum,
and
that's
because
it
relies
on
API
that
was
added
in
117.,
so
I
think
that
we're
I
mean
and
that's
that's
building.
That's
literally
just
using
the
build
like
the
go.
A
Mod
tool
won't
work
for
any
any
sort
of
dependency.
That's
like
trying
to
build
off
of
like
so.
If
you
wanted
to
build
an
SDK
for
this
API
in
like
117
or
116,
you
have
to
use
it
like.
You
have
to
manually
construct
your
go
mods
because
it's
already
going
to
yell
at
you
that,
like
hey,
go,
my
tooling
tells
you
like
you've
got
to
be
using
a
newer
version
of
go,
go
118
or
above
to.
Actually,
you
know,
use
the
go
mod,
tooling.
A
You
know
this
API
with
less
than
118
in
the
future.
So
I
just
wanted
to
point
that
out
the
Upstream
go
I
remember.
This
was
also
a
big
concern
of
us
when
we
were
looking
at
generics
in
the
API.
Was
that
like
Upstream
go
in
118
said
like
hey,
like
don't
use
this
in
production,
yet
try
not
to
export
these
types
like
we're
still
working
out
the
details,
I
feel
like
that
might
have
passed.
You
know
they're
already
exporting.
A
A
It
simplifies
things,
there's
a
lot
of
functionality
that
it
provides,
and
so
like
I
like
I,
think
it
like
the
the
seal
is
kind
of
broken
in
like
the
idea
to
export
Upstream.
We
do
understand.
There
are
performance,
implementation
or
considerations
for
using
generics,
especially
around
generics
around
user-defined
types,
the
the
built-in
types,
it's
a
way
better
situation
for
performance.
In
fact,
it's
an
order
of
magnitude's,
better
situation.
A
So
if
we
did
generics
on
N64
and
flow
64
like
there's
a
small
overhead,
but
it's
not
nearly
as
bad
as,
like
a
you
know,
a
double
lookup
table
and
like
the
the
the
names
for
the
types,
and
so
that
being
said,
like
those
are
all
kind
of
the
things
that,
like
we've,
originally
talked
about,
the
generalization
of
the
instrumentation
the
instrument
package.
A
I
mean
this
is
the
thing
like
the
meter
I,
don't
think
I
think
that's
the
the
demarcation
Point
like
having
those
methods
on
the
meter
would
be
the
part
where
the
the
generalization
for
the
generics
jumps
off
and
I
think
the
instrument
package.
When
you
start
looking
at
how
you
can
use
generics
there,
like
it
cleans
up
by
a
lot,
I
mean
every
single
option.
We
have
every
single
instrument
we
have
is
duplicated
because
it's
always
a
float,
64
and
an
n64..
A
If
you
try
to
put
this
all
in
one
package,
cutting
this
in
half
is
significant,
and
especially,
if
you're
going
to
be
adding,
you
know
another
with
this,
like
nine
six,
six
new
options
and
six
new
configs
and
six
new
new
methods
like
versus
you
know,
so
that's
18
different
additions
to
the
docs
versus
nine
would
be
added
if
we
made
generics
over
it.
I
think
that's
like
that's!
A
It's
worth
you
know,
considering,
because
that's
a
significant
Improvement
and
so
I
think
that,
like
it
also,
it
means
that,
like
our
instrumentation
like
in
the
SDK
yeah
or
that's
the
last
thing,
like
our
implementations,
if
you
look
at
this
proposal
like
it
starts
to
be
a
problem
because
you
can't
generalize
these
instruments
anymore,
the
the
generalization
leaves
the
window,
because
this
is
this
is
generic
right,
and
so
you
could
put
a
generic
there,
but
this
no
longer
is
generic,
so
the
method
type
is
dependent
on
a
single
type,
and
so
you
have
to
have
a
particular
implementation
for
every
single
instrument,
which
I'll
be
honest.
A
It's
not
like
the
end
of
the
world
like
that's
just
maybe
something
you
have
to
take
on,
but
I
also
think
that
it's
like
it's
something
we
may
want
to
consider.
There's
a
I
mean,
like
I,
say
proof
of
Concepts,
but
it's
I
mean
this
I,
don't
even
think
it
can.
It
definitely
doesn't
compile
I
didn't
build
it
out.
It
just
shows
like
what
I
would
probably
recommend
in
the
instrument
package
and
that's
again,
it's
really.
You
know
limited
to
that.
A
It's
not
fully
thought
out,
there's
still
a
lot
of
like
issues
I
think
to
to
address
here,
but
it
is
showing
something
you
know
on
the
order
of
yeah
like
half
the
the
lines
of
Code
by
adding
generics
just
to
the
instrument
package.
So
it's
a
lot
of
me
talking
that's
my
case.
I
would
love
to
hear
what
others
think,
though,.
D
Seems
like
a
pretty
compelling
case
to
me,
I
think
you
know,
based
on
the
discussion
we
just
had
around
attributes
and
extensibility.
We
probably
have
to
go
the
options.
Route
on
instruments
and
I
would
really
hate
to
see
us
not
be
able
to
use
the
generics
in
the
SDK,
because
we
all
agree
that
that
provided
a
pretty
significant
implementation
benefit
there
and
Clarity
benefit
and
so
unwinding.
All
of
that
would
would
be
no
bueno.
A
Yeah,
you
know
boho
and
naive.
We
are
I've,
been
thinking
this
wouldn't
extend
beyond
120.,
but
you
know
here
we
are
and
and
so
like
yeah
I
I
agree.
Yeah.
A
D
A
Yeah,
which
is
annoying
at
times
but
I
I,
don't
think
that
actually
is
gonna
bite
Us
in
the
butt
at
this
particular
juncture,
like
all
of
our
interfaces,
are
well
suited
because
they're
like
like
again
like
it's
the
instruments,
the
instruments
are
already
split
on
numbers
so
like
yeah,
the
whole
instrument
makes
sense,
yeah.
B
A
That's
a
that's
a
good
question,
so
that
kind
of
bleeds
into
the
next
topic
of
the
RC
as
well.
I.
Think
right,
so
I
I,
see
I,
see
two
PRS
here.
Right,
I
see
a
generics
refactor
the
API
and
an
options.
Pr
right
and
there's
still
open
questions
on
the
options.
Pr,
the
generics
PR,
there's,
there's
an
option.
There's
there's
I
think
an
open
question
about
the
The
Observers
that
that
gets
a
little
funky
we're
at
44
minutes.
A
So
I
don't
know
if
we
want
to
go
too
much
into
it,
but
I
would
probably
just
say
like
maybe
take
a
look
at
that
POC
because
there's
like
and
specifically
go
look
at
the
the
the
asynchronous
stuff
there
because,
like
there
is
a
because
of
register
observable
I
can't
remember:
I
can't
remember
the
method
on
the
the
meter.
A
You
need
to
be
able
to
pass
both
types,
both
number
types
of
instruments
to
that
method
and
the
when
you
register
or
when
you
create
a
new
observable
and
there's
the
Callback
that
you
want
to
register.
Just
for
that
instrument.
You
need
to
be
able
to
pass
just
a
generic
observable
type
there.
So
there's
like
a
different
level
of
interfaces
there
and
then
our
Observer
structure
gets
a
little
funky
and
related
to
the
embedded
package.
A
I,
don't
think
it's
intractable
I've
been
thinking
about
this
for
six
hours,
maybe
yesterday
or
the
day
before,
right
like
it's
not
like
I,
think,
intractable,
I
think
there's
Solutions
there
so
to
your
question.
Aaron
I
think
that
I
think
this
would
push
it
back.
You
know
I
feel
like
I
could
have
a
PR
ready
for
this
both
tomorrow
and
you
know
the
review
cycle.
A
That's
the
question
right
is:
how
long
is
that
review
cycle
going
to
go
and
then
did
we
cut
another
minor
release
and
if
that's
the
case,
there's
another
PR
to
pull
back
the
globals.
So
there's
three
PR's.
If
that's
the
case
and
then
once
we
pull
another
minor
release,
I
don't
see
anything
against
making
an
RC
the
next
day
you
know
add
back
into
globals
make
another
RC.
A
So
you
know
if
we're
looking
at
that
I'd
say
next
week,
plus
two
weeks
for
the
soap
time
of
the
RC,
depending
on
the
release
or
the
review
cycle
on
that.
So
it
would
push
it
back.
That
is,
that
is
true.
A
That
being
said,
I
like
as
Robert
knows,
I
am
painfully
aware
of
our
timeline,
trying
to
get
this
out
as
soon
as
possible,
but
I
also
don't
want
to
rush
this
to
the
point
where
we
release
something
we're
going
to
regret
for
the
next
five
years.
B
I'm
I'm
totally
on
board,
like
I'm,
not
saying
we
shouldn't
do
this
because
of
timelines
like
that's
that's
the
last
thing,
you'll
ever
hear
me
say:
yeah,
but
I'm.
Just
we're
gonna
have
to
report
this
up
to
the
people
who
care
about
this.
So.
A
Yeah
and
and
I
mean
I
I'm
already
under
the
gun
for
a
while
now
to
get
this
out
so
I,
yeah
and
I.
Thank
you
for
asking
that,
because
I
think
it's
it's
something
that
we
want
to
recognize.
It's
not
it's
not
trivial!.
C
D
Yeah
plus
one
there
have-
you
discussed
this
at
all
with
logdon
or
other
collection
maintainers
to
get
their
view
on
what
it
will
mean
for
them
to
have
significant
changes
in
the
API
like
this.
A
A
Okay
and
specifically,
we're
asking
for
feedback
on
the
generics
right,
because
I
think
that
we're
all
like
I,
don't
like
the
options
stuff
is
like
that's
right.
D
D
A
Yeah
again,
like
that's
a
question
yeah
exactly
so,
okay,
yeah
I
will
I'll
take
that
as
an
action
item.
So
then
you
know
just
kind
of
to
recap:
on
the
the
RC.
Is
everyone
okay,
with
pulling
back
and
doing
another
minor
version?
Or
is
this
like
I
mean
that's
kind
of
what
I'm
getting
from
this
group
right
I
see
Aaron
shaking
his
head.
D
So
we
would
pull
back
the
global
changes
and
release
115
as
is,
and
then
put
levels
back
and
started
the
116
RCS
with
the
generic
changes.
B
I
have
a
question:
do
we
want
to?
Maybe
is
there
a
reason
why
we
don't
just
pull
back
the
globals
and
leave
it
as
an
open
PR
until
we've
actually
are
ready
to
do
the
RCs
like
I
figure?
This
is
going
to
be
a
release
like
there's
going
to
be
a
115
and
then
we're
going
to
need
a
release
of
the
generics
at
least
once
right.
A
So
we
I'm
not
following
like
yeah,
we
released
the
115
in
like
the
v038
I,
think
we're
up
to
and
the
v038
would
be
the
metric
okay
yeah
sorry
like
yeah,
that
was
that
was
kind
of
at
all.
I
didn't
know
what
the
number
was.
D
A
Yeah,
it
also
means
that
you
have
to
keep
that
pure
current,
which
is
not
kind
of
yeah.
It's
kind
of
a
pain
in
the
butt,
because
a
lot
of
the
implementation
changes
changes
the
global
implementation.
So
you
have
to
update
the
global
implementation
and
then,
if
you're,
moving
the
global
implementation
at
the
same
time
from
the
internal
to
the
metrics
internal
like
there's,
conflict
I'm
not
opposed
I'm,
not
opposed,
but
the
thing
is
is
also
like
I,
like
I,
see
like
we
could
release
this
in,
like
I.
A
Don't
know
like
the
next
day,
put
globals
back
in
to
make
another
RC
with
the
globals
at
the
top,
because,
like
I,
don't
know
like
it
seems
like
it's
RC,
like
the
only
reason
I
think
you'd
want
to
pull.
This
back
is
because,
like
there's
significant
changes
to
come
out
in
our
like
in
an
RC
right,
so
I,
you
know,
I
could
just
see
that,
like
you
know,
put
this
back
in
and
then
you
know,
release.
B
A
A
A
We
pull
this
out
on
I,
don't
know
next
Tuesday
and
then
we
pull
this
and
release
it
on
next
Wednesday.
Then,
like
two
weeks
from
next
Wednesday,
we're
saying
like,
are
we
ready
to
go
versus?
Like
you
know,
we
let
this
soak
for
two
weeks
and
then
we're
like.
Okay,
let's
make
an
RC
and
then
two
weeks
from
that
one
we
can
go.
A
I
agree,
I,
think
I,
think
yeah,
the
the
gating
for
an
RCB
coming
released
is
collectors
updated
and
it's
been
out
at
least
two
weeks.
I
think
those
are.
Those
are
I'm
on
the
same
page,
yeah.
D
A
Anyways,
okay,
cool
we're
running
really
late
on
time.
That's
a
big
issue.
I
think
we've
made
a
lot
of
progress
here,
but
still
you
know
I
definitely
recommend,
like
we
kind
of
jump
into
this.
The
arguments
here
to
have
more
to
think
about.
Like
definitely
some
of
this
set
stuff,
think
about
it.
The
option
stuff
think
about
it
definitely
go
and
comment.
A
Aaron
I'll
pass
it
over
to
you
for
the
Prometheus,
with
namespace.
B
So
this
does
have
necessary
reviews
and
whatnot,
but
this
is
key
to
getting
the
collector
actually
transitioning
away
from
open
census
to
open
telemetry
now
open
tracing.
B
But
so
I
just
wanted
to
bring
it
up,
make
sure
that
there
was
ample
eyes
that
we
are
okay
with
this
going
forward
and
if
so,
then
I'll
probably
merge
it.
After
this
meeting.
B
A
Yeah
I
will
add
this
to
the
116,
Milestone
or
115
Milestone,
then
just
to
make
sure
we
don't
get
that
order
of
operations.
Incorrect
Anthony.
Have
you
taken
a
look
at
this
I
know
you're
more
involved
with
all
of
the
other
things
I.
D
I
haven't
taken
a
look
at
that
particular
PR,
but
I
know
aware
of
its
need
and
I
trust
that
if
everybody
else
has
looked
at
it,
it's
probably
fine,
it
should
be
a
fairly
straightforward
change.
I
would
expect.
B
Yeah
I
mean
it's
adding
a
prefix
to
all
the
Metro,
only
the
metrics
that
Prometheus
exports,
which
seems
to
be
something
that
was
done
in
previous,
like
open
census
and
whatnots.
But
we
don't
have
a
particular
way
of
doing
that.
I
recommended
views,
but
there
there's
some
complication
there.
So
yeah.
D
And
this
is
kind
of
like
or
open
Telemetry
the
instrumentation
Library
kind
of
is
intended
to
meet
this
need.
We
talked
a
lot
in
the
Prometheus
working
group
about
how
to
make
an
an
API
for
expressing
that
namespace
through
instrumentation
Library,
but
even
that
we
didn't
really
settle
on
and
I
think
the
collector
needs
it
to
be
broader
than
that
anyways.
It
would
need
it
either
at
the
exporter
or
at
the
meter
or
meter
provider
layer.
D
A
All
right
anything
else
that
we
want
to
talk
about
where,
at
the
end
of
the
agenda.
A
C
C
A
Okay,
well
we're
three
minutes.
Any
quick
uses
of
Hotel
people
would
like
talk
about
exciting
stories.
A
I
know
one
of
the
cool
things
I
heard
this
week
in
the
instrumentation
go
instrumentation
say
with
edpf
is
that
there
are
people
at
I,
think
honeycomb
we're
trying
to
have
customers
start
music.
So
that's
kind
of
interesting.
It's
it's!
It's
green!
We're
about
to
do
an
alpha
release.
It's
very
Alpha,
so
I
think
that
was
kind
of
a
cool
thing
to
hear.
A
Okay,
yeah
definitely
clockworthy
I.
Think
with
that,
then
we
could
probably
end
it
here.
Thanks
everyone
for
joining
we'll
see
you
all
virtually
or
next
week
same
place
same
time,.