►
From YouTube: 2021-07-27 meeting
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
Now
we
can
start,
we
please
update
the
midi
notes
by
putting
your
name
so
first
for
the
view.
Pr,
I
think,
based
on
like
last
thursday,
like
like
talk,
we
already
figured
out
what
we
want
to
unblock
the
pr,
so
I've
updated
the
pr
please
take
another
look.
I've
seen
like
like
gmacd,
already
approved
that,
and
there
are
still
two
small
issues
regarding,
for
example,
the
histogram
buckets,
because
we
need
to
hammer
that
out
later
it
has
a
dependency,
so
john
watson
mentioned.
A
Should
we
remove
that
section
entirely
and
make
it
a
to-do?
I'm
fine
either
way.
I
I
just
think
like
we
spent
two
meetings
on
what
the
histogram
default
bucket
should
be,
and
I
hope
we
can
keep
it
there
as
long
as
we
mark
it.
Clearly
like
this
is
a
to-do
item
and
we'll
need
to
move
that
to
a
better
place.
A
My
body
is
we
remove
that
later,
when
we
come
back,
we'll
probably
spend
another
two
minutes
just
going
back
and
forth
again,
but
I
talked
with
john
and
and
he's
on
vacation,
so
he
won't
be
back,
which
means
like
either
we
wait
for
jung
and
we
stuck
for
another
two
weeks
or
emergent
for
now
and
I'm
happy
to
follow
up
I'll,
put
a
comment
there
and
and
josh.
A
That
it
has
today,
no
it's
basically,
I
I
put
a
tutu,
and
I
mentioned
some
examples
like
this
is
what
we
discussed
the
histogram
buckets,
but
that's
not
in
the
right
place,
because
that
should
be
part
of
the
default
aggregation.
I
think
after
victor's,
pr
will
have
a
better
spot
and
I
won't
move
that.
A
I
think
that
also
makes
sense.
I
can't
do
that
either
way,
but
my
border
is,
if
I
remove
that
entirely
later,
when
we
come
back,
we
talk
about
what
okay
do.
We
need
we're
we're
missing
all
the
history
I
mean
we
know
it's
under
construction,
there's
some
like
a
bonus
room.
We
need
to
like
rebuild,
but
keeping
it
there
instead
of
like
tear
that
down
entirely.
B
Point
guess
so,
so
I'm
going
to
challenge
the
assumption
that
it
doesn't
like
leaving
it.
There
means
we
won't
discuss
it
when
it
moves.
If
we're
going
to
discuss
the
default
histogram
when
you
go
to
move
it,
it's
going
to
show
up
in
the
change
list
and
people
will
discuss
it
like.
I
think
I
think
that
that
that,
if
we're
going
to
continue
to
discuss
the
default
histogram,
that's
going
to
happen.
B
I
think
the,
but
I
don't
actually
expect
that
to
happen
because
that's
been
besides
having
to
educate
new
people
on
why
the
decision
was
made
and
making
sure
that
we
record
why
the
decision
was
made.
I
don't
think
that
discussion
has
been
highly
contentious
outside
of
you
know,
milliseconds
versus
seconds.
Anyone
want
to
correct
me
if
I'm
wrong
there,
I
feel
like
it
was
mostly
just
here's
what
prometheus
does
by
default.
We
feel
like
this
covers
pretty
well
when
people
think
about
it,
they
tend
to
agree.
B
I
don't
think
we've
had
trouble
with
that
discussion.
The
same
way
we
have
on
other
things.
B
It's
in
without
the
least
amount
of
contention,
if
john
really
doesn't
want
it
there
and
he's
not
here,
I'm
fine
if
we
just
remove
it
and
merge
and
then
add
it
in
in
the
aggregator
vr
or
add
it
in
in
a
separate
histogram
pr
where
we
talk
about
default,
histograms
and
stuff
like
I
I
I
don't
expect
to
have
a
lot
of
pushback
on
that.
If
we
include
our
reasoning
somewhere.
B
B
So
I
I
think,
there's
there's
actually
there's
one
thing
that
I
wanted
to
call
out
and
I'll
add
it
as
a
spec
item
for
us
to
talk
about
later,
but
I
think
we
can
do
it
in
a
follow-up
as
as
addendum
to
what
it
says
on
the.
B
A
Okay,
I
I
think
we're
done
with
the
vlpr.
B
Okay,
so
I
have,
I
have
a
few
questions
then,
based
on
the
view,
pr,
so
from
my
understanding
of
the
view,
pr
aggregators
are
going
to
be
by
name
only
in
the
first
sdk.
Is
that
correct?
B
Okay?
So
what
I
would
like
to
avoid,
then
in
the
specification,
is
specifying
anything
about
implementation,
details
or
an
interface
of
aggregators
and
only
specify
here's
the
name,
here's
the
metric
it
produces
and
if
we
need
to
here
is
like
the
what
are
they
called
the
fancy
math
term
for
the
function
that
you
use
to
combine,
match
measurements
right
specifically,
because
I
don't
want
to
get
into
stupid
debates
about
like
method
names
like
kind
of
junk
around
aggregators,
because
I
think
that
can
be
a
follow-on
discussion
of
like.
So.
B
B
Okay,
that's
how
I
was
reviewing
the
pr,
and
so
I
wanted
to
make
sure
that
that
we
are
in
agreement
about
that.
There
is
an
option
of.
We
could
say
that
we
think
aggregators
are
going
to
need
to
be
customized
by
users
and
we
want
to
provide
that
as
an
interface,
and
I
feel
like
right
now.
The
pr
sits
a
little
bit
in
the
middle
between
the
two
right
of
how
to
implement
an
aggregator
versus
just
here's,
the
name
and
here's
what
it
here's.
What
metrics
about
books.
B
Am
I
still
muted,
I
feel
like
my
computer's,
I
I
can't
hear
it
all
day:
okay,
yeah
yeah,
so
so
what
I
mean
by
name
what
what
I'm
suggesting
is,
you
would
say
like
I
want
a
histogram
aggregator
and
here's
my
configuration
for
it
right
as
a
config
e
parameter
thing,
but
we're
not
defining
like
this.
This
is
an
interface.
B
You
know
it.
It
consumes
a
measurement
produces
this
value.
You
know
it
has
like
we're,
not
defining
the
the
interface
or
the
the
implementation
details
of
how
to
implement
an
aggregator,
we're
just
defining
here's,
how
you
configure
one
in
the
sdk
and
we're
going
to
have
names
for
them
of
like
this
aggregator
with
this
name
and
these
configuration
parameters
that
that
was
my
assumption
from
the
view.
Pr,
okay,.
C
So
may
I
ask
or
actually
chime
in
here
so
I've
been
doing
the
aggregation
stuff
and
do
you
have
an
issue
if
we
just
had
let's
say
a
simple
constructor
that
just
takes
in
like
one
or
two
parameters
like
for
example
today
we're
gonna
need
a
sum:
aggregator,
that's
one
for
delta,
one,
that's
cumulative!
So
we
have
a
couple
of
options
there.
When
you
say
by
name,
I
presume
that
the
simplest
way
most
language
will
implement.
That
is
by
some
kind
of
enumeration,
so
that
we'll
have
an
enumeration
that
says
sum
delta
sum.
B
No,
that's!
That's!
That's
not
what
I'm
implying
when
I
when
I
mean
by
name
what
I
mean
is
it's:
it's
not
an
interface.
What
what
I
mean
is
just
like
there
there's
a
way
of
describing
this
thing
with
its
name
and
that's
what's
exposed
it's
not
where
exposing
an
aggregator
interface
and
you
provide
implementations
of
it.
That's
all
I
mean
and
it'll
be
different
for
languages,
especially
ones
that
don't
have
constructors
right.
B
So
in
the,
for
example,
the
java
prototype
there's
a
builder
that
has
a
method
that
says
you
know
aggregate
as
histogram
and
it
takes
parameters
and
we're
using
the
builder
pattern,
because
in
java
the
builder
patterns,
the
convention,
that's
going
to
be
different
per
language.
So
again
the
key
there
is
here's,
the
name
of
it
and
here's
the
configuration
parameters,
as
opposed
to
like
here's,
a
class
that
you
would
extend
yeah
so.
D
D
So
there
is
a
possibility
to
have
a
an
interface
called
aggregator
if
that
makes
constructor
return
that
interface,
but
but
the
requirement
is
at
this
moment
that
interface
should
not
be
defined,
should
be
private
if
possible,
or
methods
on
that
interface
should
be.
Private
should
not
be
extends
extendable.
A
Yeah,
I
think,
number
one
we're
not
ready
to
allow
any
users
to
implement
their
private
aggregators
on
top
of
existing
aggregators.
So
we're
not
going
to
expose
any
public
interface
to
allow
that,
like
extension
or
customization,
number
two
is
given.
We
don't
expose
that
interface.
We
don't
expect
people
to
use
the
interface
because
there's
nothing
like
that
on
any
view
api.
Instead,
on
the
view
api,
we
want
to
specify
the
aggregation.
It
has
to
be
something
else,
whether
it's
a
string
or
it's
a
configuration.
D
B
C
Yeah,
so
I'm
struggling
to
understand
this,
I
mean
so.
We
know
that
we
need
to
specify
minimum
of
two
things,
the
name
or
the
type
of
aggregator
that
we
want,
either
by
name
or
by
enum
or
some
you
know
or
by
class,
and
we
need
to
provide
it
parameters
right.
So
so
is
there
something
wrong
with
just
defining,
let's
say
a
sum
aggregator
constructor
that
takes
in
temporality,
but
that
class
is
sealed,
locked
down.
You
can't
extend
it.
You
can't
do
anything
with
it.
D
So
victor
aggregator
will
have
a
merge
or
some
method
on
it.
Correct
users
should
not
be
able
to
call
that
merge,
because.
E
E
C
D
C
D
D
I,
as
long
as
that
class
can
be
transformed
into
an
interface
later.
I
don't
see
a
problem.
I
don't
know
the
the
the
limitation
of
the
the
dot
net.
If
transforming
that
class
that
you
right
now
have
a
class
to
to
be
transformed
into
an
interface.
If
it's
a
breaking
change
or
not,
but
that
should
not
be
the
case.
We
should
be
able
to
transform
that
into
an
interface.
C
F
B
So,
to
be
clear,
the
specification
should
define
here's.
The
default
aggregation
per
instrument
which
is
in
the
current
spec
it
should
define
here,
is
how
you
can
configure
each
aggregator
in
view
when
I
say
I
want
this
as
a
histogram
or
I
want
this
as
a
sum
or
I
want
this
as
last
value
right
or
gauge
or
whatever
we
want
to
say
and
like
that
set
of
things,
that's
it.
It
doesn't
need
to
say
anything
else.
It's
just
here's
how
I
configure
them
on
views,
here's
what
the
defaults
are
for
instruments.
B
That
is
all
that
specification
needs
to
be
right.
Now,
all
the
rest
of
it.
We
we
want
to
wait
until
we
have
our
prototypes
ready
and
where
we
can
define
this
interface
that
we
feel
is
actually
sufficient
and
complete
across
all
languages,
and
I
think
that
will
help
get
that
thing
through
a
lot
quicker.
That's
all
I'm
suggesting
I
don't
want
to
derail
into.
How
do
we
implement
aggregators?
I
don't
think
that's
actually
useful
right
now.
C
Time
a
comment
here:
I
don't
disagree
with
your
statement.
So
question
is
the
pr
that
I
have
for
aggregator.
Is
that
too
detailed,
or
are
we
needing
to
do
that
separately
or.
B
There's
there's
a
bunch
of
musks
in
there
that
I
would
like
to
remove,
because
I
don't
think
they
need
to
be
there
like
again,
the
only
the
only
thing
I'd
like
for
that
pr
to
focus
on
is
here's
how
you
configure
them
in
views
and
here's
the
default.
B
So
here's
the
name
of
the
ones
that
you
can
configure
in
views
and
the
configuration
parameters
they
take
the
metrics
that
they
produce
and
then
here's
the
default
for
instruments
to
the
extent
that
that's
all
that's
in
there,
that's
great,
but
the
whole
bit
about
the
default
measurement,
processor
and
and
what
aggregators
must
and
must
not.
B
A
Yeah,
I
think
what
I
can
do,
given
I'm
going
to
remove
the
default
histogram
buckets
from
the
view.
Pr,
I
need
to
put
it
somewhere,
I'm
happy
to
work
with
vector
offline
to
update
his
pr
I'll
contribute
to
hpr
by
sending
pull
requests
to
his
range,
and
I
I
think
my
understanding
is
we
we
just
we
just
limit
the
like
it's
very
similar
to
what
I
have
for
the
histogram
in
the
vpr
just
list
how
this
is
what
the
default
behavior
is,
and
this
is
what
we
allow
and
the
user
to
change,
no
interface.
B
Josh
you're
mutated
again,
I
know
I
know
sorry
about
that.
Okay,
so
this
one,
this
one
is
just
the
the
proposal
for
the
exemplar
specification.
Now
this
one
does
propose
an
interface
for
an
example
or
filter
and
exemplar
reservoir.
B
I
am
totally
fine
if
we
remove
that
from
the
specification
again,
because
I
don't
want
us
to
fight
over
what
these
things
are
and
what
they
do.
I
think
the
the
baseline
is
more
important.
So
if
you,
if
you
read
the
specification,
you'll
see
html
comments,
I
guess
or
xml
comments.
I
don't
know
whatever
that
define
what
I
you
know
what
I'm
okay
dropping
and
I'm
curious
if
that
resonates
with
people,
but
if
you,
if
we
start
to
hit
contention
around
what
the
interfaces
actually
are
totally
fine
to
drop
them.
B
What
this
does
specify
is
what
exemplars
should
do
at
a
minimum,
and
I
also
highlight
divergences
from
the
original
otep.
Specifically,
I
think
we're
moving
in
the
direction
of
reservoir
based
sampling,
where
we
can
make
sampling
decisions
and
we
aren't
necessarily
going
to
provide
one
bucket
per
histogram
bucket
as
a
guarantee.
B
That
is
the
big
divergence
from
the
original
otep.
So
for
those
who,
for
those
of
you
familiar
with
the
original
hotep
and
existing
exemplar
specifications,
this
is
this
is
a
reservoir
based
approach
and
it
doesn't
not
guarantee
that
all
histogram
buckets
will
be
covered.
However,
it
also
leaves
that
kind
of
unspecified,
so
an
sdk
can
provide
that
kind
of
assembler.
If
they
want.
B
Please
take
a
look.
I
don't
want
to
take
too
much
of
our
in-person
discussion
here,
because
I
want
to
give
people
a
chance
to
read
it,
but
I
didn't
actually
open
it.
It's
still
a
draft
because
I'm
waiting
for
the
aggregator
and
upr
to
get
in
so
I
can
tie
it
into
the
appropriate
locations.
One
last
thing
to
call
out:
I
added
a
configuration
section
to
the
spec
with
a
set
of
environment
variables
that
can
be
configured
based
on
bogdan's,
pending
otep.
That
will
talk
all
about
configuration
for
us.
B
I
look
forward
to
matching
that,
but
it's
it.
It's
basically
a
parameter
to
help
control
some
reservoir
sampling,
specifically
around
limiting
measurements
that
are
eligible
right.
So
there's
two
components
to
the
the
proposal:
there's
a
set
of
configuration
where
you
can
limit
eligible
measurements
to
only
those
that
have
sampled
spans
and
it
and
it
talks
about
the
mechanism
and
the
rest
of
the
spec
that
it'll
use
and
the
second
bit
is
this
plan
to
use
reservoirs
to
sample
it
proposes
an
interface
for
reservoirs.
That's
pretty
generic!
B
It
does
not
propose
any
implementation
details
about
reservoirs
for
now
only
that
you
will
get
sampled
exemplars
from
these
aggregators
okay.
So
it's
it's.
Please
take
a
look
if
you
think
it
needs
more.
Let
me
know
if
you
think
it
needs
less.
I
outlined
where
I
felt
it
could
do
less
if
we
wanted,
if
we,
if
we
find
contention
and
I'm
happy
to
cut
that
out.
A
B
B
Okay,
so
last
is
on
aggregation
temporally.
This
is
something
that
we've
kind
of
talked
about.
There's
there's
a
bit
on
this
in
victor's.
Pr
that
I
like,
and
I
think
I
I
want
to
make
sure
we're
going
this
direction.
B
So
when
we
aggregate
synchronous
instruments
right
inherently
feel
like
they
want
to
be
delta
aggregations,
the
simplest
way
to
implement
them
cumulative
also,
you
know,
is
the
inverse
with
asynchronous
instruments
where,
when
you
do
asynchronous
sampling
cumulative
is
the
easiest
to
pull
right
and
we've
kind
of
talked
about
this
a
little
bit
and
talked
about
what,
if,
by
default,
the
aggregators
provide
delta
for
these
synchronous
instruments
and
cumulative
for
asynchronous
and
then
somewhere
downstream.
F
B
F
Want
to
check
with
other
people
related
closely
related
is
that
we
in
the
go
sdk.
We
also
implemented
the
stateful
processor
as
a
subtract
function
if
you
ever
want
to
take
cumulative
measurements
and
turn
them
back
into
deltas,
which
only
would
happen
if
you're,
a
consumer
that
only
supports
deltas
and
can't
accept
cumulatives,
which
turns
out,
does
exist
and
we've
seen
more
than
once.
The
new
relic
team
comes
in
and
says
yeah
all
of
our
system
is
based
on
deltas
exclusively,
and
so
in
my
prototype,
I
have
this
machinery
to
subtract.
F
C
Just
a
note
that
in
in
the
c-sharp
implementation
prototype
the
expo
when,
when
we
do
our
collection
function,
so
we
have
that
concept
of
aggregators
and
when
the
exporter
comes
in
to
collect
the
metrics,
it
tells
us
whether
or
not
it
wants
delta
or
cumulative
that
we
talked.
We
discussed
that
previously
about
you
know
who
owns
that
particular.
But
in
this
case
exporter
asks
the
aggregator
to
do
to
for
delta
cumulative
and
the
aggregator
without
implementation
specification.
C
But
the
aggregator
will
then
do
its
best
to
provide
what
the
exporter
need,
including
a
possibility
of
converting
from
delta
to
cumulative
accumulator
to
delta,
which
maintains
all
of
the
state
management
and
the
storage
all
inside
an
aggregator.
So
from
the
c-sharp
perspective
and
aggregate
is
really
the
only
thing
that
has
state
or
stateful
needs
per
se.
B
This
is
why
I
wanted
to
talk
about
it
because
I
there's
yeah,
so
should
the
exporter
be
controlling
the
aggregation
coming
out
of
so
so
I
have
another
question
later
around
metric
producer
kind
of
not
or
not
metric
processor
not
really
being
specified
or
outlined
as
an
interface,
and
I
think
we
need
to
because
we
have
metric
exporter.
We
have
metric
processor
kind
of
as
this
concept-
that's
not
really
outlined,
but
my
real
question
is:
what
do
the
metrics
look
like
that
hit
an
exporter
right?
B
Does
the
exporter
get
to
say
I
want
this
aggregation
and
someone
else
takes
care
of
it
or
are
we
going
to
basically
feed
in
you
know
if
you,
if
I
read
your
aggregator
spec,
it
says
this
aggregator
will
produce
deltas
right.
This
aggregator
will
produce
cumulatives
in
this
scenario.
Right.
Is
that
what
I
should
expect
in
the
metric
exporter?
B
I
think
we
all
need
to
align
on
what
the
electric
exporter
sees,
and
so
if
the
metric
exporter
has
a
means
to
basically
say
here's
the
key,
the
temporality
I
want
and
someone
else
manage
it,
that's
fine,
but
I
I
think
we
we've
heard
two
different
opinions
and
victor
what
you
implemented
was
what
I
heard
about
a
month
or
two
ago
and
then
last
month
I
heard
the
other
thing
that
we're
just
talking
about
right
now.
So
I'm
kind
of
curious
which
one
we're
going
with.
A
I
I
intend
to
cover
this
in
the
exporter
pr,
but
here's
my
current
thinking.
Let's
say
if
you
have
a
console
or
in-memory
exporter,
you
probably
want
to
validate
like
whether
the
algorithm
is
correct.
Imagine
like
later
you
want
to
implement
your
own
aggregator
and
you
want
to
support
both
delta
and
cumulative.
I
can
imagine
the
situation
where
I
want
my
in-memory
exporter
to
be
able
to
handle
temperature
as
the
absolute
value
and
handle
the
incoming
request
as
delta
as
I
want
to
test
that
and
it
it
won't
work
for
me.
A
If
I
have
to
specify
something
on
the
exporter
saying
I
want
everything
to
be
cumulative,
so
I
can
imagine
in
the
future
we
might
say
an
exporter
instance
will
be
able
to
receive
cumulative
and
delta
from
different
streams,
and-
and
I
kind
of
imagine
that
exporter
can
give
some
metadata
telling
hey,
I
support
both
or
I
can
only
support
delta.
If
you
give
me
a
cumulative,
I
like
I
have
to
drop
the
data,
I
don't
export,
I
I
don't
expect
the
exporter
will
do
any
delta
cumulative
or
vice
versa.
Conversion.
F
In
my
prototype,
the
way
I
handled
this
was
when
a
new
aggregator
is
needed.
The
aggregator
is
the
there's
a
selector.
That's
given
the
opportunity
to
decide
which
temporalities
the
aggregator
is
responsible
for
producing
and
then
so
so,
at
the
construction
time,
the
processor
knows
all
of
its
exporters.
It
consults
all
of
its
exporters.
F
The
result
of
this
is
that
the
exporter
dictates
which
temporality
it
wants
at
the
time
of
aggregate
aggregator
construction
and
the
processor
remembers
what
it's
supposed
to
do
at
the
time
of
activator
construction,
meaning
are
we
supposed
to
be
stateful
or
not?
And
then,
by
the
time
the
exporter
sees
this
data.
It's
already
been
properly
handled,
it's
in
their
correct
temporality,
but
there
was.
There
were
two
contact
points
at
the
construction
time.
You
say
all
the
temporaries
you
want
and
at
export
time
you
get
the
thing
you
asked
for.
F
C
Yeah
so
so
I
was
going
to
say
that
I
agree
with
you
josh
mcdonnell
and
to
answer
suresh
josh
suresh's
question
earlier.
C
Is
that
to
josh
mcdonald's
point
the
aggregator
when
you
first
construct
it
and
for
all
the
actual
accumulation
and
aggregation
of
data
we
do
you
know
we
do
construct
the
aggregator
with
the
temporality
in
place
and
then,
depending
on
the
implementation,
and
whether
or
not
that
particular
implementation
want
to
go
above
or
beyond
that
particular
aggregator
may
or
may
not
have
a
conversion
to
support
other.
You
know
temporality
as
necessary
when
the
exporter
comes
by
and
asks
all
the
aggregate
hey.
C
I
want
cumulative
or
I
want
you
know,
delta
the
aggregators
say
I
could
do
it
for
you
or
no.
This
is
all
I
support
and
then
it's
up
to
the
exporter
to
to
choose.
You
know
appropriately
at
that
point
based
on
the
you
know,
collection
of
aggregation
it
has
so
in
in
this
particular
implementation.
The
exporter
doesn't
tell
at
construction
time.
You
know
you
know
what
what
aggregators
to
construct
or
what
have
you,
because
we
were.
B
Yeah
yeah,
so
I
think
the
java
implementation
then
diverges
the
most
here,
because
we
did
the
least
amount
of
work
on
the
exporter
side.
We
have
no
idea
how
many
exporters
we
have
or
will
have,
because
it
can
change
dynamically
at
runtime
still
in
the
java
spec.
So
it's
starting
the
java
prototype,
and
that
is
something
I
want
to
change
but
hey.
I
think
I
know
what
I
what
what
the
result
of
this
outcome
of
this
discussion
is
is.
Can
we
get
the
exporter?
B
Spec
worked
on
a
little
bit
because
from
what
I'm
hearing
everybody
wants
exporters
to
define
the
temporality
they
desire
right
as
like,
I
want
delta
or
I
want
cumulative,
and
when
we
look
at
the
other
side
around
the
view
spec
around
aggregation,
it
sounds
like
we
don't
want
views
to
be
able
to
define
temporality,
because
we
want
the
exporters
to
own.
That
decision
is
that
correct.
A
No,
no
that's
different
from
my
understanding.
My
understanding
is
the
exporter
might
be
able
to
suggest
that
what
it
wants
or
it
it
commanded
that
it
only
supports
cumulative
or
it
only
supports
delta.
But
if
the
next
part
like
otlp
can
support
both,
then
the
user
might
say.
I
have
three
instruments.
I
want
instrument
a
to
be
exported
as
delta,
but
b
and
c
should
be
cumulative.
A
Yeah,
I
think,
on
the
view,
if
the
user
didn't
choose
anything
we'll
give
the
default
and
the
defaults,
probably
I'll,
prefer
the
default
to
respect
the
exporter.
But
I
agree
with
you
josh
suresh
that
we
should
make
progress
on
the
exporter
pr-
and
this
is
my
next
big
thing
after
the
view
got
merged.
B
Yeah
yeah,
I
mean
there's
so
basically
my
big
open
question
is:
I
want
to.
I
think
that
the
java
prototypes
behind
the
other
prototypes
in
terms
of
the
current
thinking
with
aggregation,
temporality
java
right
now
forces
it
to
be
decided
only
by
views
and
then
exporters
just
deal
and
this
notion
of
exporters
influencing
it.
I
I
want
to
kind
of
understand
what
that
looks
like
how
to
implement
that.
What
overrides
happen
all
that
kind
of
stuff,
because
we
need
we
need
to
update
our
implementation
for
there.
B
B
That's
a
possibility,
but
but
most
importantly,
what
I
want
is
is
what
is
actually
going
to
be
specified
and
what's
the
dance
between
an
exporter
asking
for
a
temporality
and
what
the
sdk
needs
to
do
so.
Yeah.
B
B
I
think
should
we
walk
into
the
next
topic
yeah,
so
this
is.
This
is
possibly
my
misreading
of
the
spec,
but
if
you
look
at
the
current
view
pr
around,
because
I
again
I
implemented
the
the
current
view,
pr
of
the
specification-
and
I
should
actually
include
a
link
so
I'm
getting
on
that
sorry
around
extra
attributes
and
around
the
attributes
that
are
chosen.
B
So
one
thing
that
I
wasn't
clear
on
in
java
attribute
keys
have
types
associated
with
them.
In
this
specification
it
all
the
examples
are
string
based
right
and
so
what
I'd
like
to
do?
I
I
implemented
this
spec
almost
exactly
as
written,
and
I
think
it's
a
terrible
api
in
java,
because
what
I
really
want
to
provide
is
just
regex
patterns
and
a
configurable
set
of
regex
patterns,
and
I
want
to
make
sure
that
that,
like
the
way
this
is
specified
and
what
we're
implementing
this
is
kind
of.
B
Okay,
so,
like
it
says
a
list
of
attribute
keys
as
an
example,
that's
optional,
if
not
provided
all
attribute
keys
will
be
used
by
default.
But
a
list
of
attribute
keys
in
java
is
actually
a
type
set
of
name
type
pairs
so
like
I
am
boolean,
and
I
am
this
value
I
am
float
and
I'm
this
value
and
it's
a
really
atrocious
api
to
use
in
practice.
B
B
I
I
also
want
to
do
this
as
a
follow-on
pr.
Not
I
don't
want
to
change
that
pr
at
all
at
this
point,
but
what
people
think
about
expanding
that
pr
to
include
like
regular
expressions
against
keys
or
a
configurable
set
of
them?
I.
A
Support
that
my
my
only
concern
not
not
concerned,
I
think
you
will
cover
that
if
we
choose
regular
expression,
I
would
want
that
regular
expression
to
be
tied
to
the
language.
So,
basically,
you
give
me
the
java
regular
expression
type
instead
of
some
like
string,
because
each
language
have
their
own
preference
of
what
regular
expression
should
look
like,
and
I
don't
want
it
to
be
a
string
for
while
if
we
want
wild
card,
I
think
it's
totally
fine
to
have
that
standardized
as
a
string
across
all
languages.
B
Yeah
yeah
totally
and
I
I
can
open
a
follow-up.
I
think
it
should
be
small
and
hopefully
not
contentious,
but
I'm
also
going
to
make
it
be
a
should
or
or
a
could
not
a
must.
So.
A
A
First,
as
I
explained,
if
you
want
to
have
string
as
regular
expression
across
all
languages,
people
would
hate
us
because
for
different
languages
like
javascript
and
c-sharp,
they
have
very
different,
regular
expression,
syntax
and
if
we
ask
people
to
use
type
at
certain
moment,
I
would
expect
people
want
to
use
a
configuration
file
or
environmental
variable,
and
it
is
becoming
hard
because
that
environment
variable
for
different
language
will
mean
different
things.
This
is
why
I'm
trying
to
stay
safe
and
while
the
car
is
widely
adopted-
and
I
I
think
it's
good
enough
for
attributes.
C
C
B
Instrument
in
the
specific
part
of
the
view,
spec
we're
talking
about,
are
like
what
baggage
values
to
attach
as
metric
labels
and
what
the
list
of
attribute
keys
that
you're
going
to
keep
versus
the
ones
you
aggregate
away.
So
someone
needs
to
specify
that
somewhere
and
we're
not
exposing
an
interface
for
users
to
do
this,
we're
only
exposing
configuration.
So
the
configuration
here
has
to
be
complete.
C
Right,
I
mean
even
for
selection
of
attributes,
you
know
per
your
problem,
it's
like
you
know.
Why
not
just
say
you
know,
here's
an
instrument,
here's
some
attributes
or
whatever
it
is.
We
already
have
defined
our
key
value
pairs
or
whatever
the
attribute
is
and
then
just
let
you
know
generically
have
them
just
say
yes
or
no
right.
B
Yeah,
we
actually
have
a
thing
called
an
attributes
processor.
In
java
I
mean
it.
If
you
look
today,
it's
called
labels
processor,
but
it
got
moved,
attributes
processor
that
allows
you
to
attach
baggage
and
all
that
and
we're
implementing
everything
behind
this
interface
we're
just
not
exposing
that
to
users
today,
right
like
again,
it's
the
spec
has
how
to
configure
views
and
that's
all
you
get.
B
B
So
I'm
backing
all
of
it
with
that
thing,
but
in
terms
of
how
we've
specified
a
user
configures
the
view
we
could
expose
a
lambda,
and
I
think
we
specifically
decided
not
to
do
that
yet
so
that
we
don't
for
two
reasons.
One
is,
I
think
we
could.
B
We
can
define
it
later
because
we
have
to
find
the
minimum
here,
and
the
second
reason
is
so
that
we
avoid
fighting
over
what
the
interface
is
across
all
the
different
prototypes,
because
I
think
we
all
have
a
different
thing
that
we've
implemented
to
the
extent
that
the
configuration
we
have
right
now
is
sufficient.
B
I
think,
if
we
add
this
regex
matching
or
or
a
wild
card
matching
either
one.
It
gives
us
enough
flexibility
that
I'm
totally
fine
with
it
for
v1,
and
then
we
can
fight
over
what
that
interface
looks
like
later.
My
fear,
though,
is
we
shouldn't
expose
that
raw
interface
just
yet
without
some
understanding
of
what
it
should
be
and
where
it
should
live,
and
then,
secondarily
the
the
differences
between
the
languages.
C
B
F
G
The
problem
is,
is
that
you
have
languages
that
implement
something
in
a
particular
way
and
another
language
implements
a
very
similar
looking
thing
another
way,
and
then
you
have,
the
standardization
process
becomes
very
complex
and
it's
going
to.
G
I
mean
that
that
being
said,
like
I
know
in
the
gosig
specifically,
we
do
this
pretty
often
where
we'll
come
up
with
some
ideas
and
we'll
bring
it
back
to
the
group.
Oh
well,
we've
gotten
better
at
bringing
it
back
to
the
group
in
all
elements
of
open,
telemetry
and
sometimes
coming
to
the
specification
side
of
things.
People
just
go
like
that's
cool,
but
that's
such
a
go
thing
like
just
go.
Do
it
yourself?
So
maybe
we
could
just
try
that
process.
A
Yeah
for
for
the
attribute
names,
I
I
think
it's
not
a
super
complex
thing
and
if
you
want
to
pursue
the
wild
card
or
regular
expression,
I
think
it's
probably
just
one
or
two
weeks
work
and
I
think
it's
worth
it
for
anything
else.
I
I
think,
probably
will
kind
of
say
like
if
people
just
want
attribute
names
with.
We
ask
all
the
isd
case
to
implement
wild
card
order.
Expression
like
this
way
and
if
language,
like
certain
implementation,
want
to
give
more
flexibility
like
a
callback
for
arbitrary
type,
they
can
do
that.
A
B
Another
thing:
if
it's
possible
java
has
this
notion
of
sdk
extensions,
where
we
provide
all
sorts
of
crazy
stuff
and
it's
done
in
a
module
which
is
considered
unstable.
It's
a
really
good
place
for
experimentation
and
exposing
these
kinds
of
things.
So
probably
we'll
try
to
figure
out
a
way
to
expose
things
there
to
get
actual
test
usage
from
users
who
are
willing
to
accept
the
risk
that
it
could
change
and
and
it
to
the
extent
you
can
do,
that
I'd
recommend
it.
E
I
was
just
going
to
jump
on
the
regular
expression
point.
Can
people
hear
me
I've
been
having
some
problems
with
my
mic.
Someone
mentioned
that
there
was
potentially
some
differences
between
the
target
language
implementations.
E
Are
there
some
good
examples
of
exactly
what
those
differences
might
be?
The
only
one
that
I
was
racking,
my
brains,
the
only
one
I
could
think
of
was
something
like
the
syntax
for
named
capture
groups.
Is
that
the
kind
of
thing
we're
talking
about
when
we
say
that
c
sharp
is
different
from
javascript
is
different
from
java,
or
is
there
something
more
fundamental
than.
F
E
That's
what
I'm
wondering
so
if
it's
just
if
it
is
only
you
know
some
some
out
there
things
relatively
speaking
like
that,
then
my
my
opinion
is
that
full
regular
expressions
are
going
to
be
a
hell
of
a
lot
more
useful
than
just
simple
wildcarding.
E
B
I'll
tell
you
what
I'll
make
the
pr
against
the
other
pr
and
I'll
look
up,
because
I
bet
there
exists
some
regular
expression
spec,
that
is
the
minimal,
regular
expression
spec
across
all
languages
of
here's,
the
only
things
we
allow
that's
a
minimum
set
and-
and
if
I
can
find
that
thing
I'll
link
it
and
we
can
use
that.
A
A
A
When
I
look
at
that,
there
are
two
open
items,
one
is
the
specific
instrument
for
measuring
duration,
which
I
I
think
we
agreed
that
we're
not
able
to
cover
that
another
one
is
for
the
callback
returning
height.
I
can
follow
up
with
the
jonathan
with
that
tool
covered.
I
I
think,
we'll
be
able
to
catch
the
next
spec
release
just
by
marking
the
metrics
api's
feature
freeze.
A
So
I
I
propose
that
I'll
create
a
pr
to
change
the
status
from
experimental
to
feature
freeze
for
the
api,
spec
and
I'll
I'll
go
through
the
current
document
to
see
if
there's
any
wording
or
like
type
all
those
things
I'll
make
some
simple
update
in
a
separate
pr,
and
I
want
people
to
give
me
feedback
whether
you
see
a
particular
thing
that
would
require
us
to
delay
the
feature
phrase
for
api.
B
Fyi
we
have
a
pr
out
for
java
to
migrate
to
the
new
api
and
it
works.
H
I
think
this
dovetails
into
the
last
topic,
just
just
a
general
question,
because
we've
been
working
on
metrics
for
so
long
like
do.
We
want
to
set
any
more
firm
target
dates.
Is
there
anything
I
can
do
to
assist
progress
like,
like?
I
remember
when
we
were
finishing
up
on
tracing.
We
had
andrew
coming
in
every
week
with
a
burn
down
charge
and
everything
would
that
be
helpful
here
like
like
how?
How
can
I
best
assist
like
I've
got
myself?
H
B
I
think
for
the
yeah
sorry
josh
go
ahead.
B
I
was
gonna,
I
was
gonna
make
a
quick
suggestion
is
if
you,
if
you
look
at
even
the
notes
of
this
particular
meeting,
recording
decisions
and
rationale
is
actually
probably
the
most
significant
thing,
we're
involved
in
the
discussion,
and
then
it's
really
I
know
from
for
when
I
ran
the
metric
sig
and
I
know
for
riley,
it's
probably
really
hard
to
listen
to
the
discussion
and
write
notes.
H
B
Comment
meaningfully
and
write
the
decisions
and
discussion
as
they're
happening
so
that
that
rationale
is
captured,
but
also
we
tend
to
rehash
discussions
a
lot
and
so
to
the
extent
that
it's
captured
and
then
someone
is
keeping
tabs
of
discussions
and
active,
open
conflicts
or
active
like
resolved
things.
So
we
can
point
back
to
them.
That
would
be
super
valuable.
Sorry
bradley
go
ahead.
A
Just
regarding
what
josh
mentioned,
I
I
think
the
challenge.
What
I
see
is
we
we
like.
We
have
some
challenge,
but
those
challenge,
I
I
think
we
can
cover
them.
The
biggest
challenge
I've
seen
is
sometimes,
in
the
sake
we
kind
of
made
the
decision
with
people
who
join
the
meeting,
but
for
people
who
miss
that
meeting
later
they
can
come
back
and
reward
the
decision,
and
I
have
no
good
way
of
handling
this.
D
A
Meetings,
I
I
think
we
probably
will
continue
to
do
that
until
we
have
the
three
major
things
figured
out
like
how
do
we,
the
pipelining?
How
do
we
do
the
exporting
and
the
aggregation
so
before
that?
I
I
think
we'll
probably
will
be
almost
the
same
as
bad
as
we
are
today.
But
after
that
I
I
think
the
like
the.
H
Changes
should
be
fairly
small
correct
and
we
discussed
this
last
week
in
the
maintainers
call.
I
remember
like
it
looks
like
that's.
The
last
big
hurdle
was
the
sdk
spec
yeah,
all
right,
we'll
all
be
attending
these
calls
every
week
and
I'll
attend
the
sdk
spec
calls
every
week
and
I
will
try
and
take
more
copious
notes.
While
people
are
talking
yeah
and
maybe.
A
For
the
api,
once
we
went
feature
freeze,
I
I
think
we
can
track
that
in
the
in
the
spec
meeting
like
we
look
at
related
small
issues
and
make
decision
whether
it
is
required
for
the
stable
release
or
not
and
do
the
triage
like
more
frequent
basis
yeah
for
isdk.
I
I
hope
that
within
two
or
three
weeks
we'll
be
able
to
get
the
experimental
release.