►
From YouTube: 2022-05-12 meeting
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
B
A
Hot
unseasonably
hot,
usually
we
don't
see
any
hundred
degree
days
until
june
at
the
earliest,
and
we
just
got
we're
just
through
a
week
of
it.
So.
B
A
C
Yeah,
we
I
feel
like
there's,
maybe
like
two
weeks
or
something
like
that
here
we
need
ac
need,
is
a
strong
word.
You
know,
like,
I
think,
there's
probably
a
few
more.
That
would
be
nice
to
have
it,
but
yeah.
It's
just
like
very
different.
Although.
C
A
C
A
D
Headed
down
your
way
next
month,
aaron,
so
I'm
going
to
talk
for
the
the
community
day
was
accepted.
Yeah.
A
A
C
Yeah,
there's
like
monorama
is
healthier
in
portland
and,
like.
A
C
A
Yeah
there's
a
big
devops
scene
here
and
devops
days.
Austin
just
happened
last
week
and
I've
been
helping
organize
with
them
for
a
while.
Well,
I've
been
kind
of
side
volunteering
more
than
anything
else
like
that
they
need
bodies
to
move.
Things
is
really
what
it
is,
but.
C
Yeah,
I
know
the
feeling,
which
is,
I
think,
not
unsung
work
like
I
thought
that
the
thing
doesn't
go
off.
So
it's
all
about
this
little
medusa
yeah.
C
Where
are
we
at
three
minutes
passed?
We
could
probably
get
started.
Let
me
turn
that
off
cool.
I
don't
know
how
long
this
is
going
to
take.
We
definitely
have,
I
think,
some
stuff
to
talk
about
metrics
world,
but,
as
usual,
please
add
yourself
to
the
attendees
list
and
if
you
have
anything
you
want
to
talk
about,
add
it
to
the
agenda.
C
Cool
so
yeah,
I
think
that
shoot.
I
don't
know
if
this
is
completely
updated.
I
wanted
to
talk
a
little
bit
about
the
project
of
the
metrics
sdk
alpha
release.
I
know
I've
been
working
with
aaron
a
fair
amount
over
the
past
week
on
some
of
these
issues.
In
fact,
I
don't
remember
what
the
milestones
at
19
complete
we've
regressed.
That
just
means
we
added
issues
so
we're
still
about
the
same,
not
real
far.
C
However,
a
lot
of
work
specifically
has
been
done
around
this
issue
here,
and
this
is
the
reader.
If
I'm
not
mistaken
interface
and
creating
this
reader
interface,
there
is
a
lot
of
back
and
forth.
I
I
think
most
of
these
can
be
resolved.
C
If
not
all
of
them
yeah,
I
haven't
gone
through
just
yet,
but
I
think
the
majority
of
the
the
changes
that
I
have
gone
through
in
the
review
have
been
accomplished
and
anything
left
like
we
kind
of
have
the
state
where
this
isn't
going
into
the
main
branch.
So
we
still
wanted
to
change
small
details
like
that
seems
totally
fair,
so
we're
looking
to
merge
this,
so
we
need
maybe
some
more
eyes
on
it.
C
I
don't
know
if
we
need
the
strictest
of
guarantees
on
all
of
the
mergers
that
are
going
into
this
new
sdk
branch,
but
when
we're
creating
interfaces
and
that
kind
of
thing
that
are
going
to
be
more
project-wide,
I
think
that
we
do
want
to
have
a
little
more
eyes
on
them.
C
Smaller
things,
I
think,
could
be
a
little
bit
more
lenient,
but
I
don't
think
this
qualifies
as
a
smaller
thing,
so
maybe
some
more
eyes
would
be
ideal
if
people
have
time
to
review
this
afterwards,
with
the
the
caveat
that,
if
it's
you
know
not
perfect,
maybe
leave
a
comment,
but
also,
maybe
don't
let
that
block
you
from
giving
the
misapproval
but
yeah
anything
else
there.
You
want
to
add.
A
There's
been
a
lot
of
back
and
forth.
I'm
happy
to
sit
down.
I'm
happy
to
make
time
anywhere
to
discuss
this
with
anybody
for
any
length
of
time.
I'm
sure
I
could
talk
your
ear
off
for
hours.
If
you
let
me
but
yeah,
I
want
to
get
another
set
of
eyes
on
this,
so
that
we
can
continue
on
this.
One
will
unblock
the
next
issue
that
I
have
in
the
the
agenda,
which
is
the
periodic
reader
it
could
have
been
rolled
into
this
pr
it.
A
It
wasn't
just
just
so
that
we
have
kind
of
at
least
a
implementation
of
this,
so
that
we're
we
know
that
we're
building
something
that
we
can
build,
but
it's
similar
work
to
the
manual
reader
yeah,
so
review
this
first
off.
If
anybody
wants
to
take
a
dive
into
the
metrics
world,
there
are
issues
open
for
it
and
ready
ready
to
be
worked,
and
then
I
believe
the
next
step
after
this
will
be
we're
gonna
start
tackling
the
view
state
or
and
that
that's
what
it
was
called.
A
We
can
come
if
anybody
has
any
suggestions
on
a
better
name,
I'm
also
all
for
it,
because
names
are
hard,
but
I
think
this
will
be
the
next
piece
of
work
forward,
building
this
in
a
maintainable
fashion.
So.
C
Yeah
there
is
a
lot
of
I
think
activity
going
on
here,
already
just
kind
of
what
aaron's
alluding
to
is
just
like
we're
at
the
top
level.
Still
there's
a
lot
to
go.
So
if
you
do
want
to
participate
in
helping
the
metrics
sdk
development,
I
think
that
was
a
good
time
to
get
on
board
and
understand
the
basis,
because
I
think
this
is
going
to
be
the
the
entrance
point
into
complexity.
C
Looking
into
the
view
state
personally
like
this
is
where
things
start
to
get
complex,
and
then
we
need
to
start
talking
about
how
to
manage
aggregations
and
the
interaction
with
instruments.
So
there's
there's
a
lot
of
complexity
to
come,
and
I
think
that
there's
a
consensus
from
some
people
that
I've
talked
to
already
that
we
really
want
to
try
to
simplify
this
as
much
as
possible
without
putting
ourselves
into
a
corner.
C
I
guess
for
performance
in
the
future,
but
yeah
I
I
the
goal
here
is
to
make
sure
we
have
a
firm
understanding
and
a
developer-centric
implementation.
So
I
I
value
the
contributions
on
this
one.
Definitely
that
being
said
yeah,
I
think
this
is
going
to
be
a
good
starting
point.
I
do
think
aaron.
I
was
thinking
a
little
bit
about
the
force
flush
idea
yesterday,
which
is
going
to
relate
to
this
periodic
reader,
but
maybe
we
could
talk
about
that
after
well,
I
guess.
A
D
D
So
anytime
we
get
back.
I
will
use
to
finish
reading
this
pr.
So
certainly
that
will
be
valuable,
but
I
think
if
we've
got
all
of
us
here-
and
there
are
things
to
discuss-
let's
discuss
them.
Okay,.
C
Yeah,
okay,
so
one
of
the
things
that
aaron
and
I
have
been
talking,
there's
a
few
things.
One
of
the
things
that
aaron
and
I
have
been
talking
about
is
in
the
specification
themselves.
C
C
There's
also
some
like
issues,
I
think,
surrounding
control
flow,
which
we've
been
talking
about
for
multiple
weeks
now
so
like
it's,
I'm
not
gonna
get
too
much
of
the
details,
but
the
the
idea
is
that
essentially,
like
the
meter
provider
itself,
has
the
the
centralized
location
where
shutdown
and
force
flush
are
initiated
from
are
supposed
to
be
initiated
from
from
the
the
user
standpoint,
and
this
is
a
specification
defined
thing
and
conceptually
that's
a
little
tough,
because
on
the
other
end,
the
reader
is
the
thing
that
initiates
the
reading
of
metrics,
so
the
collection
from
the
media
provider
and
all
of
its
you
know,
tangled
web
of
where
that
telemetry
can
come
from,
and
so
it's
it's
a
little
bit
and
it's
called
out
in
the
specification.
C
It's
a
little
bit
of
a
nonsense
to
say
that
something
like
the
prometheus
exporter
or
the
prometheus
reader
would
get
a
force,
flush
signal
and
know
how
to
handle
it
right,
because
the
prometheus
exporter
or
prometheus
reader
is
the
thing
that
gets
a
signal
from
a
remote
endpoint,
and
then
it
would
have
to
respond
to
that.
So,
if
you
tell
it
in
the
meter
provider
world
to
go
and
flush,
there's
nothing
really
for
it
to
do,
because
it
can't
flush
it
anywhere.
That's
not
the
way
that
it
is
initiated.
C
It
does
make
sense
in
the
periodic
reading
sense
or
any
sort
of
reader
that
has
a
concept
of
an
exporter,
some
some
sort
of
destination
to
read
that
telemetry
into,
but
it
is
again
just
like
how
do
you
continue
that
signal?
So
our
current
implementation
here
is,
we
have
you
know
we
added
this
method
into
the
reader
interface
and
that
reader
interface
is
something
that
all
readers
need
to
be
implementing.
C
I
was
thinking
about
this
aaron,
though
I'm
not
sure
we
want
to
do
this
and
I
don't
think
they
should
block
this
pr.
I
just
want
to
make
that
clear
from
the
start,
but
I
I
think
that
what
we
could
also
do
is
create
a
separate
interface
and
I
could
write
this
down
as
well
and
that
you
know
we
can
check
if
readers
implement
that
force
flush
interface.
Some
sort
of
you
know
dynamic
assertion,
and
if
it
is,
then
we
can.
C
You
know
dynamically,
do
something
and
if
not,
then
there's
really
no
reason
to
be
flushing
it
because
it
doesn't
support
it,
and
so
I
think,
if
there's
something
like
for
the
periodic
reader,
this
is
going
to
make
a
lot
of
sense
and,
as
aaron
quoted
this
to
me,
the
other
day,
you
know
the
more
interface
expands,
the
less
it
has
meaning,
and
I'm
butchering
that
saying.
C
But
the
idea
is,
if
we
do
take
this
out,
it
becomes
a
lot
more
targeted
and
it
is
compliant
with
the
specification
in
a
much
more
one-to-one
manner,
and
I
think
that
it
would
make
sense
because
of
that's
also
more
of
a
true
go-ism
here.
But
that
was
just
one
of
the
ideas
that
I
was
thinking
about.
Another
one
that
aaron
and
I
were
kind
of
talking
about
was
you
know
again.
This
control
flow
issue
is
like
what
does
it
mean
to
you
know
before
flushing
a
reader?
C
C
I
was
thinking
about
that
a
lot,
and
I
think
that,
if
you
think
about
purely
from
like
a
information
theory
control
flow
standpoint
like
it
may
go
that
you
want
the
reader
or
maybe
even
an
exporter,
to
initiate
the
call,
but
that
doesn't
it
doesn't
really
help
because
the
end
of
the
day,
the
user
wants
a
single
place
to
call
these
sort
of
things,
both
shutdown
and
force
flush
and
maintaining
you
know
all
of
these
readers
or
any
sort
of
like
asynchronous
state
across
you
know.
C
Multiple
processes
is
probably
not
what
we
want
to
provide.
It
wouldn't
be
in
line
with
the
tracing
setup,
so
I
do
think
that
we
may
want
to
try
to
handle
these
sort
of
situations
where
you
can
have.
You
know
the
single
meter
provider
call
all
the
way
through
these
shutdowns
and
these
force
flush
options
and.
C
C
And
yeah,
I
kind
of
imagined
it
was,
and
I
I
think
that
when
we
do
the
periodic
reader
we
should
probably
make
that
change,
because
I
think
that
that
would
make
sense
at
that
point.
A
I'm
okay
with
that,
I
believe
the
manual
readers
force
flush
just
returns
nil,
so
yeah.
C
And
it
again
like
it
makes
it
like
it
doesn't
make
any
sense
that
that
had
that
there,
the
specification
says
it
doesn't
need
it
and
it
doesn't
really
do
anything.
So
why
does
it
exist
so
yeah,
I
don't
know,
that's
that's
kind
of
where
I
was
coming
to
that
like
well.
Sometimes
it
makes
a
lot
of
sense
like
when
it
knows
where
to
ship
these
metrics
but
yeah.
I
think
I
think,
that's
just
you
know
not
a
very
big
design
change,
but
I
think
a
good
go-ism
that
we
could
introduce
here.
D
I
think
we've
got
kind
of
an
analog
in
spain
processors,
spam
processors
have
a
force
flush
on
the
interface.
A
simple
span,
processor
simply
returns
nil,
because
it
doesn't
have
anything
to
flush.
A
new
error
says
yep.
I
did
what
I
could
to
flush
it,
even
though
that
was
nothing
because
it
means
nothing
to
me.
D
B
I
feel
like
we're
we're
rehashing
a
spec
debate
that
happened
six
months
ago
as
well.
The
this
very
same
objection
probably
was
made.
Probably
by
me.
I
remember
riley
was
answered
the
question
sort
of
considering
well
right
now.
The
only
example
you
have
for
a
pull
exporter
is
prometheus,
but
what
if
there
was
a
pull
exporter
that
was
pulling
periodically,
but
you
asked
to
flush
it.
It
knows
how
to
write
data,
it
can
pull
on
demand
and
force.
Flush
means
pull
on
demand.
B
He
was
imagining
a
type
of
exporter
that
doesn't
exist
in
the
open
source
world,
and
at
that
point
I
didn't
have
any
more
to
debate.
I
it
doesn't
this
never
bothered
me.
I
don't
have
much
more
to
say.
A
The
other
thing
to
consider
is
the
batching
span.
Processor
needs
a
force
flush
because
it
batches
there
isn't
a
similar
analog
in
the
metrics
world.
In
that
there
the
batches
already
happen
when
you
collect
not
not,
they
happen
asynchronously
at
the
processor
level.
C
Well,
yeah,
I
think
I
mean
I
think
it's
okay,
but
I
think
it
also
is
a
mistake
on
the
the
span
processor
interface
design,
because
it
it
seems
to
communicate
when
you
look
at
that
interface,
that
every
span
processor
is
going
to
have
a
meaningful
use
of
the
force
flush.
C
But
I
think
this
is
it
kind
of
goes
back
to
that
idea
that,
like,
if
you're
going
to
have
an
interface
and
it's
going
to
have
some
sort
of
meaning
to
it,
like,
I
think,
if
there's
a
you
know
a
use
into
trying
to
trim
that
down
to
like
having
a
useful
meaning
for
every
single
operation,
and
if
you
wanted
to,
you
know,
extend
that
you
can
do
that
by
extending
it
and
asserting
that
it
implements
another
interface,
which
is
which
is
useful
at
configuration
time
like
we're
going
to
know
at
the
configuration
time
whether
to
be
calling
a
function
or
not.
C
Instead
of
calling
the
function,
you
know
right
at
the
you
know
the
critical
point
for
a
function
as
a
service.
You
know
call
where
they're
trying
to
actually
flush
bands
like
you're,
not
wasting
any
time
on
some
sort
of
you
know,
function,
lookup
and
then
function
call
and
they
get
a
nil
operator
back
we're
just
going
to
skip
that
entirely
because
we
configured
it
to
skip
it
entirely
from
the
start.
C
I
guess
that's
you
know
we're
talking
microsecond,
maybe,
but
maybe
that's
not
a
big
deal,
but
I
I
don't
know
I
it
just
seems
like
there's
a
possibility
there.
It
also
isn't
like
the
end
of
the
world.
C
I
was
just
looking
at
it
because
I
do
notice
that
like
if
we
keep
this
here,
it
might
be
worth
creating
a
spec
issue
for
it,
because
it's
not
defined
in
the
spec
and
the
spec's
pretty
ambiguous
about
how
forced
flushes
are
supposed
to
take
place.
I
think
that
josh
and
riley
have
a
lot
of
context
because
there's
a
lot
of
conversation
that
happened
but
like
if
you
read
the
spec
directly,
like
I
think,
there's
missing
concepts
that
were
included
there.
A
Yeah
I
was
gonna
bring
up
real
quick
force.
Flush
is
in
the
span,
processor
interface
definition
at
the
spec
level.
A
It's
not
at
the
metric
reader
interface
definition
at
the
spec,
so
it
seems
to
be
an
omission
at
most
at
the
spec
level,
because
there
is
definitely
verbiage
about
how
the
meter
provider,
when
it
receives
a
force
flush
needs
to
call
force
flush
on
all
of
its
readers
and
exporters.
But
how
does
it
do
that?
If
it's
not
necessarily
yeah
so.
C
Okay,
yeah,
I
don't
have
extremely
strong
opinions.
I
think
it
provides
us
a
little
bit
more
wiggle
room,
but
it's
not
again
like.
I
don't
think
it's
the
end
of
the
world
cool.
I
think
that
was
kind
of
go
ahead.
Can.
C
Yeah,
okay,
that's
kind
of
where
I
was
going
next.
I
was
thinking
of
maybe
picking
up
that
issue.
So
I'll
put
these
notes
down
there
as
well,
so
yeah
I'll.
Take
that
but
yeah
we
just
need
to
that
one's.
I
think,
blocked
as
well
until
we
get
this
pr
merge.
So
let
me
actually
assign
this
to
myself.
So
don't
forget
that
and
then
yeah
perfect
josh.
You
still
have
your
hand
up.
C
I
don't
remember
if
that's
from
before
sorry,
okay,
one
of
the
things
josh,
I
don't
know
if
you
I.
I
also
know
that
we
kind
of
talked
asynchronously,
like
you
were
kind
of
stepping
away
from
a
little
bit
of
the
sdk
development
into
some
other
parts
of
open
telemetry
are,
I
hope
I
said
the
right
word.
I
think
I
don't
know,
but.
B
I
can
just
say
it
myself.
I
feel
that
I
produced
a
pretty
like
for
me
that
was
useful
to
produce
a
complete
prototype
of
of
views
implementation.
I
certainly
bring
with
it
my
own
performance
background,
like
feeling
for
where
things
should
be
optimized
not-
and
I
think
maybe
there's
some
disagreement
about
those
things,
but
you
know
I
don't
feel
like
I'm
helping
you
anymore.
B
I
think
it
was
useful
for
me
as
one
of
the
specs
primary
authors
to
have
worked
through
it,
and
I
I
I've
just
been
through
so
many
of
these
little
debates
about
like
what's
a
reader,
what's
an
explorer
that
I'm
sort
of
feeling
beyond
that
as
well.
I
don't.
I
don't
see
that
I
don't.
I
don't
think
it's
too
too
much
worth
debating
whether
there's
a
full
force
flush
api.
That
means
nothing
or
whether
it's
missing
and
you
dynamically
check
for
it
like
who
cares?
B
I
don't
know,
that's
just
me,
I'm
I
came
to
the
meeting
since
I
had
no
other
conflicts
and
I
want
to
participate.
I
was
looking
at
the
pr
that
aaron
had
flashed
on
I'm
enjoying
that
five
minutes
into
the
hour
and
I
have
feelings,
but
I
I
also
I
don't
know.
I
think
the
these
issues
deserve
to
be
done
in
a
group
and
and
taking
one
person's
draft
is
certainly
not
the
way
to
go.
So
I
I
mean
I
was.
B
C
Yeah,
so,
first
of
all,
thanks
for
all
the
work
on
the
draft
proposal,
I
think
that
was
very
useful
to
have
a
conceptual
end-to-end
standpoint.
So
I
definitely
don't
want
to
downplay
that.
I
think
one
of
the
things
I
did
want
to
ask
was
if,
if
that's
the
case-
and
you
don't
want
to-
I
think
participate,
can
you
maybe
just
mention
that
in
the
280
open
pr
just
so
that
65.
C
C
Design
comments,
yeah
yeah
no
worries.
I
I
went.
B
Back
to
I
see
acic,
I
came
back
to
that
issue
on
monday
morning
and
realized
that
I
don't
care
enough
to
have
a
debate
over
it.
So
if
we
are
debating
the
privacy
of
the
register
and
produce
methods,
I
it's
not
worth
it's
not
worth
it
to
me.
Let's,
let's
move
on,
if
that's
the
one
yeah.
B
No,
I
don't.
I
don't
want
to
talk
about
it
anymore.
I'm
sorry!
I
didn't
come
back
to
that.
You're
right.
I
left
it.
Looking
like
I
wanted
to,
and
I
totally
decided
I
don't
care
to
argue.
So
let
me
okay,
let
me
know
if
I
haven't
resolved
them
all
but
yeah.
Let's
look
at
this,
the
the
one
in
front
of
us.
B
You
know
the
the
initial
reaction
I
had
is
that
there's
you
know
I
I
mean
I
guess
the
pitch
I
took
there
here
had
had
more
than
one
interface,
where
you
see
one
in
front
of
you,
this
view
of
you
having
a
match
function
for
descriptor
that
that
work
checks
out
for
me
and
that
having
a
produce
method
that
also
checks
out
for
me,
but
having
an
update
method,
sounds
like
a
long
code
path.
B
The
way
it
looks
right
there
and
I
had
created
an
instrument
object
which
is
like
the
result
of
that
match
is
really
compiling
a
thing
that
you
could
then
update,
and
so
that's
just
my
first
reaction
was
like
this
looks
like
a
longer
code
path.
I
could
see
it
happening,
but
there's
a
I'm
not
sure,
I'm
not
sure
how
descriptors
are
being
used
in
the
update
method.
When
I
came
to
it.
C
Yeah
and
aaron,
maybe
you
could
talk
a
little
about
the
distinction
between
the
instrument
and
the
data
stream.
I
haven't
read
all
this
at
this
context
here
yet
sorry,
I
just
looked
at
the
code.
A
So
the
key
the
key
there
is
there
is
a
distinction
between.
A
What
is
considered
matching
for
view
in
the,
in
the
view,
description,
it's
pieces
of
information
like
instrument,
name
and
description
and
the
meter
that
that
is
providing
it
and
what
is
actually
eventually
recorded
at
a
record
at
a
at
the
endpoint
of
a
data
data.
Point
right,
which
data
stream
descriptor
would
encompass
the
instrument,
because
that
that
is
part
of
where
what
is
what
makes
it
unique.
A
But
it
would
have
also
any
additional
attributes
that
were
added
at
the
call
point
at
the
like,
add
or
observe.
B
Point
I
misread
it,
so
I
didn't
see.
Data
stream
was
a
new
package
and
I
haven't
seen
that
package
yet.
A
I
did
not,
I
did
not
actually
create
a
data
stream
descriptor,
but
I
I
just
something
that
differentiates
the
instrument,
how
you
describe
an
instrument
from
a
data
stream
and
the
idea
is
you
you
match
based
on
a
view
whether
or
not
you
should
be
updating
this
view,
based
on
the
rules
for
matching
that
are
described
by
the
spec
right
and
then
you
update
anything
that
you
match.
So
the
idea
would
be
when
you're
creating
an
instrument.
A
You
query
the
sdk
and
say
hey
what
views
do
I
match
and
it
can
go
to
each
view
because
it
knows
it.
The
sdk
knows
about
all
of
the
views
and
say
does:
does
this
match
this?
Does
this
match
this?
Does
this
match
this
and
if
yes
record
it
in
there
and
if
not.
A
Ignore,
like
don't
don't
put
it
in
your
record
path
essentially
and
then,
when
you
call
an
ad
or
an
update
or
add,
observe
record
any
of
those
methods.
Eventually,
it
will
drill
down
and
build
this
data
stream
descriptor
that
calls
update
and
that's
where
the
accumulation
actually
gets.
The
the
new
update
from.
A
And
the
idea
there
is
to
be
able
to
just
decouple
within
this
package
the
accepting
of
data
and
the
actual
recording
of
data.
So
I
know
at
some
point
we
talked
about
how
there
are
different
ways
that
this
might
be
built.
I
think
that's
what
is
necessary.
I
I'm
not
I'm
not
100
sure
and
I
can
be
convinced
of
another
thing,
but
I
needed
somewhere
to
start
off
and
and
you'll.
A
I
editorially
I
have
written
this
as
if
this
were
how
it
should
be
made,
but
that
is
just
so
that
I'm
not
always
writing
a
passive
voice
and
sounding
unsure.
A
B
So,
just
for
everyone
else,
who's
listening
the
way
I
had
phrased
this
there
there
was
a
you
know.
You
would
you'd
create
a
view
compiler
that
knows
of
all
the
views
and
then
the
the
first
interaction
you'd
have
with
this
view.
Compiler
is
to
present
it
a
descriptor
and
say
compile
it
returns
an
instrument,
and
then
the
instrument
can
be
cached
in
the
api
level
instrument,
so
that
the
so
you
never
really
need
to
use
a
descriptor
again.
B
Moreover,
the
descriptor
that
you
would
be
using
is
only
a
key
because
it's
the
api
level
descriptor
and
the
views
can
modify
the
descriptor.
So
that's
not
the
api,
it's
not
the
script
you're
going
to
be
using
for
the
output,
so
it
begins
to
sort
of
just
look
like
a
map
key
and
then,
rather
than
having
a
map.
Key
I'd
rather
just
have
an
interface
which
is
in
my
branch,
it's
called
interface.
Sorry,
it's
called
instrument.
So
then
the
instrument
interface
has
this
new
accumulator
method.
B
I
think
the
word
accumulator
has
thrown
people
off
and
I
do
agree,
there's
different
ways
to
do
this,
and
we've
talked
a
lot
about
how
there's
different
directions
of
data
flowing.
So
whether
the
accumulator
word
is
throwing
us
off
still
or
the
name
is
bad.
The
the
still
the
idea
is
that
there's
another
level.
So
first
you
compile
the
instrument,
you
compile
the
view.
You
then
have
an
instrument,
you
you
give
it
some
key
values.
You
now
have
an
accumulator
which
you
can
update
multiple
times.
B
It
means
that
the
the
view
is
compiled
once
and
at
that
point
you
have
an
instrument
rather
than
a
descriptor,
and
I
think
you
can
probably
achieve
the
same
by
looking
up
the
descriptor,
but
I
also
see
that
I
don't
haven't
seen
your
just
data
screen
descriptor
type
and
it
might
actually
just
be
the
same
thing.
I'm
saying,
which
is
an
interface
that
supports
update,
so
that.
A
I
would
really
expect
that
the
descriptor
would
be
a
container
that
has
both
the
meter
and
the
instrument.
That's
like
the
the
information
for
the
meter
and
the
instrument
so
that
we
can
get
the
aggregations,
so
we
could
just
build
into
that.
I
don't
know
if
that's
the
appropriate
way
of
looking
at
it.
B
Yeah,
I
I
just
I
see
a
loss
of
optimization
in
this.
These
interfaces,
like
there's,
there's
a
compile
station.
That
gives
you
a
thing
that
you
can
then
find
accumulators
based
on
your
attributes,
and
this
looks
like
forcing
you
to
do
to
do
more
lookups.
I
don't
know
I
I'm
I'm
trying
part
of
the
reason
I'm
stepping
back
here
is
that
I
don't
feel
like
it's.
I
don't
really
want
to
argue
to
that.
B
My
way
of
doing
things
is
necessarily
right
versus
wrong,
but
I
do
see
worrying
signs
that
that
what
might
get
built
here
is
not
going
to
have
the
same,
maybe
performance
that
I
started
with
assumptions
about
so
yeah.
I
mean
I
I
consider
the
like.
If
we're
now
talking
about
the
internals
of
the
implementation,
I'd
like
to
see
a
reason
why
we
shouldn't
just
take
what
I've
done
at
least
I'd
like
to
see
that
that
was
looked
at
since
it.
B
You
know
I,
I
wrote
100
test
coverage
in
my
viewstate
package,
so
the
compiler
has
thorough
testing.
The
accumulator
interfaces
are
carried
out
with
all
the
different
temporality
configurations,
and
the
thing
that
I
was
left
with
and
and
and
still
want
to
do
is
to
try
and
tighten
up
some
of
the
specs
around
conflict
resolution,
because
the
major
part
of
handling
what
I,
I
think,
there's
still
some
disagreement
among
the
sigs
about
how
to
handle
these
these
conflicts.
B
But
if
you
do
have
conflicts,
then
I
believe
the
prescribed
behavior
is
to
output
more
than
one
thing
with
essentially
conflicting
descriptors,
and
I
and
I'm
I'm
wondering
how
that
would
work
and
what
I'm
seeing
here,
whereas
I
know
how
it
worked
in
the
the
design
I
gave,
and
it
does
have
you
know
and
essentially
interfaces
that
that
the
api
level
interacts
with,
and
it
has
interfaces
that
the
collection
path
interacts
with
and
they
are
they
are
it's
a
little.
B
B
C
I
I
really
like
this
for
the
simplicity
that
it
shows
the
interaction
and
I
I'll
be
honest.
I
don't
think
I
fully
understand
josh's
implementation
currently,
but
I
I
I
really
like
how
I
just
can
read
this
this
view
interface
and
I
just
know
how
it's
going
to
be.
B
Used
but
isn't
the
view
different
than
an
instrument?
That's
that's
the
thing,
I'm
I'm
confused
by
like
that's
why
the
the
two
behaviors
are
mixed
into
one
interface
here.
C
B
C
B
Josh,
well
I
I
would.
I
would
suppose
that
when
you
create
an
instrument,
you
you
check
every
view.
Do
you
match
and
you're
getting
back
this
boolean?
So
then,
I
suppose
what
aaron
described
is
that
you
now
restore
each
instrument
will
store
a
list
of
views
that
it
matches,
but
every
reader
has
a
different
behavior
for
those
views.
So
the
complexity
that
I
ended
up
with
is
that
like
well.
C
Mean
that's
kind
of
how
I
saw
it
too,
like
the
upper
like
these
two
methods,
the
update
in
the
match
are
called
by
the
instrument
right,
the
instrument's
saying.
Like
do
I
match
you,
because
if
I
do,
I'm
gonna
update
you
and
then
the
the
reader
goes:
okay,
cool,
like
you're!
Managing
all
of
this
all
these
updates
so
tell
me
what
the
produced
metrics
are
at
this
timestamp
that
I'm
calling
you
at.
D
D
Match
is
called
by
the
meter
to
identify,
what's
the
set
of
views
that
this
instrument
that
I'm
creating
now
needs
to
know
about
what
what
v,
what
what
instruments
could
actually
produce
to
this
this
view
and
then
update
is
called
when
you
actually
record
a
value
on
an
instrument
to
say.
Okay,
I've
got
a
little
bit
of
an
additional
information.
Now
I
have
some
extra
attributes
that
may
change
whether
you
match
or
not,
please,
if
that
that's
valid,
for
you.
A
The
matching.
My
at
least
my
reading
of
the
matching
parameters
of
the
of
whatchamacallit.
Of
the
the
view.
Spec
is
it's
instrument
name,
it's
instrument,
description.
It's
the
meter
name,
there's
a
couple
other
things
on
meter,
but
you
filter,
you
can
add
or
remove
attributes
you
cannot.
You
don't
match
on
attributes.
A
C
So
essentially,
what
I'm
hearing
is
that
the
match
is
called
by
the
meter
and
it
maintains
a
state
of
all
the
things
that
for
any
instrument
it
creates.
It
knows
like
okay,
since
I
know
that
when
I
created
this
this
match
with
this
view,
I
need
to
send
this
update
to
this
view
and
it
it
maps
those
two
right.
The
the
instrument
keeps
that,
though,.
A
Yeah,
that
was
my
intent
with
this
design.
The
first
pass
I
had
with
it
just
had
update,
but
you
have
to
then
do
the
match
logic.
Every
single
update
right.
B
So,
but
it
feels
like
to
me
even
passing
is
some
sort
of
descriptor,
unless
that,
like
you,
want
to
have
a
the,
the
idea
is
that
you
can
do
some
work
once
and
then
put
that
into
the
instrument,
and
you
should
be
able
to
call
update
very
cheaply.
At
that
point,
I
think,
and
I'm
worried
that
you're
going
to
be
looking
up
by
some
sort
of
descriptor
the
thing
that
you
want
to
update,
whereas
you
should
actually
just
be
able
to
have
it,
because
you
did
that
compile
stuff.
A
B
Descriptor
doesn't
change
so
so
I
don't
understand
the
descriptor.
Well,
there's
a
data
stream,
descriptor
type,
I'm
not
sure
what
you're
talking
about
there,
but.
A
B
Just
be
the
attribute
set,
that's
that's
what
I
was
trying
to
say
and
then
by
creating
another
interface,
that's
returned
by
compile
rather
than
saying
match,
and
then
you
know
passing
some
view.
Just
some
descriptor
back
through
you're,
just
gonna
have
to
look
up
something
that
you
could
have
returned
in
the
first
place.
D
Yeah,
I
think,
if
that
last
step
is,
is
really
just
the
same
as
the
record
or
add
on
the
instrument,
then
the
view
can
be
returned.
The
compiled
view
can
be
returned
as
the
instrument
instead,
and
so,
when
you
record
or
add
on
that
instrument
you're
effectively
passing
through
you
know,
the
instrument
would
get
the
recorder.
Then
it
would
call
update
on
its
view.
A
So,
in
that
case,
would
would
you
assume
that
match
would
provide
a
provide,
probably
a
new
type
that
has
the
update,
which
is
or
a
new
a
new
interface
that
potentially
has
the
update
essentially
or
maybe
a
function
or
whatnot
that
accepts
the
attribute
set
yeah.
That's
what
we're
hearing.
C
Yeah,
I
think,
if
that's
a
yes,
I
agree.
B
A
B
Y'all
think
the
the
act
so
so
one
thing
I
believe-
and
I
think
we
can
experimentally
show-
is
that
the
major
cost
of
most
metrics
apis.
The
way
they're
used
is
constructing
this
attribute
set
from
the
key
value
array
and
we've
our
code
path's
pretty
optimized
there,
but
it's
still
not
cheap.
So
you
so
at
the
moment
of
a
metric
api
call.
You
have
some
attributes
and
you
have
some
value
and
we
think
that
most
of
the
cost
is
usually
like
finding
a
map
key
from
your
attribute
set.
B
Now,
if
each
reader
has
a
variable
set
of
keys
that
they're
that
they're
aggregating
by
that
means,
different
readers
are
going
to
to
remove
different
keys
and
therefore,
as
aaron
is
saying,
there's
something
that
can
change
when
you
change
your
attribute
set
and
that
that
may
be
something
you
call
data
source
now
in
my
branch,
the
way
I
handled
this
was
built
on
an
assumption.
The
assumption
is
that
the
cost
of
additional
filtering,
which
means
to
compute
the
output
on
every
api
event
is,
is
an
unnecessary
cost.
B
So
so,
if
I'm
going
to
do
some
filtering,
I
will
do
that
in
the
collection
step
rather
than
in
the
api
update
step,
and
it
means
that
I'm
going
to
take
my
full
attribute
set
and
pass
it
into
the
update
method.
Roughly
speaking
and
then
when
I
do
collect,
I
will
look
up
the
output
stream
from
the
input
stream
attributes
and
pay
the
cost
of
filtering
that
once
per
collection,
rather
than
once
per
api
event.
B
I
think
that
leads
to
kind
of
an
argument
again
in
favor
of
returning
some
interface
that
I
can
use
rather
than
because,
when
I
read
the
pseudo
code
that
I
saw
in
that
issue,
the
update
method,
taking
a
data
stream
descriptor,
what
you
could
do,
the
filtering
on
every
api
call
and
then
the
data
stream
descriptor
would
be
the
calculated
output
stream,
but
now
you're
paying
to
calculate
the
output
stream
for
every
api
event.
Rather
than
for
every
collection.
C
So
but
okay,
josh
I'll,
be
honest.
I
don't
know
if
I
completely
followed
the
optimization,
it
seems
nuanced,
but
if
this
is
replaced
with
just
an
app
or
so
so
if
match
is
updated
to
return
some
sort
of
compiled
view
or
some
yeah
updater
or
something
like
that
and
the
updater
takes
an
attribute
set.
Does
that
address
the
issue
that
you're
talking
about
or
is
there
still
something?
That's
I
see
your
head
dotting,
but
let's
just
talk:
you're,
muted,.
B
C
Yep
cool-
I
I
really
like
this
and
I'll
be
honest.
It's
for
selfish
reason,
because
I
get
it
and
I'm
kind
of
dumb
so.
B
You
know
like
this
is
nice.
I
so
don't
want
to
be
in
a
position
of
being
like
the
guy
who
created
the
thing
that
nobody
understands
so
like
I'd.
Rather
have
you
guys
debate
this
and
step
back
than
then
just
push
it
on
you,
but
I
can
definitely
keep
coming
to
these
talks
and
aaron
can
ping
me
if
there's
a
review
that
needs
my
input.
I
I
did
come
away
from
all
this
exercise.
B
Thinking
a
couple
things
ought
to
be
written
down
in
the
spec
that
might
be
disagreed
upon
by
the
different
cigs
in
terms
of
various
things,
so
it
was
useful,
and
I
hope
that
you
know
that
we
get
this
done
one
way
or
another.
C
Yeah
one
thing
josh
I
do
want
to
point
out
is
the
resolution
of
how
conflict
should
be
handled.
I
think,
is
extremely
important,
so
I
I
definitely
think
if
that's
something
that
I
would
value
having
an
answer
on,
so
I
appreciate
you
taking
the
charge
there.
B
Yeah,
I
will,
I
think,
there's
a
few
more
things
that
need
to
be
said,
but
it's
not
very.
It's
obviously
not
clear
the
other
sticks,
so
I
will
have
any
more
yeah.
C
Well,
cool,
I
I
feel,
like
my
knowledge
bucket,
is
quite
full
at
this
point,
so
I
don't
know
if
we
want
to
dive
into
too
much
of
this
stuff,
I
can
double
check.
Doesn't
look
like
anything
else.
Is
added
to
the
agenda.
C
I'm
going
to
pause
on
the
topics.
I
think
that
we
we
should
continue
this
conversation.
I
know
aaron's
already
got
a
task
to
try
to
revamp
that
that
interface
and
I've
got
a
few
others,
so
I'm
gonna.
A
Quickly,
add
something
from
just
the
talk
that
we
have
take
a
look
and
see
if
that.
C
No
worries
yeah,
I
went
to
talked
by
kelsey
hightower
winston
he's
scrolling
up
and
hitting
enter
20
times
and
everyone's
just
like.
I
don't
understand
why
you
don't
use
the
the
retract
command
or
something
like
that.
It
goes
well.
Otherwise,
it
looks
like
I'm
doing
absolutely
nothing.
So
I
think
that
I
need
some
way
to
just
yeah
I'll
hit
refresh
a
few
times,
but
I'm
guessing
aaron
what
you're
doing
is
you're
just
trying
to
capture
what
we
were
just
talking
about
in
the
yeah.
C
Okay,
updater,
okay,
cool
cool.
This
looks
good.
I
think
this
is
more
in
line
with
what
we
were
talking
about
in
my
understanding.
Does
this
don't
look
good
josh
and
anthony
yeah,
okay,
cool
yeah?
I
think
I'd
like
to
read
this
poll
thing
before
and
I'll
give
you
a
comment,
but
I
think
this
is
cool.
We
have,
I
think
something
forward.
C
I
would
like
to
try
to
get
some
thing
merged
in
soon,
maybe
next
week
so
yeah,
I
think
the
faster
we
can
get
to
letting
people
review
that
other
better
and
then
yeah.
We
can
go
from
there,
but
before
we
go,
I
do
want
to
ask
if
anybody
has
some
cool
use
cases
of
open
split
tree?
I
know
a
former
colleague
is
trying
to
do
a
lot
with
the
open
tracing
bridge
and
getting
a
lot
of
back
channel
discussions
on
that.
D
Yeah,
I
saw
those
comments
and
and
pr's
for
that.
I'm
intrigued.
C
As
to
what's
going
on
there
always
interesting,
I
it's
just
somebody
who
has
a
large
code
base
that
isn't
already
interested
within
open
tracing
and
the
migration
path.
It's
definitely
raising
the
question
in
my
mind
that
we,
I
think
we
have
a
migration
path,
there's
still
a
few
issues
that
I've
that
we
already
have
identified,
that
we
don't
have
resolved,
but
I
think
we
could
do
a
better
job,
communicating
how
to
how
to
migrate
from
open
tracing
to
open
telemetry
and
honestly,
we
haven't
documented
it
as
an
issue,
but
it's
it's.
C
I
think
valued
time
spent
because
there's
already
a
lot
of
use
of
open
tracing
and
if
we
can
provide
a
very
clear-cut,
distinct
path
forward,
using
our
bridge
or
just
replacing
statements.
I
think
there's
some
some
value
there
to
help
the
adoption
of
insulin
tree
so
yeah.
D
C
Yeah
one
of
the
cool
things
I
was
thinking
about
this
morning
was
like
two
or
three
weeks
ago.
We
saw
an
example
of
auto
instrumenting
source
code
through
the
injection
or
just
running
some
sort
of
generator
on
it
right
like
I.
Maybe
we
could
do
something
there
where
you're
you're
looking
through
and
anytime.
You
see
some
sort
of
open,
telemetry
function,
call
or
construction.
We
know
the
equivalence
and
open
telemetry,
so
we
could
try
to
to
build
something
like
that.
C
C
Well
awesome.
I
think,
then
we
could
probably
end
the
meeting
here
and
get
back
to
reviewing
things.
I
really
appreciate
everyone
jumping
in
and
listening
to
this,
and
I
don't
know
it's
the
most
useful,
but
I
appreciate
the
contributions
and
otherwise
we'll
see
you
same
place
same
time
next
week
or
a
secret
bye.
Everyone.