►
From YouTube: 2022-06-09 meeting
Description
Instrumentation: Messaging
A
B
Are
the
erlang
say
he
hasn't
seen
as
much
attendance
in
a
long
time.
B
Yeah,
I
also
kind
of
feel
that
this
is
going
to
go
pretty
quick
just
because
we're
doing
a
pretty
good
job,
keeping
things
flowing
in
asynchronous
conversations,
so
yeah
give
it
30
more
seconds.
B
Okay
or
wait,
which.
A
Scroll
down
just
a
little
bit
there,
I
guess
two
weeks
ago,
yeah,
that's
that's
the
same
meeting
as
this
one.
Okay,.
B
A
That
seems
like
chasing
an
ever
ever
moving
target.
It
seems.
B
I
know
right
yeah,
okay.
Well,
I
think
I
think
I'll
clean
this
up
later
on,
but
yeah
we
can
just
jump
into
it,
not
too
much
on
the
agenda
right
now,
damian
or
josh.
If
you
have
anything,
please
be
sure
to
add
yourself,
add
anything
agenda
wise
to
the
topics
and
add
yourself
to
the
entities
list.
We
can
jump
in
just
kind
of
a
heads
up
on
progress
in
the
metric
sdk.
B
B
So
speaking
of
that
here's
the
project
board,
I
was
just
going
through
this,
and
so
there's
david.
I
hope
he
wasn't
in
the
wrong
room.
C
Cool
so
dude
were
you
in
the
wrong
room
by
chance?
No,
no,
I
was
I
was
at
sig
instrumentation
talk
with
bjorn
and
co
about
exponential
histograms,
okay,.
B
Okay,
cool
so
jumping
into
it.
The
in
progress
columns,
heating
up,
definitely
got
a
pr
that
I
don't
see
here.
I
guess
it's
not
tagged
appropriately,
but
apparently.
D
B
B
That's
my
question
to
you:
I
think
we
can
probably
close
this.
This
has
a
lot
more
stuff
from
the
demo
that
we
had
it
kind
of
included
here,
but
I
feel
like
this
is
probably
good
enough
to
close,
but
I
wanted
to
ask
you,
I
guess
was
my
concern.
A
B
B
The
width
aggregation
you're
right-
yes,
sorry
this
is
in
is
it,
though,.
B
B
Views
you
sorry
here
we
go
yeah
yeah,
so
the
aggregation
is
an
optional
configure,
okay
configuration!
So
that's
a
good
thing,
because
that'll
probably
frame
our
next
discussion.
But
yes,
so
that
was
my
idea.
Was
that
to
have
some
sort
of,
I
guess
we're
saying
like
with
set
aggregation
option
as
well.
Yeah.
A
B
Honestly,
we
can.
I
could
split
that
off
from
this
issue
and
then
I'll
just
close
this
issue.
Okay,
then
I
will
take
that
as
an
action
item
to
address
that
after
the
meeting
okay
cool,
so
that
should
be
done,
and
this
is
still
actively
kind
of
being
worked
on
in
that
same
vein,
temporality
option
instrument
kinds.
Yes,
I
think
everything
else.
Oh
this
view
state.
Is
this
something
you're
still
working
on
aaron
or
should
I
just
take
this
off
your
plate?.
A
Honestly,
I
think
at
this
point
it's
going
to
be
subsumed
by
whatever
our
aggregations
end
up
being
that's
where
the
different
logic
of
the
view
state
ends
up
living.
B
Yeah,
I
think
you're
right
I've
been
digging
into
this
a
little
bit.
That's
an
understatement,
a
lot
and
playing
around
with
like
three
different
models
already
looking
at
josh's
old
pr.
Looking
at
our
original
example,
there's
a
lot
a
lot
of
moving
pieces
going
on
there,
so
I
think
you're
right.
How
do
you
want
to
identify
this
in
the
project
board?
Should
we
close
this
or
why
don't
we.
A
A
Is
that
and
so,
or
or
actually.
B
B
I
think
that
might
be
a
better
idea.
Maybe
we
do
that
because
I
still
want
something
tracking
that
work.
I
guess
so
so
maybe
we
try
to
do
that.
If
that
makes
sense,
okay,
then
I
will
leave
that
as
an
action
item
for
you,
aaron,
okay,
cool.
Okay,
do
you
need
some
okay,
one
of
the
other
things
that
I
was
looking
at
in
that
defaults?
B
Okay,
that's
probably
gonna
be
and
kind
of
sussing
out
this
aggregation.
One
of
the
things
I
was
looking
at
is
just
like
working
there's,
essentially
like
two
chains
here
going
right
like
there's
the
the
export
side
of
things
and
then
there's
the
instrument
side
of
things
and
like
they
kind
of
they
meet
in
the
middle
right
and
so
how
they
meet
in
the
middle.
I
think
we're
kind
of
working
backwards
for
both
of
them
and
I'm
as
I'm
getting
toward
more
towards
the
aggregation
side.
B
I'm
looking
a
lot
at
the
java
implementation
as
well,
which
is
confusing
at
first,
but
I
think
it's
a
good
conceptual
understanding.
In
addition
to
those
other
references
I
just
mentioned
earlier,
and
so
one
of
the
things
I'm
thinking
is
just
kind
of
working
all
the
way
out
to
building
these
stubbed
instruments,
so
the
async
and
the
sync
instruments
and
then
having
them
essentially
store
to
some
abstract
interface.
That
is,
you
know
especially
expected
to
be
defined
later
on
something
like
a
writable
storage.
B
I
think
java
calls
it
like
an
immutable,
writable
or
immutable
storage
or
something
I
don't
know
but
like
having
some
sort
of
storage
interface
and
then
that
interface
can,
you
know,
evolve
afterwards.
So
essentially
you
say,
like
you
know,
you
can
build
out
all
the
way
to
the
instrument
and
the
instrument
just
says
like
add
a
record
or
something
like
that,
and
then
that'll
then
we'll
build
from
there.
It's
kind
of
my
idea
so
really
think
about
it.
Go
ahead.
The.
A
Way
I
was
planning
on
doing
it
is
the
aggregation
would
be
an
interface
that
has
update
and
a
retrieve
and
the
update
is
the
instrument's
view
of
writing
a
new
number
into
that
aggregation.
So
a
counter
would
update
like
one
every
time,
but
the
the
retrieve
whatever
we
call
the
retrieve
path,
would
not
would
do
whatever
necessary
calculations
to
do
the
aggregation
to
to
combine
the
different
updates
and
put
it
out
in
the
the
format
that
it
expects
it.
B
Yeah,
so
yes,
I
think
that
I
was
looking
at
a
very
similar
approach.
Java
does
it?
Similarly,
instead
of
calling
out
an
aggregation,
they
call
it
an
accumulation
which
I
think
is
about
something
we
used
to
have,
but
what
they
do
is
they
have
an
accumulation
that
has
essentially
like
an
update
or
like
a
record
method,
and
then
they
have
a
retrieve
method
as
well,
but
then,
on
top
of
that
they
have
an
aggregator
which
is
funny
because
it's
a
reserved
word,
but
it's
an
internal
package.
B
So
they
have
an
aggregator
that
essentially
takes
these
accumulations
and
that's
the
thing
that
kind
of
handles
the
temporality
selection
right.
So
if
they
know
that
you
know
that
instrument
is
accumulative,
it
knows
how
to
combine
the
two
aggregations
or
the
accumulations
and
then,
if
it's
delta,
it
obviously
knows
how
to
handle
the
the
accumulation.
B
But
I
think
that
that's
where,
like
the
status
order,
is
at
the
end
like
this
aggregator
level,
so
I'm
still
kind
of
like
looking
through
like
separation
of
duties
there,
because
I
think
that
the
more
we
can
define
that
separation
of
video
it.
It
helps
under
understanding
of
the
code,
but
I
also
think
it
helps
us
in
you
know.
One
things
we've
looked
at
in
the
past
is
concurrency
through
this
pipeline.
It
also
helps
us
in,
and
I
don't
know,
there's
a
lot
of
things.
B
I
think
it
helps
us
in,
but
I've
been
doing
a
lot
of
example,
research
and
you're,
trying
to
like
figure
this
out
and,
like
I
said
like
looking
at
a
lot
of
different
code
as
well
as
the
specification.
I
guess
I
didn't
mention
that,
but
that's
important
as
well
and
so
yeah.
B
I
would
like
to
keep
going
in
that
I'm
trying
to
put
together
some
sort
of,
I
think,
high
level
design
that
we
should
try
to
like
shoot
for
maybe
some
naming
structure
and
then
maybe
we
can
talk
about
that
before
a
pr.
I
guess,
because
I
think
that's.
The
key
is
like
I'd
rather
not
have
like
a
pr
go
out
and
just
not
really
hit
the
mark.
So
I
want
to
make
sure
that
we're
all
in
agreement
on
that.
B
Okay,
yeah
and-
and
I'm
like
likewise
the
other
way
around
I'd
love
to
hear
it.
If
you
have
like
a
design
doc
or
something
like
that,
aaron
as
well,
that
you
were
thinking
about
mine
is
literally
on
pen
and
paper
right
now,
and
so
it's
not
really
well
formed,
but
yeah.
I
think
there's
something
I've.
A
The
idea
here
is:
we
have
meters
meters
create
instruments,
instruments.
Any
black
line
is
a
creation
event.
So
when
you
do
like
an
async
counter
that
creates
an
instrument,
that
instrument
will
also
create
the
aggregations
based
on
the
views
that
are
attached
by
a
reader
right,
so
there'll
be
an
aggregation
of
you
know,
sums
or,
if
they're
changed
in
any
way,
but
that's
per
reader
and
then
blue
is
the
update
path.
So
users
have
references
to
instruments,
instruments
have
references
to
the
aggregations
that
were
created.
A
I
don't
know
if
this
is
too
readable
here
and
it
will
go
and
update
each
aggregation
that
is
attached
to
that
instrument
and
then,
similarly,
the
read
path
is
from
the
reader,
so
the
reader
is
the
source
of
the
read
it's.
It
queries
every
meter,
every
scope,
essentially
which
should
have
the
group
of
readers
or
the
group
of
aggregations
that
are
in
that
reader
and
it
just
does
the
retrieve
from
each
aggregation.
A
That's
combined
at
the
scope
level,
I've
been
working.
B
A
How
does
that
update
path
know
which
group
of
readers
to
update
it
just
knows
every
aggregation
that
was
attached
to
that
instrument,
so
the
instrument
will
keep
a
list
of
aggregations
that
were
created
right
creation
time.
I
see.
B
Yeah,
so
I
guess
that
that's
the
this
looks
pretty
similar
to
what
I
was
thinking.
It's
just
that
that
aggregation
block
like
how
do
you
expand
that
right,
because
there's
there's
a
there's,
an
update
path
to
the
aggregation,
but
there's
also
a
cycling
path
from
the
the
reader
right
that
goes
through
the
meter
and
pulls
from
it,
and
so
I
guess
that's
like
how
do
you
maintain
state?
B
A
B
If
you're,
using
just
like
a
sum,
how
do
you
understand
or
somewhere,
like
the
last
value?
How
do
you
understand
resets
right
so
does
the
aggregation
understand
like
the
conceptual
idea
of
like
a
cumulative,
or
does
it
like
understand
just
only
like
a
delta
and
if
it
doesn't
understand
the
cumulative
word
meters
come
from.
A
So
there
would
be
a
cumulative
sum
there
would
be
a
delta
sum
there
would
be.
Actually
there
would
be
a
cumulative
int
delta
delta
sum
or
cumulative,
and
some
cumulative
float
some
delta
in
some
delta
float
sum
that
can
all
be
determined
at
the
time
of
creation
that
doesn't
change
over
time.
A
Right,
that's
a
product
of
the
view
and
the
reader
right.
Yes,
so
we
just
have
different
instances
of
that.
A
So
when
does
the
the
reset
happen
for
a
cumulative,
it
doesn't
for
a
delta,
it
happens
when
you
do
the
retrieve
and
since
that's
per
reader
right,
a
different
reader
would
have
a
different
group
of
aggregations
and
a
different
set
of
views,
and
it
would
create
when
you
create
the
instrument,
it
would
create
it
in
both
groups
of
readers
at
the
same
time,
and
it
would
update
in
both
readers.
At
the
same
time,
everything
stays
isolated
to
its
path.
A
Yeah,
I
think
the
difference
is
I
don't
go
one
level
deeper
of
like
the
sum
is
the
same
here
except
cumulative
and
delta.
I
just
say:
well,
there's
a
cumulative
sum
and
there's
a
delta
sum.
That's
okay.
We
know
all
of
that
information
when
we're
creating
it.
So
if
there's
a
little
bit
of
duplicate
code
that
that's
okay,.
B
Yeah,
well
I
mean
I,
I
still
think
we
could
probably
solve
that
with
some
generics
there
I've
been
playing
around
and
I
think,
that's
possible-
maybe
yeah
yeah,
okay.
I
think
I
think
that
sounds
good.
Could
you
share
a
link
to
this
sure?
A
B
Okay,
yeah,
that
sounds
good.
Okay,
let's
go
back
to
the
sharing
screen
here.
B
Okay,
cool,
so
I
think
that's
everything
we
wanted
to
kind
of
touch
on
in
the
project
boards
yeah.
I
think
that
looks
probably
good.
B
The
only
other
thing
I
wanted
to
kind
of
mention
was
this
this
issue,
but
I
think
we
might
actually
have
already
kind
of
touched
on
the
resolution,
so
I
was
putting
in
some
suggestions
here,
and
so
one
of
the
things
that
I
was
just
thinking
about
is
just
this
idea
of
how
to
configure
this
aggregation
at
the
view
level,
and
so
I
was
just
going
to
add
something
along
those
lines.
B
I
propose
something
like
this,
but
I
think
aaron
makes
a
good
point
that
this
encapsulates
some
sort
of
abstract
internal
thing
that
I
didn't
really
define
and
returns
an
instance
of
it,
but
I
think
what
I'd
rather
do
and
I've
been
playing
around
with
this
a
little
bit
is
just
to
have
similar
to
what
we
have
for
like
an
instrument
in
the
view
package
or
other
things
just
have
some
sort
of
structure
here
and
that
essentially,
that
structure
contains
all
the
configuration
for
an
aggregation
so
like
a
drop
struck
will
have
none
but
like
an
explicit
bucket,
histogram
aggregation
would
have
you
know
the
buckets,
and
this
record
min
max
type
and
essentially
like
the
struct,
would
just
be
a
config
for
each
one,
and
then
you
would
have
I
hadn't.
B
I
stashed
it,
but
I
can't
find
it
in
my
git
stash
right
now.
It'll
just
essentially
take
like
a
you
know,
a
with
set
attribute
function
here
for
the
for
the
view,
and
then
that
will
you
know,
accept
an
interface
that
could
be
any
one
of
those
aggregation
types.
B
The
interface
thing
was
the
thing
that
was
a
little
bit
worried
about,
because
we
technically
aren't
supposed
to
be
accepting
user-defined
aggregations
and
I
was
going
to
add
just
essentially
like
a
private
method
to
it,
to
you
know,
prevent
that,
but
there's
nothing
preventing
anybody
from
embedding
that
interface
to
get
around
it.
B
So
it's
it's
like
I
don't
know
at
some
level
you
kind
of
have
to
you
know,
communicate
to
the
users
they
shouldn't
be
doing
this,
but
if
they
want
to
go
off
on
that
path,
I
think
that
that's
just
the
way
it's
going
to
be.
There
are
ways
to
go
around.
It
be
really
strict
about
it,
but
it's
like
it's
bad
code,
and
I
didn't
really
want
to
mess
around
with
that.
So
I
think
that
was
kind
of
going
to
be.
B
My
answer
to
that
was
was
just
having
some
sort
of
interface
with
the
private
method
to
it.
B
Cool,
I
will
try
to
post
that
in
this
issue.
Again
I
went
off
and
just
looking
at
a
bunch
of
other
things,
one
of
them
is
reviewing
that
pr,
that's
outstanding
right
now,
but
other
than
that.
I
think
that
was
the
only
point
I
wanted
to
add
there.
The
next
thing
on
the
agenda.
Josh,
you
have
a
hotel,
go
launcher
with
exponential
histogram
support.
B
Okay,
well,
I
don't
know,
maybe
josh
is
just
only
listening.
Just
a
heads
up,
I
remember
this
from
previously
josh
was
talking
about
supporting
exponential
histograms
in
the
existing
sdk,
if
I'm
not
mistaken,
and
to
do
that
he's
created
essentially
a
distribution,
and
it's
it's
in
this
repository
lightstep
tested
from
jmx
sdk
prototypes
nearly
finished.
D
I'll
try
this
I'm
in
a
very
funny
office
today.
Lightstep
wanted
me
to
have
an
exponential
histogram
sdk
we
could
give
to
customers.
So
I
took
the
prototype.
I
was
working
on
in
february
and
march
and
just
finished
it
and
and
made
it
sure
it
was
kind
of
like
legit
and
tested
and
something
that
lightstep
would
itself
try
to
use
and
I'm
not.
I
really
don't
want
to
get
in
the
way
or
make
it
look
like
there's
interference
here.
D
So
I'm
trying
to
downplay
it
we'd
like
to
be
able
to
make
some
quick
controlling
decisions
over
performance,
for
example,
and
that's
one
thing,
light
steps
hoping,
but
I
do
hold
out
this
as
a
sort
of
fully
validated
now
complete,
complete
form
of
the
sdk
prototype
that
I
was
showing
off
in
february
and
march,
and
I've
gotten
eighty
percent
of
it
reviewed
and
tested
at
this
point.
D
If
you
were
reading
an
older
copy
of
any
of
my
code-
and
you
thought
this
doesn't
look
quite
right-
like
it
probably
wasn't
quite
right-
I
did
find
a
race
condition
or
two
with
some
of
my
original
code
and
a
few
bugs
in
the
synchronization
of
the
whole
story,
because
my
my
old
version
never
had
more
than
one
reader.
So
there
were
a
few
bugs.
B
Okay
with
that,
I
think
we're
almost
done
so
I
just
wanted
to
mention
that
I'm
gonna
be
at
an
off-site
splunk
event
next
week,
so
I
should
still
be
online
but
probably
slow.
The
response,
I'm
honest,
I'd
rather
be
doing
hotel
work
so
yeah
other
than
that
aaron's
listed
that
we
have
open
solution
days
at
the
open
source
conf
coming
up
on
june
20th.
I
think
you
can
still
get
a
ticket
for
a
virtual
attendee
right,
yeah,
there's
a
question
there.
As
of
monday.
B
Somebody
said
that
you
could,
but
I
don't
know
if
that's
still
an
option
but
yeah,
I
think
that's
I
I
don't
plan
on
being
there,
but
I
know
that
aaron
and
anthony
are
planning
to
be
there
and
a
whole
host
of
other
people.
So
if
you
have
the
time
it's
worth
it.
A
Yeah
that
I
was
just
gonna
say:
I'm
gonna
be
there.
I
know
a
few
other
people
will
be
if
you
want
to
get
together
and
do
a
dinner
one
of
the
nights
for
that
week
or
lunch
or
something
I
would
be
more
than
happy
to
to
help
add
local
expertise
to
the
restaurants
of
the
area.
B
You're
making
it
hard
for
me
not
to
come
also
just
a
heads
up
if
you
want.
There
is
also
an
an
hotel
panel
during
that
day
that
I'm
pretty
sure
that
it's
supposed
to
be
a
maintainer's
panel,
but
the
definition
maintainer
as
daniel
dallas
says,
is
it's
kind
of
light.
So,
if
you're
a
heavy
contributor,
they
they're
more
than
happy
to
have
you
up
there
and
you're
more
than
happy
to
be
a
part
of
the
crowd
and
answer
questions
as
well.
So
yeah.
B
Yeah
yeah,
that's
from
history!
That's
exactly
what
I've
experienced
so
yeah
cool,
but
with
that
there's
nothing
else
left
on
the
written
agenda.
I'll
pause,
see
if
everybody
else
has
anything
else
to
talk
about.
B
Cool
any
user
stories
by
chance.
B
Well,
then,
I
think
we
could
probably
end
it
here
short
and
sweet
like
we
were
saying:
cool
aaron.
I
I
don't
expect
them
to
have
time
this
next
week,
but
I'd
love
to
sync
with
you,
some
more
on
that
aggregation
stuff
in
the
future,
so
be
ready
for
a
slack
thing,
but
other
than
that
thanks
everyone
for
joining
we'll
see
you
same
place
same
time
next
week
or
asynchronously.