►
From YouTube: 2023-03-16 meeting
Description
Instrumentation: Messaging
A
B
I
know
Roberts
I
can
make
it
I
know
well,
I,
don't
know
I'm
guessing
Aaron's,
not
gonna,
make
it
as
well.
He
was
out
this
week
right,
Anthony.
A
Okay,
David's
also
out.
A
C
B
I
guess
for
three
minutes
past
this
might
be
just
what
we
get
cool.
Let
me
start
sharing
that.
B
Awesome
yeah,
if
you
all
have
something
you
want
to
talk
about
as
well,
please
feel
free
to
add
to
the
agenda.
B
B
So
this
past
weekend
there
was
some
feedback
from
Bogdan
about
this
design
for
our
interfaces,
which
I
think
it's
a
little
confusing.
There's
some
I
think
technical
stuff,
that's
a
little
bit
out
of
place,
but
it's
an
interesting
idea,
so
maybe
just
kind
of
walk
through
this,
because
this
is
the
thing
that
kind
of
sparked
there's,
also
a
bunch
of
other
cleanup
I,
think
I
found
from
the
API
in
the
process.
That's
the
long
and
short
story
of
this,
but
maybe
just
to
start
off
here.
B
So
one
of
the
things
that
you
kind
of
pointed
out
is
that,
like
currently,
we
have
like
these
embedded
interfaces
where,
like
the
synchronous,
is
used
as
this
grouping
mechanism,
so
like
a
counter,
actually
has
this
embedded
in
it.
What
this
means
is
that
any
implementation
of
the
64
counter
has
to
embed
the
synchronous
interface
in
it,
and
we
talked
about
this
before
in
the
tracing
API
design
before
we
released
it.
B
But
what
this
also
means
is
so
due
to
that
fact
that
it
has
to
embed
something
here,
there's
an
implicit
extension
to
it
so
say,
like
the
synchronous
interface
here,
added
a
method
to
it
that
all
you
know,
synchronous
instruments
had,
then
all
implementations
would
inherently
include
that
method.
They
would
compile
still.
B
So
we
would,
you
know,
survive
the
the
compile
guarantee,
but
they
would
Panic
at
runtime
is
the
is
the
thing
here-
and
we
talked
about
this
during
the
tracing
API,
because
it's
a
way
to
get
essentially
yeah,
okay,
I'll
say
like
just
to
get
around
the
the
compatibility
guarantees
that
go
kind
of
states
that
we
don't
actually
guarantee
in
this
project.
B
But
we
look
at
grpc
who
also
have
something
similar
to
this,
where
there's
private
methods-
and
they
also
require
you
to
embed
if
you
wanted
to
Implement
some
sort
of
interface
and
there's
a
lot
of
consternation
in
that
project.
For
doing
that,
like
there
wasn't
like
they
weren't
really
excited
for
that
solution,
because
it
implicitly
required
you
to
do
these.
B
Like
you
know,
massive
checks,
anytime,
there's
an
upgrade
otherwise
you're
your
code
could
ship
without
it,
realizing
that
it's
going
to
panic
at
runtime,
which
I
think
is
a
fair
critique,
and
that's
that's
why
we
didn't
want
to
do
that
in
the
tracing
API.
What
Bogdan
is
pointing
out,
though,
is
that
you
could
also,
in
your
implementations,
provide
some
no
op
implementation
of
that,
and
what
that
means
is
that,
instead
of
implementation,
embedding
the
interface,
they
could
also
just
embed
the
no
op
implementation
of
the
API.
B
So
here
in
specifically,
it
would
be
some
sort
of
float64
counter,
and
then
you
could
also
provide
some
sort
of
no
op
float.
64
counter
I.
Think
that's
a
kind
of
a
great
idea
at
first
I
was
like
well,
it
doesn't
really
win
us
anything
because
you
know
there's
still
this
problem,
that,
like
you,
know
the
user,
there's
nothing
telling
the
user
that,
like
you,
know
that
they're
going
to
need
to
implement
this,
no
opposite
to
get
a
no
Behavior.
B
B
We
have
forward
compatibility
because
that
they've
they've
made
an
explicit
Choice
like
they're,
either
saying
like
yeah
I
know
the
inner,
like
methods
are
going
to
be
added
to
this,
and
that
means
that
I'm
either
going
to
choose
that
it
will
Panic
or
it
will
be
a
no-op.
That's
how
I've
got
compatibility
setup
going
forward,
which
is
it
makes
it
an
explicit
choice
on
the
SDK
authors
side.
B
So
it
actually
sounded
like
a
good
idea
to
me
because
it
kind
of
gets
around
that
grpc
consternation,
because,
instead
of
it
just
being
a
panic
at
runtime,
it
would
be
a
no-op
and
it
won't
Panic
at
runtime.
It'll
just
have
an
unimplemented,
behavior
and
I.
Think
that
that's
fair,
you
know
and
I
think.
If
there's
there
can
be
completely,
you
know
it
could
also
be
that
you
know
we
find
that
users
are
like
yeah,
that's
great,
but
I
actually
wanted
to
log
an
error.
B
So
there's
nothing
stopping
us
from
saying
like
Okay,
we
could
also
provide,
or
some
other
you
know,
project
could
provide
like
an
error
implementation
that
everyone
could
have
bet.
I
know
it
just
provides
like
essentially
like
an
explicit
choice
for
SDK
implementers
I
said
what
they
want
the
default
Behavior
to
be,
and
that
seemed
like
a
positive
design
to
Choice.
It
also
addresses
some
of
the
compatibility
issues
for
adding
things
in
the
future.
C
I
think
this
will
run
into
the
same
issue
that
you've
got
an
open
issue
for,
for
the
you
know,
lot
meter
implementation
meter
provider
is
the
only
way
to
get
a
meter.
Meter
is
the
only
way
to
get
an
instrument.
A
B
That's
true
yeah,
so
I
I,
don't
know
if
it's
outside
of
the
scope
of
the
specification.
B
Specifically
because
the
specification
it's
written
in
saying
that
the
no
up
implementation
cannot
provide
a
way
for
a
user
to
create
an
asynchronous
counter,
so
I
think
it's
on
the
line
and
where
it
falls
on.
That
line
is
not
entirely
clear
to
me
because,
like
in
our
existing
situation
for
three
eight
eight
six
I
created
like
this,
this
is
literally
providing
a
function
to
create
a
meter
outside
of
the
meter
provider
like
I.
Think
that's
right.
C
B
Yeah
I,
yeah
and
so
I,
and
so
the
way
I
see.
That,
though,
is
that,
like
the
API
itself,
is
not
providing
a
way
to
create
that
it's
just
providing
a
way
that
users
can
use
the
go
I,
don't
know
the
go
language
itself
to
create
an
implementation
of
that.
That
being
said,
I
can
definitely
see
the
point,
and
I
can
see
that.
That's
maybe
not
something
we
want
to
include,
but
I
also
think
that
this
is
an
area
of
the
specification
that
could
be
changed.
B
I
I
I'm
not
exactly
sure
why
we
require
this
to
only
get
up
well,
I,
think
I
do
so
I
think
I
think
if
the
no
op
requires
this,
because
it
was
written
based
on
what
the
API
I
already
had
and
I
think
the
API
had
something
in
mind
for
the
SDK
like
the
SDK,
when
it
was
talking
about
implementations,
it
doesn't
want
any
other
way
for
these.
These
objects
to
be
created
and
I.
B
Think
that's
fair
because
in
in
the
API
I
think,
if
there's
only
one
way
that
you
should
be
using
it
and
that's
to
implement
the
API,
not
you
know
creating
a
meter
out
of
thin
air
without
the
correct
pipeline
to
associate
it
with
like
that,
doesn't
make
any
sense,
but
I
don't
so
that
then
the
no
op
came
along
and
it
adopted
the
same
idea,
but
I
don't
think
at
the
no
op
specifically
actually
needs
these.
B
So,
like
you
know,
if
you
think
about
it,
like
the
the
purpose,
there
is
not
necessarily
like
to
restrict
the
you
know
creating
a
meter,
because
the
pipeline
doesn't
know
how
to
process
it.
Well,
the
pipeline
is
not
going
to
process
anything
in
the
NOAA
right
like
having
having
a
creation
of
a
meter,
isn't
necessarily
going
to
hurt
the
no
op
implementation.
So
I
I
wonder
if
this
is
an
area
where
the
specification
could
actually
be
updated
to
allow
explicitly.
C
B
C
Right,
if
that
new
method
is
something
where
a
no-op
implementation
doesn't
make
sense
or
is
explicitly
quite
wrong,
because
it's
meant
to
change
the
state
of
something
and
doesn't
change
its
state.
What
then
well
I
mean
you
won't
have
compile
failures?
Yes,
you
won't
have
a
panic,
but
now
you've
got
an
incorrect
implementation.
C
Right
so
a
user's
got
what
they
expect
to
be
a
functioning
SDK.
They
get
an
instrument
from
it
that
they
expect
to
function,
but
that
an
instrument
has
methods
that
are
implemented
by
a
no-op,
that's
embedded
and
don't
actually
do
anything.
B
Right
and
I
think,
if
that's,
that
is
not
a
situation
that
I
would
want
to
run
into
and
I
think
that
in
the
SDK
I
would
rather
have
a
build
failure
or
have
a
panic,
but
I
think
that
there
are
other
SDK
authors
out
there
that
that's
not
what
they
want.
I
think
that
I
think
that
decision
of
whether
they
want
it
to
be
a
no-op
is
up
to
them
at
that
point,
I
think
that's
what
this
introduces.
It
introduces
that
option.
C
I'm
not
sure
that
that's
an
option
we
should
be
introducing,
though,
like
because
that's
then
the
SDK
author
making
a
choice
on
behalf
of
the
application
author
who's
trying
to
use
that
SDK
in
a
way
that
the
application
author
may
not
even
know
that
that
choice
has
been
made
for
them
and
may
end
up
in
a
scenario
that
they
are
either
getting
bad
data
incorrect
data,
not
the
data
they
expect
and
are
completely
oblivious
to
it.
B
A
B
B
Right,
but
that's
what
I'm
saying
like
what
what
your
definition
of
correct
is
is
subjective
here.
Right
like
this
is
I,
think
the
the
question
that
a
lot
of
people
would
like
to
know
like
that's
what
I'm
saying
like
it's
a
it's,
an
explicit
Choice
when
you
introduce
something
like
this.
Currently,
it's
not
an
explosive
Choice.
Currently,
it's
a
just
a
compilation
error
like
we've
already
made
that
choice
for
people.
B
Actually,
we
didn't
I
take
that
back
so
like
so
right
here,
if
we
add
something
to
the
synchronous
instrument
or
there's
some
sort
of
like
method,
that's
added
to
the
photo
64
counter.
Currently
they
already
have
to
embed
this
right
to
have
it
be
correct,
so
there's
already
going
to
be
a
panic
at
runtime.
For
them,
it's
not
going
to
be
a
compilation,
error.
C
B
Yeah,
that's
true,
although
the
next
issue
on
the
agenda
also
points
out
that,
like
the
a
circus
can't
get
removed
because
we
need
it,
we
still
need
this
grouping
mechanism,
it's
used
in
the
register
callback,
and
so
at
some
level
you
need,
you
know,
I
I
say
you
know,
rename
that
to
observable
and
that's
what
this
PR
does.
But
it
still
is
some
sort
of
way
that
we
we
group
across
these
interface
or
these,
these
instruments.
B
And
I
think
that's
fair,
because
I
think
grouping
across
them
is
is
useful
in,
like
this
likeness
I
definitely
think
it's
needed.
I
think
that's
a
that's
a
solid
approach
for
the
Asic
or
the
observables,
the
synchronous
I,
don't
know
if
there's
a
need
to
group
them,
so
synchronous
is
removed,
but
I
think
that
there's
something
that's
implicit
like
that
is
still.
That
is
helpful.
Like
not
having
something
compile
is,
is
you
know
an
issue
we
talked
about
last
week
is
a
big
issue
for
a
lot
of
Developers
for
SDK
authors.
B
It's
not
necessarily
something
that
we
have
an
issue
with
I
think
we
appreciate
that
as
a
as
the
the
official
SDK
like
we
don't
want
to
ship
any
SDK
with
unimplemented
features
and
I.
Think
that
there's
a
way
to
approach
that
I,
don't
think
I
know,
there's
a
way
to
approach
that.
In
fact,
I
wrote
a
little
proof
of
Concepts
here
for
how
to
actually
Implement
what's
what's
being
proposed
in
this
issue,
and
what
that
does.
Is
it
just?
B
You
know
it
embeds
the
interface,
so
there
would
be
a
panic
at
runtime
and
then
it
calls
using
the
reflect
package
everything
everything
that
actually
is
a
method
of
the
interface.
So,
like
you
know,
if
you
take,
for
instance,
like
this
interface
here,
this
float
64
Observer.
It
passes
in
whatever
our
implementation
of
that
interface
is
to
this
function
here,
and
that
function
here
goes
through
every
single
method
of
the
the
type
it
has.
It
calls
it
if
it's
not
exported.
B
Obviously
it
doesn't
call
it,
but
if
it
is
exported,
it
calls
it
and
it
should
not.
Panic
is
the
idea,
so
in
it
we
already
have
a
built-in
mechanism
to
validate
that
we
are
implementing.
Everything
is
that
we
still
have
the
correctness,
guarantee
that
we're
looking
for
from
the
compilation
that
ends.
If
we
forgot
to
embed
something,
the
compilation
does
fail.
B
Yeah
I
mean
it's
a
test
in
the
SDK
and
in
the
know
up
but
yeah
it
is
I
mean
so
that's
the
other
thing
is
like.
Then
we
could
provide
that
like.
If
you
look
at
that
test
like
it's,
nothing
that
you
can't
provide
that
functionality
to
the
end
user,
like
it
literally
you
could
I
could
restructure.
To
just
be
like
give
me
your
media
provider
implementation,
you
meet
a
provider
there's
a
few
things.
B
Give
me
like
three
different
things
that
you
actually
have
and
I'll
go
down
the
chain
of
causality
and
check
to
make
sure
that
everything
is
implemented
correctly.
But
you
know
like
there's
some
there's
nothing
to
like
stop
us
from
exploring
something
like
that
and
I
think
that
it
still
provides
that
same
guarantee
that
people
want
in
in
shipping
something
that
they
know
is
correct.
You
know,
I
think
I
mean
I
I.
B
In
my
mind,
as
well
to
having
a
compilation
error
because
you
catch
it
at
the
earliest
possible
Point
in
the
development
cycle
that
you've
failed
to
do
something
right,
but
then
I'm
also
hearing
that,
like
the
other
side
of
the
argument,
is
like
you
know
like
this,
does
you
know
impose
a
decision
on
SDK
authors
right
like
it,
so
the
upgrade
path
for
an
SDK
author?
B
You
know,
that's
actually
a
good
question
so
say
like
we
do
like
some
sort
of
like
ad
link
thing
here.
I,
don't
know
what
the
ad
link
equivalent
yeah
just
say,
like
literally
there's
like
an
ad
link
method
that
gets
added
here.
If
instrumentation
like
the
API
starts,
you
know
using
that
new.
You
know
the
one
point,
I
don't
know:
1.2
version
of
API
and
then
the
SDK
of
some
sort
of
other
you
know
vendor
is
using.
You
know
some
sort
of
implementation
of
the
1.1.
B
Are
they
still
able
to
actually
use
that
right?
So,
like
the
question
is,
is
like
you
know,
the
vendor
is
scrambling
to
try
to
like
implement
the
ad
link
beforehand
but
say
the
customers
of
that
vendor
are
like.
Well,
let's
see
if
it
still
works
like
they
just
don't
get
a
link
added
at
that
point
right.
It
just
drops
it
on
the
floor
because
they've
been
implemented,
the
no
op
and
since
the
no
op
is
implemented
from
the
1.2
and
it's
imported
back
into
the
SDK.
B
The
question
is:
is
it
I
guess
imported
back
into
the
SDK?
You
know?
Is
there
a
backwards
compatibility,
that's
introduced?
There
is
the.
C
B
B
Right,
okay,
so
you're
right,
yes,
okay!
That
is
right!
So
it
you
know
in
that
situation,
right
like.
If
we
didn't
do
this,
then
we
didn't
provide.
You
know
these
SDK
authors
with
an
explicit
ability
to
choose
the
no-out.
The
the
vendors
customers
are
just
going
to
fail
right,
like
their
their
application,
is
not
going
to
compile
anymore.
C
B
C
B
No
I
I
definitely
agree
like
I.
Don't
think
this
is
a
true
abstract
class
that
has
like
some
sort
of
Base
Class
that
you
can
actually
do
or
you
can
you
can
choose
here.
The
thing
is,
though,
like
kind
of
what
you
said
like
there
is
an
incorrectness,
that's
actually
going
to
be
introduced,
I
think
that
that's
something
that
is.
B
I
agree,
I
think
if
that's
something
that's
a
problem,
but
I
also
agree
that,
like,
but
I
also
think
that
that's
a
decision
that
we're
making
for
SDK
authors
that
we
don't
have
to
because,
like
in
the
SDK,
the
open,
Telemetry
SDK
right,
we
can
make
that
choice
and
say
like
okay.
Well,
the
the
Upstream
is
like.
That's
that's
not
going
to
work
like
it's
going
to
panic
and
you're
going
to
have
issue,
so
you
have
to
you
have
to
roll
both
of
those
updates
right.
B
But
an
SDK
author
may
say
like
well.
That's
fine,
but
like
literally
we're,
never
going
to
support
links
for
counters
or
something
like
that
right.
So
adding
links
is
always
going
to
be
a
no-out
for
us.
So
like
it's
incorrect
Behavior,
but
like
that's
just
always
going
to
be
the
behavior
that
we're
going
to
support
anyways.
So
our
customers
are
going
to
have
to
understand
that
like
yeah
instrumentation
that
they
have
may
be
doing
linking
there,
but
we're
not
supporting
any
blinking.
So
it
seems
like
that's
a
choice
they
would
want
to
make
anyways.
B
C
There
examples,
though,
where
vendors
are
explicitly
not
implementing
things,
I
mean
I
know
there
are
vendors,
who
have
released
sdks
that
have
additional
capabilities
that
don't
exist
in
the
canonical
SDK,
but
I'm
not
aware
of
anybody,
who's
stripping
functionality
out
and
say
you
know,
these
things
are
no
Ops.
Now.
B
I
mean
one
of
the
things
that
comes
to
mind.
Is
that
streaming
implementation
that
I've
seen
where
you
know
a
lot
of
the
any
any
sort
of
method
that
is
on
a
span
that
updates
the
span
doesn't
actually
do
anything
like
it's
just
whatever
the
start
condition
of
the
span
was
like,
that
is
the
span
that
gets
created
and
then
there's
a
single
at
the
end
right,
any
update
in
between
is
a
no-op.
B
B
But,
like
you
know,
if
we
make
that
choice
for
them
like
here,
it's
like
okay.
B
Look
I
want
I,
want
the
Ford
compatibility
Behavior
here
to
panic,
because
I
want
my
thing
to
always
provide
real
open
television
rise
and
the
other
one's
like.
Well,
that's
great
but
like
I
just
want
to
know
up
and
yeah.
It
may
silently
like
not
work,
but
I'm
Gonna
Keep
really
actively
developing
any
sort
of
features
that
I
can
support.
I
guess
is
the
question.
B
I
also
realized
I
think
it's
25
minutes
into
this
and
I'm
still
sharing
the
screen.
I
didn't
expect
this
to
actually
get
resolved
in
this
meeting,
but
I
do
think.
There's
a
good
discussion
here.
In
fact,
I
was
kind
of
hoping
there
would
be
more
people
here
to
have
this
discussion.
B
Unfortunately,
most
of
them
are
out
on
break
I'm,
wondering
if,
like
I'm,
not
necessarily
sold
that
we
should
go
in
this
direction,
but
I
I
do
think
it's
a
good
idea
to
explore
and
I've
been
thinking
about
it
and
I
have
a
group
of
Concepts
out
and
there's
also
in
the
process,
split
off
a
bunch
of
other
issues
that
I
think
we
have
with
the
API
that
I
wanted
to
address.
B
So
maybe
we
can
kind
of
focus
back
in
on
the
the
other
issues
coming
in
after
this,
and
maybe
just
put
a
put
the
proverbial
pin
in
this
Anthony's
that
sounds
fair,
okay,
I
I
would
ask,
though
Anthony
like,
if
you
could
think
through
this
one,
a
little
bit
more
and
if
you,
if
you
still
have
like
any
sort
of
insights
that
we
haven't
covered,
add
them
to
the
issue
as
well.
I
think
if
that's
that'd
be
really
helpful,.
B
Thanks,
okay,
cool
so
next
thing,
as
Anthony
kind
of
pointed
out
in
the
process.
That
conversation
is
this
idea
that
the
asynchronous
and
synchronous
instrument-
oh
I'm,
sorry
interfaces
aren't
needed,
basically
just
ends
up
being
needed,
but
the
synchronous
isn't
so
this
could
get
removed.
B
This
was
another
thing
in
the
the
API
space
that
I
think
was
that's
not
right
needed.
I.
I
think
that
it's
worth
removing
this
at
this
point,
just
because,
like
specifically,
this
is
not
needed
and
including
this
in
the
initial
offering
for
the
API,
is
only
adding
the
burden
of
development.
C
B
Like
kind
of
what
we
talk
about,
this
also
imposes
some
sort
of
private
method,
which
in
itself
is
making
a
design
Choice
here
on
how
we
want
to
you
know,
have
forward
compatibility
and
embedding
of
interfaces,
so
there's
a
PR
out
to
resolve
this.
This
is
also
included
in
that
proof
of
concept,
but
it
needs
needs
some
reviews,
the
other
one
is
we
talked
about
this
last
week.
This
is
a
Browns.
B
The
instrument
option
so
specifically
there's
this
PR
in
the
specification
talking
about
the
Sync
API,
that's
calling
it
advice,
and
so
one
of
the
things
I
wanted
to
ask
in
this
PR
and
I
got
clarification
on
like
other
community
members.
Decisions
is
like
this
idea
that
first
off
I
asked
if
this
is
just
for
synchronous
instruments
and
I,
don't
think
this
is
so
it
needs
to
apply
to
all.
B
Instruments
is
what
Jack
is
understanding,
but
the
key
thing
here
is
that
the
advice
parameter
is
I
asked
if
it's
specific
to
the
parameters
being
just
about
the
kind
but
the,
but
the
entirety
of
the
advice
could
be
passed
to
any
of
these
instruments
and
Jack's
understanding
and
thought
was
that
that
wasn't
the
case
that
you
know
passing
advice
to
a
counter
should
be
something
that
a
counter
understands
and
I.
B
Think
that's
I,
think
that's
fair
I
think
that's
actually
a
probably
a
pretty
good
design
and
I
say
that,
because
of
the
separation
between
the
instrumentation
author
and
the
operator,
so
the
instrumentation
author
I
think
you
can
say
that
they're
isolated
enough
to
where
they
say,
like
hey,
like
I,
literally
think
that
this
instrument
should
be
a
histogram
or
I
think
it
should
be
a
counter
and
because
of
that,
I
want
to
give
some
advice
as
to
how
I
would
probably
structure
the
the
bounds
on
the
histogram
or
maybe
the
attributes
of
this
counter.
B
But
to
say
to
them
like
you
know,
I
think
this
should
be
a
counter.
But
if
you
decide
to
choose
a
histogram
I
would
recommend
these
buckets.
I
think
that
you're
starting
to
get
into
the
implementation
side,
whereas
if
a
user
on
the
operation
of
the
the
code,
that
is
their
application,
tries
to
run
something
and
says
like
hey,
like
that's
a
counter,
but
I
actually
want
it
to
be
a
histogram,
then
they
can
also
provide
like
they're
going
to
have
to
provide
A
View
to
change
that
right
or
some
sort
of
aggregation.
B
You
know
override
in
their
default
aggregations
and
in
that
same
process
they
they
have
the
tools
on
their
side
to
fix
the
bucket
side.
So
it
seems
like
that's
a
pretty
fair
API
to
say,
like
hey
like
if
you're
writing,
instrumentation,
like
you,
probably
are
just
going
to
provide
advice
specific
to
that
instrument.
B
The
problem
is,
is
that
our
current
setup
doesn't
allow
that
we
only
provide
a
specificity
down
to
these.
The
number
type
in
the
asynchronous
OR
synchronous
type,
which
is
called
Observer
or
nothing.
And
so
this
proposal
is
to
split
that
specificity
down
to
the
instrument
type,
and
we
talked
about
this
last
time
in
the
problem
with
doing
something
like
this
is
that
it
is
going
to
add
a
lot
of
options
and
clutter,
essentially
the
API
at
least
that's
what
I
thought.
I
went
it
through
and
I
actually
did
this.
B
It's
not
I
think
as
bad
as
I
thought.
It
was
going
to
be
like
there's
a
big
number
here,
but
in
the
end
of
the
day,
like
each
instrument
needs
its
own
option
and
its
own
configuration
or
config
type
and
its
own
a
new
configuration
function,
but
it
actually
isn't
like
I.
Don't
know
it's
not
too
overwhelming,
and
you
know
these
combined
options
become
pretty
simple.
B
Like
the
combines,
you
know,
Observer
config,
which
is
named
incorrectly,
you
know,
is
just
removed,
because
this
is
just
like
something
that
applies
to
all
observables
right
here.
So,
like
these
combined
options
become
pretty
straightforward.
There's
a
little
bit
of
a
bloat
in
trying
to
implement.
You
know
things
like
you
know
the
main
with
unit
and
that
kind
of
stuff
just
because
you
have
to
implement
like
I,
don't
know
12
different
apply
options,
but
that's
a
that's
an
implementation
detail.
B
This
is
not
exposed
to
the
user,
so
I
think
it's
actually
a
positive
change
and
kind
of
similar
to
what
we
were
doing
with
the
span
where
we
we
split
the
start
option
from
the
end
option
in
the
beginning
before
we
release
the
trace,
API
I
think
this
is
something
that
we
would
probably
kick
ourselves.
If
we
don't
do
so,
I
I
wanted
to
try
to
you
know,
propose
that
I
think
it
needs
reviews
as
well.
C
What
does
that
do
to
the
godoc
that
gets
generated?
One
of
the
things
I
struggle
with
with
our
start
and
stop
span,
options
is
figuring
out
which
things
are
actually
valid
options
at
the
start
and
stop
because
the
ends
up
putting
the
information
in
weird
places
or
places
that
seem
weird
based
on
my
expectation.
B
Shoot
I'm
not
on
the
right
Branch.
Sorry.
A
B
Okay,
so
this
is
I
think
that
PR
change
that
we
were
just
looking
at,
so
you
can
walk
me
through
what
you
want
to
see,
but
I
can
kind
of
just
maybe
look
at
this
Anthony.
A
B
Wow
I'm
really
screwing
this
up.
Yes,
this
is
the
right
PR,
IDE,
okay,.
A
C
B
Yeah,
that's
definitely
true
being
also
to
be
fair,
though,
that,
like
we
already
had
this
problem
man,
that
was,
that
is
a
lot
with
this
option
here.
You
know
the
width
description
with
unit
is
hard
to
understand,
like
what
this
actually
applies.
To
given
option
has
the
embedded
options
in
it.
I
mean
we
already
have
this
problem.
It
is
making
it
worse,
though,
by
doing
this.
C
B
Well,
I
mean
yeah,
it
is
so
it's
it's.
These
options,
plus
the
options
below
that
we
were
looking
at
I
mean
there's
only
three
options
right
now,
there's
nothing
specific
currently
right
like
if
we
had
hints
that
each
one
of
these
would
have
its
own,
like
with
Our
advice,
so
I
keep
saying
the
wrong
thing
like
it
would
have
its
own
with
advice,
option
that
would
come
with
it.
B
Yeah
I
mean
like
to
track
like
64
counter
options
right
like
there's:
okay,
there's
eight
different
places.
It's
listed,
so
you
know
in
its
new
config
in
the
actual
definition,
but
yeah
you
have
to
you
have
to
track
it
down
through
each
one
of
these
other.
Like
multiple
option,
implementations.
B
You
know-
and
this
is
like
there's
nothing
to
say
that,
like
we
couldn't
split
this
up
and
not
have
these
conglomerate
ones
but
like
as
we
were
kind
of
talking
when
you
know
we
did
this
for
the
flip
64
observable
options
like
David
Kinder,
pointed
out
that,
like
repeating
this,
like
you
know
with
description
for
each
one
of
these
is
going
to
just
be
like
Madness
like
it
would
put
it
closer
in
the
documentation,
but
then
there'd
be.
You
know
three
options
for
each
one
of
these
flow
64.
B
C
Yeah
I'm
not
sure
that
there
are
any
good
choices
to
be
made
here
really,
but
I
do
want
to
make
sure
that
we
we
consider
what
impacts
this
will
have
on
things
like
the
documentation
and
how
that
either
helps
or
hurts
users
trying
to
figure
out
what
they
can
do
at
any
given
point
yeah.
B
And
I
I
agree
like
I.
Definitely
think
it's
it's
helpful
to
try
to
be
able
to
just
like
I
mean
the
thing
is
like
they're,
not
even
gonna,
I.
Think
they're,
probably
not
gonna,
come
here.
First
right
like
this
is
where
they're
going
to
start
and
they're
going
to
be
somewhere
in
this
meter
and
like
they're,
going
to
be
like
okay,
cool
I
need
to
start
a
counter
like
what
do
I
do
here,
am
I
going
to
go
over
to
here
and
they're
gonna,
be
like
all
right.
There's
nothing
right!
Yeah
yeah!
B
You
know
there's
nothing
to
say
that,
like
we
can't
like
I,
one
thing
that
we
could
do
is
like.
If
we
could
in
this
description
link
to
like
you,
know
the
N64
I
guess,
N64
doesn't
really
like
the
so
something
like
here
right
say
like
here
like
this.
Also,
could
you
know,
go
look
at
the
N64
observable
options
and
go
look
at
the
you
know
the
options
and
maybe
I,
don't
know
how
to
link
here.
I
think
it's
possible
in
the
docs.
B
C
I
think
it
would-
or
at
least
it
would
provide
a
start
right
and
maybe
yeah
it
follows
ends
up
following
several
chains
of
those,
because
you
know
we
point
from
here
to
N64
observable,
which
then
points
to
the
option,
or
you
know
whatever
it.
B
B
Yeah
I
mean
like
the
key
thing
that
I
want
to
like
get
across
is
though,
like
I,
definitely
think
we
should
try
to
focus
on
this,
but
also
like.
We
need
to
provide
that
functionality
of
being
able
to
specify
down
to
the
instrument
it's
hard
to
like
it
may
seem
like
we
don't
need
to
right
now,
but,
like
I,
am
I'm
worried
at
the
long-term
compatibility
API
that
we're
going
to
need
it.
So
I
wanted
to
try
to
focus
on
it
at
this
point
in
the
game.
C
B
I
was
thinking
about
that
last
night
as
well.
I
think
you
might
need
four,
but
even
then,
unless
we
put
generics
in
the
API,
which
we
almost
could
but
yeah
I
agree
this.
This
is
kind
of
a
disaster
in
that
sense,
anyways,
so
yeah,
please
I,
think
take
a
look
at
this
I
think
it's
worth
moving
forward.
This
proposal
I'll
try
to
update
afterwards.
Let's
see.
A
B
But
yeah
I
think,
if
that's
that's,
probably
one.
We
probably
want
to
take
a
look
at
next
step.
I
think
that
this
is,
we
already
talked
about
yeah
we're
gonna
talk
about
this
there's
a
PR
de
rahu,
specifically
this,
but
also
moving,
but
no
up
is
oh.
That
is
the
movie
that
I
want
one
this.
This
is
a
big
one
like
unless
we
change
the
specification.
B
This
is
not
compliant,
which
we
might
change
the
specification,
but,
like
I,
don't
know,
I
just
wanted
to
call
this
out,
because
currently
this
is
something
we
need
to
address
like
there's,
there's
no
on
the
line
with
this
one
like
we
literally,
are
providing
a
way
to
create
a
new
meter.
Currently
yeah
I,
don't
know
if
there's
too
much
more
to
talk
about
that.
B
Yeah
there's
also
kind
of
this
issue
where
currently
we
have
these
Observer
configs,
which
they
apply
to
observables.
So
it's
just
a
rename
there's
a
PR
App
for
it
I
think
if
we
I
think
it's
pot
like
there's
a
current
PR
out,
but
there's
also
like
this
split
Matrix
configuration
down
to
instrument
level
I
could
just
fix
it
all
in
this
PR.
B
C
B
It's
just
going
to
be
merged
conflicts,
yeah
I
mean
the
only
reason
I
I
call
this
out
is
because
Observer
does
mean
something
in
our
API,
like
we
literally
have
like
our
64
Observer,
because
that's
the
thing
that
does
the
observation,
so
I
think
it
is
important
to
you
know,
because
it
doesn't
apply
to
observers
these
options.
So
it's
worth
worth
changing,
but
okay,
I
will.
B
Okay
cool
so
at
the
end
of
this
I
have
like
kind
of
a
meta
question
on
this
one.
So
there's
a
lot
of
changes
to
the
API
here
and
we're
in
the
release
candidate
phase,
actually
we're
at
the
end
of
the
two
weeks
of
the
first
release
candidate
phase.
So
how
do
we
want
to
proceed
with
this?
Like?
B
Is
this
something
we
want
to
back
out
the
changes
to
Maine
that
like
move
the
global,
and
we
want
to
do
another
non-stable
release
of
the
API
and
then
go
back
into
our
release
candidate
phase,
or
do
we
just
want
to
you
know,
do
the
second
release
candidate
phase
with
all
these
changes
to
the
API.
B
That's
a
good
question:
I
think
there's
a
few
but
I
think
they're
minor
one
of
them
is
going
to
be
cencov,
so
that
is
not
done.
I
definitely
know,
that's
not
done.
This
is
related
to
the
semconf.
This
is
some
kind
of
this
is
all
the
apis.
B
This
is
again
sub
kind
of
split
the
HTTP,
confident
account
and
then
all
the
other
apis,
so
it's
all
semcomp
and
then
what
we
have
merged
is
this
rap
errors
which
isn't
blocking
anything,
because
this
is
something
that
was
dealing
with
the
a
detector,
the
host
detector,
I
think
which
I
don't
know
if
that
merged.
This
is
related
to
the
API.
This
is
also
related
to
the
API.
A
C
If
something
comes
up,
that
really
does
need
to
be
addressed.
I
think
we
have
the
option
of
creating
a
release,
114x
branch
and
doing
the
114
one
114
too,.
B
Okay,
so
I
also
wonder
about
this
kind
of
thing
here,
because
one
of
my
other
questions
that
I
realized
after
the
fact
is
that
I
think
we
deprecated
a
a
global
package
in
the
RC.
So
this
is
in
1150
rc1
and
then
one
15
rc2
is
going
to
have
it's
just
going
to
remove
this
hotel
metrics
Global
package.
The
problem
is
that
if
you
go
to.
B
Yeah
I
think
just
if
you
actually
go
to
the
website
since
the
fact
that
the
RCs
don't
show
up
as
the
latest
there's
no
there's
going
to
be
no
deprecation
notice.
Here,
like
you,
can
you
can
go
to
the
RC
and
it
and
it
says
that
this
is
deprecated,
but
it
doesn't
go
to
that
by
default.
C
I
think
we're
gonna
need
to
do
that
anyways,
so
the
similar
to
what
we
just
did
with
the
o21
releases
that
we
made
to
do
more
packages
is
deprecated
right.
C
B
All
right,
yeah
I
was
trying
to
avoid
that,
but
I
didn't
realize
the
docs
aren't
gonna
docs,
actually
I,
don't
think
the
go
tooling
either
picks
up
the
RC
like
it
says
that
RC's
not
at
a
preferable
version.
So.
C
Yeah,
it
doesn't
they're
not
eligible
to
be
the
latest
version,
but
I
think,
probably
because
of
that
we
we
wouldn't
want
to
leave
a
deprecation
Tombstone
until
we're
out
of
our
C
phase
right,
because
otherwise
people
go
there
and
get
you
know
for
yourself.
You
want
to
say
it's
deprecated
go
use
this
thing.
Oh
there's!
Nothing!
There,
though
yeah.
B
Absolutely
okay,
all
right,
then
I!
Guess
that
answers
my
question.
Okay,
so
the
plan
is
to
just
you
know.
Look
at
these
changes.
We've
gone
through
today,
go
through
another
release
them
as
another
RC
event,
because
that's
what
I'm
going
to
say
on.
A
Okay,
cool.
B
All
right
final
thing
on
the
agenda
is
Robert
saw
some
activity
here
wants
to
add
a
worn
internal
login
function.
A
B
B
C
Logging
spec
have
numeric
verbosity
mapping.
C
A
Yeah
right
security
fields.
B
B
I
mean
I,
think
you
can
it
just.
It
all
goes
back
to
zero
yeah
zero
is
both
error
and
and
fatal.
B
So
if
you
do
zero
and
you
back
that
up,
that's
like
one
through
three
would
be
warned
and
then
info
would
be
like
I,
don't
know
four
through.
What's
that,
like
seven
I,
don't
know
like
that,
seems
fair
to
me,
I
think.
B
Spell
pseudo
anyways
there's
a
p
in
there:
Anthony,
yeah,
okay
and
and
then
I'll
be
command
line
too
much
I'll
fix
that
okay,
yeah
I
mean
I
think
for
everyone,
some
eyes
on
that,
but
other
than
that
I,
don't
think.
There's
much.
B
C
B
Yeah
I'll
I
think
I'll
update
a
comment,
but
what
that
actually
means,
after
the
fact,
okay
cool,
then
that
means
we're
at
the
end
of
the
agenda.
I'll
pause
here.
Does
anybody
have
anything
they
wanted
to
add
or
talk
about?
That's
not
on
the
agenda.
C
Okay,
speaking
of
logging,
I
think
we
mentioned
s-log
here
before,
but
that
seems
to
be
in
its
final
comment.
Period
looks
like
it's
going
to
be
accepted.
If
anybody
has
anything,
they
think
they
need
to
say
on
it.
Now
is
the
time
it
looks
like
they
did
add
logging
methods
with
context.
C
B
A
B
Cool
all
right,
I
think
there's
plenty
of
things
to
do
here,
so
we
could
probably
end
it
here.
Thanks
everyone
for
joining
we'll
see
you
all
virtually
or
next
week
same
place
same
time,.