►
From YouTube: 2021-11-23 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
It
should
be
good
yeah.
I
have
an
old
calendar
sync
for
those
who
are
curious,
so
I
actually
have
two
meetings
every
week
and
I
always
click
on
the
wrong
one
generally,
but
usually
it's
the
same.
One.
C
Hey
everybody:
let's
wait,
one
more
minute
in
case
we
are
still
waiting
for
people
that
join
the
incorrect
meeting.
C
Okay,
let's,
let's
start,
if
that's,
okay
with
everybody,
thank
you
for
joining
yeah.
Thank
you
for
adding
by
the
way,
whoever
added
the
note
regarding
the
zoom
room,
yeah.
Let's
start
with
the
non-metric
specific
stuff
for
now
so
tristan
pr,
two
one
two
one
no
start
span
should
always
return
return.
Parent.
C
Okay,
probably
well.
B
C
C
Yeah
yeah
yeah.
Well,
that's
that's
a
little
bit
problematic
in
any
case.
Basically,
this
changed
up
this
review
that
blocked
another
comment
already,
but
other
than
that.
Basically
it's
regarding
what
to
do
when
you
are
using
the
api
in
an
op
fashion.
What
to
do
yeah.
I
guess
we
need
to
review
that
so
far.
Only
box
and
review
that
one,
the
next
one
is
also
from
tristan
per
tracer
configuration,
and
this
is
an
hotep
actually.
C
C
The
idea
of
this
step
is
I'm
just
reading
that
now
a
support
setting
configuration
sampler
id
generator,
spam
limits,
etc
on
individual
tracers
that
override
the
shared
configuration
provided
by
the
tracer
provider.
So
probably
this
one.
It
will
be
interesting
to
to
to
consider
so
please
review
that
as
well.
C
C
Perfect
now
we
go
that's
probably
yeah
a
little
bit
better
yeah,
so
basically
yeah.
C
The
next
item
is
this
one,
which
is
I
added
it
two
minutes
ago:
it's
not
mine.
Basically
it's
about
adding
service
the
service
term
to
glossary.
C
There
was
some
initial
discussion
regarding
where
should
it
be
whether
it
should
be
in
the
semantic
convention
section
or
the
glossary
itself,
and
there
has
been
lately
some
discussion
regarding
what
service
means
and
why
maybe
this
cannot
be
defined
with
the
correct,
with
the
current
wording
for
mobile
devices.
John
watson.
Are
you
around
he's
not,
but
please
take
a
look
at
that.
It's
relatively
straightforward,
but
we
need.
Of
course,
all
the
parties
involved,
as
you
can
see
here.
C
John,
is
mentioning
that
in
this
comment
that
he
doesn't
understand
what
the
definition
service
includes
and
especially
for
web
pages
or
mobile
apps.
The
injuries
like
mentioning
that,
but
probably
he
doesn't
agree
with
that.
So
please
take
a
look,
that's
important
enough.
It
has
been
approved
for
for
some
time
now,
but
we
need
to
wrap
up
the
discussion
there.
C
C
If
there's
nothing
else,
I
guess
we
can
right
away
jump
into
the
metrics
discussion,
especially
I'm
very
interested,
because
I
know
that
riley
sent
the
pr
to
propose
the
sdk
becoming
stable.
So
I'm
pretty
interested
about
that.
D
Yeah
can
I
focus
my
screen
I'll
try
to
make
it
bigger,
yep
yeah,
so
so
first
we're
we're
trying
to
get
the
sdks
back
to
stable
and
just
heads
up
this
week.
We
won't
have
the
metrics
meeting
due
to
the
thanksgiving
I'll
update
the
calendar,
and
I
have
one
specific
ask
I'll
be
gone
for
the
entire
december.
So
do
you
think
we
should
keep
the
metrics
meeting
at
december
time?
My
worry,
is
there
won't
be
enough
participants?
D
I
don't
know
many
folks
will
be
on
vacation
and
maybe
this
meeting
can
be
used
because
anything
that
is
related
to
stable,
like
when
we
decide
if
a
particular
issue
should
be
post
stable
release.
I
I
think
it's
an
important
thing
so
better
to
have
a
wider
audience,
so
my
suggestion
would
be.
We
cancel
the
december
metric
sig
meeting
and-
and
we
use
this
meeting
to
close
any
issues
that
are
marked
as
a
blocker
for
stable
release.
D
No
objection,
okay,
I'll
I'll,
update
the
calendar,
then
so
I
send
the
pr
to
mark
the
sdk
spec
high
stable.
Currently
it
has
dependency
on
other
issues,
so
I
just
put
the
pr
here
you
can
find
that
in
the
description.
D
D
Vacation
I
I'll
try
as
best
as
I
can,
but
I
understand
there
might
be
new
issues
coming
so
we'll
try
to
follow
us,
but
we
have
some
reality.
So
in
case
there
is
a
blocking
issue.
We
should
address
that
instead
of
rush.
E
Yeah
is
it
we
are
feature,
freeze,
correct,
right
now:
yeah,
okay,
thanks.
C
By
the
way
really
so
you
will
be
working
this
week
and
the
next
week
and
then
you're
gone
right.
So
yeah.
D
Okay,
exactly
I'll
be
working
until
the
end
of
november
and
and
I
I'll
try
as
best
as
I
can-
to
drive
the
the
sdk
spec
and
the
exporter
specs,
including
promises.
But
I
understand
that
premises
is
a
little
bit
risky
because
it
has
many
dependencies
and
we
need
to
do
a
more
prototypes.
So
I
I
think
it's
unlikely
to
get
to
stay,
get
to
stable
by
end
of
november.
For
the
three
other
exporters
like
the
console
in
memory
and
otlp,
I
think
we
will
be
able
to
make
it
for
the
isdk.
D
D
E
I
see
so
unless
you,
unless
you
prove
me
in
a
couple
of
sentences
that
we
really
need
both.
B
I
I
think,
there's
an
argument
to
be
made
that
maybe
we
don't
need
supported,
and
we
just
assume
that
you
support
both.
If
you
don't
have
preferred
and
if
you
have
a
preferred,
we
give
you
that
one
like
that.
That's
that's
a
decent
argument,
but
the
the
idea
here
bogdan
is
like
the
otlp
exporter
would
say
that
I
support
both
and
it
doesn't
have
a
preferred
or
the
preferred
is
an
environment
variable
right.
E
The
ldlp
exporter
can
return
that
value
if
there
is
a
config
that
config
can
be
done
on
the
exporter
and
the
exporter
just
returns
the
value
that
they
want.
So
I
think
I
think
in
the
end,
from
the
sdk
perspective,
it
needs
to
see
what
the
heck
I
do
for
you,
that's
it
like.
I
I
don't
need
I
need.
I
don't
need
to
resolve
a
logic
in
the
sdk
that
logic
can
be
resolved
somewhere
else.
D
Yeah
I'll
explain
so
the
there
are
exporters
like
the
in-memory
console
and
otlp
current
spec
requires
them
to
support
both
cumulative
and
dell.
So
in
this
way
they
won't
have
the
supported
equal
tool
both
so
they
will
have
they'll
have
like
support
both
cumulative
and
delta,
and
some
exporters
will
have
a
preferred
temporarily
so
the
like
oklp,
they
would
say,
I
always
prefer
cumulative.
D
This
is
already
in
the
spec
on
the
exporter,
and
so
I,
if
the
user
doesn't
specify
anything,
then
the
implementation
should
try
to
respect
the
preferred
and
there
will
be
exporters
who
don't
have
preference
they're
saying
like
I'm,
I'm
fine
with
anything.
In
this
way.
The
sdk
spec
gives
a
suggestion
that
the
sdk
should
like
if
the
reader
doesn't
have
a
preference.
D
E
So
my
point
is
about
who
is
resolving
this,
so
so
you
give
the
sdk
you
you
have
to
implement
couple
of
apis.
You
give
the
sdk
two
options
like
I
support
this,
and
this
is
my
preferred
versus
you
give
just
one
option
to
the
sdk.
I
want
data
in
this
format,
independent
and
then
and
then
the
logic
of
how
user
configured,
how
environment
variable
set
or
whatever
is
on
the
other
side.
E
So
I
think
I
want
I'm
trying
to
to
reduce
the
the
public
api
and
the
public
api
right
now
has
two
methods
which
are
very
confusing.
For
me,
it
would
be
just
a
simple
method.
What
aggregation
do
you
need
this
one,
I'm
giving
you
that?
That's
it.
D
D
Like
the
exporter,
has
the
leader
needs
that
as
well
like
imagine,
you
have
a
you,
have
something
modeled
as
a
reader
allow
exporter
to
be
modeled
as
a
reader,
and
we
allow
other
people
to
implement
their
own
reader
sure.
So,
if,
if
exporter
is
the
only
place
that
has
it
in
java,
if
you
model
the
premises,
no.
E
No,
I'm
not
I'm
not
saying
that
the
exporter
is
the
only
one
who
has
this
give
me
your
temporality.
The
reader.
Has
it
as
well,
but
has
only
one
method,
give
me
the
temporality
and
that's
it,
I'm
not
I'm
not
against
passing
the
temporality
and
the
fact
that
it's
confusing
to
have
two
methods
and
resolve
this
in
the
entity
versus
having
only
one
method
on
this
public
interface.
B
Can
can
I
phrase
this
another
way
for
riley
so
right
now,
there's
only
there's
only
two
possible
temporalities,
okay.
So
basically,
there's
only
two
use
cases
right
now.
For
these
two
methods
use
case
number
one
is
I
only
support
one
temporality.
So
actually
that's
going
to
be
my
default
preferred
like
prometheus,
where
I
say
hey
give
me
cumulative
my
supported
and
my
preferred
are
exactly
the
same
and
there's
only
one,
because
I
only
support
one.
B
I
assume
and
jack
can
tell
me
if
I'm
wrong,
if
he's
here
new
relic,
might
say
delta
because
they
want
delta
metrics,
so
they
only
support
delta
and
they
only
prefer
delta.
Maybe
they
support
you
know.
Maybe
they
do
support
cumulative.
I
don't
know
it
doesn't
matter
point
being
if
they
want
delta,
they
say
I
want
delta
and
for
the
most
part,
they're
going
to
get
delta.
B
The
where
things
get
interesting
here,
then,
is:
if
I
don't
care-
and
I
just
want
you
to
give
me
whatever
effectively-
I
don't
specify
preferred
right
and
I'll
say
I
want
either
but
like
we
don't
even
have
to
force
them
to
write
something
if
they
don't
have
a
preferred
temporality.
B
We
can
assume
that
they
support
both
in
that
case,
but
effectively
what
I've
seen
as
I've
implemented
exporters
is
either.
I
have
exact
one-to-one
matching
of
preferred
and
supported
right.
So,
if
preferred
exists,
I'm
going
to
pick
it
all
the
time
anyway,
or
it
kind
of
doesn't
matter
right.
The
the
thing
supports
either
one
so
effectively.
I
think
I
do
agree
with
bogdan
that,
basically
we
don't
we.
B
We
don't
need
one
of
these
methods
and
I
would
argue
that
maybe
we
don't
need
supported,
because
effectively,
the
only
thing
supported
is
really
saying
is
either
you
can
give
me
both
in
which
case
that
should
probably
be
the
default
or
you're
saying
like
only
give
me
this
specific
one,
which
is
really
your
preferred
right.
So
if
you
think
of
it,
that
way
of
give
me
either
or
give
me
a
specific
one.
We
only
need
one
method
to
say
that.
E
Yes,
that's
that's
exactly
the
point
because,
because
even
if
you
look
at
the
logic
that
is
right
now,
if
you
have
both,
if
you
have
preferred,
read
that
logic
and
see
how
complicated
it
is
compared
with
just
simple,
do
you
have
a
preferred
one?
No
then
I
give
whatever
I
want.
Do
you
have
a
preferred
one?
Then
I
give
you
that
before
and
that's
it
because
that,
even
if
you
read
the
logic
that
is
now
10
lines,
that's
the
summary
that
you
pointed
josh
like.
If
you
have
a
preferred.
E
E
D
E
Correct
so
so,
if
we
remove
one
of
the
method,
it's
a
breaking
chain.
So
that's
why?
I
think,
if
we
want
to
have
this
simplification,
we
should
simply
accept
the
pr
that
removes
the
the
supported
part.
D
A
D
For
for
ga,
it
is
not
required,
it
is
allowed,
so
it
just
asks
for
some
example.
Instead
of
like
the
actual
change
to
the
spec.
D
This
one
I
replied
yesterday,
I
I
think
it's
currently
covered
by
the
spike.
Maybe
we
can
have
one
example,
so
the
the
ask
is
hey.
If
you
have
a
view
that
matches
with
multiple
instruments-
and
you
happen
to
put
a
name
in
the
view
so
you're
forcing
if
there's
a
match,
then
it
should
be
renamed
to
something
else.
Then
what
do
you
do
if
you
match
multiple
streams?
D
B
Clarification
problem
where
the
way
the
spec
is
worded,
this
is
implicitly
covered
at
the
spec,
but
it's
it's
hard
to
kind
of
see
that
unless
you
actually
walk
through
the
implementation
of
your
head.
F
Yeah,
I
also
have
another
question
on
the
conflict
part.
So
what
happens
if
you
have
the
like
a
name
conflict,
but
they
belong
to
separate
meters,
so
they
have
different
instrumentation
library,
names.
D
Yeah,
I
I
think,
that's
a
very
good
question.
It's
related
to
the
permissive
thing
again,
because
we
allow
the
same
name
of
instruments
to
show
up
under
different
meters,
and-
and
this
is
like
today,
we
allow
that
in
the
isdk,
but
for
premises
we're
having
an
issue.
So
maybe
we
need
to
either
change
the
the
metric
name
or
we
need
to
add
extra
dimension,
and
there
there
are
pending
prs
for
premier
c6
caller.
B
I
have
a
stippler
suggestion.
I
actually
think
we
should
just
allow
disallow
renaming
a
view
if
you
select
multiple
instrument
types.
B
Just
straight
up,
so
if
I
try
to
select
like
a
histogram
and
a
sum
and
rename
it
to
the
same
view
either
we
need
to
allow
that
and
have
all
the
measurements
go
to
the
same
stream
and
say
that
that's
an
okay
thing
to
do,
which
we
have
not
specified
yet
and
I
think,
would
require
a
little
bit
of
fun
wording
or
we
just
say,
like
that's,
not
allowed
right
now,
and
maybe
we
loosen
that
restriction
later
with
some
specification
for
how
to
deal
with
it.
E
I
I
would
prefer
always
to
start
with
not
allowing
because
opening
more
is
backwards,
compatible
versus
doing
a
mistake
right
now,.
F
Hey:
hey
josh.
I
didn't
quite
understand
what
what
the
multiple
types
of
instruments
part
had
to
do
with
this
like?
Would
you
still
have
the
same
issue,
even
if
they
were
all
counters
that
you
were
targeting
right.
B
If
they're
all
counters
yeah
you'd
still
have
an
issue
with
conflicts
across
counters,
but
you
would
not
have
the
same
issue
with
the
prometheus
exporter
or
you
because,
because
counters
would
lead
to
you,
don't
have
the
same
type
of
measurement,
which
means
you
could
potentially
merge
those
streams
together
by
doing
label
shenanigans,
whereas
if
they're
actually
different
original
instruments,
it's
even
worse.
B
So
I
think
it's
less
of
a
solvable
issue
in
the
prometheus
exporter.
If
that
makes
sense,.
F
Yeah
that
that
makes
sense,
I
think,
I'm
just
trying
to
so
specifically
for
like
semantic
inventions.
We
say
that,
for
instance,
like
http
library
should
create
this
instrument
and
if
you're
using
multiple
hd,
http
libraries-
and
you
create
a
view,
then
you
are
going
to
run
into
this.
I
think
it's
potentially
a
common
case.
B
So
you're
saying
anytime,
you
bounce
is
yeah,
so
the
the
most
stringent
thing
we
can
do,
I'm
suggesting
the
minimum
should
be.
If
you're,
selecting
multiple
types,
we
should
disallow
rename
because
we
only
allow
rename
with
a
very
specific
name.
The
other
thing
we
can
do
to
be
more
stringent
is
we
could
say
anytime,
you
multi-select
or
do
any
kind
of
multi-select.
B
With
your
view,
you
cannot
rename
that's
the
that's
a
more
stringent
thing
we
could
take
here,
and
I
would
also
be
okay
with
that
in
the
sense
of
I
think
we
need
to
have
name
mungine.
In
the
view
api.
We
have
not
specified
that
we
weren't
planning
to
specify
it
and
we
were
planning
to
specify
it
for
v1.
B
It's
something
we
want
to
do
for
v2,
so
we
could
also
basically
outlaw
any
kind
of
view
rename
outside
of
explicit
name
match
to
explicit
rename,
in
the
view
api,
until
we
have
a
chance
to
do
something
more
clever
that
that's
that's
fine,
too,
in
the
interest
of
trying
to
minimize
scope
to
what
we
think
meets
certain
needs
now
and
fix
more
over
time,
as
we
specify
more.
That
throws
us
yet
another
bone,
but
I
think
at
a
minimum
it
should
just
be
for
multiple
types.
D
D
There
is
multiple
match
or
not,
because
the
instrument
could
come
at
any
time.
So
maybe
at
the
creation
you
don't
see
anything
then
one
instrument
and
later
another
one
come
with
the
same
name.
They
know
it's
a
problem.
So
that's
why
the
current
spec
is
more
like
a
imperative
language
way
of
like
following
a
certain
sequence.
So
you
see
the
first
one,
there's
no
conflict
and
then
you're
good
to
go.
The
second
one
has
a.
B
I
understand
what
you're
saying
we:
we
explicitly
distinguish
between
the
regex
and
the
exact
string
matching
in
the
java
implementation.
So
that's
actually
something
we
could
implement
because
we
could
know
if
the
user
is
sending
us
a
pattern.
Matchy
string
versus
a
exact
string
and
we
can
disallow
that
might
not
be
the
case
in
all
languages
and
you're
right
that
the
spec
is
allows
for
pattern,
matchy
things,
so
I
think
it's
harder
for
us
to
specify
the
second
bit,
which
is
why
the
first
one
I
definitely
am
proposing
it's
still
something
we.
B
We
could
potentially
spec
out
like
that
if
you
want,
if
you
want
me
to
take
the
language
for
that,
I
can
take
the
language
and
try
to
throw
something
together,
but
okay
yeah.
I
either
way
I
at
a
minimum.
I
want
the
first
thing
because
I
think
that's
absolutely
necessary
to
avoid
a
bunch
of
issues.
The
second
thing
I
think
we
really
do
need
to
fix
and
the
spec
in
the
next
sorry.
B
F
So
if
we
don't,
if
we
don't
do
the
second
thing,
do
we
need
to
define
a
little
more
concretely
what
a
conflict
means
like
from
this
paragraph
that
riley
pasted
from
the
spec,
but
the
conflict.
B
Is
if
you
have
yeah
I
can
I
can
do
that
as
well.
Basically,
if
you
have
the
same
metric
with
different
units
or
different
descriptions,
that's
a
conflict.
B
I
guess
here's
a
question,
though
this
is
something
we
assumed
in
the
job
implementation.
If
there
isn't
a
conflict
in
terms
of
the
the
description
or
the
units,
then
all
instruments
that
get
rewritten
to
that
name.
We
send
all
their
measurements
to
the
same
aggregator
and
we
get
one
metric
stream
out
of
it.
And
I
assume
that's
the
correct
thing
to
do
here,
based
on
how
the
specs
written
so
just
wanted
to
confirm
that
that
is
also
everyone's.
F
Understanding
that
makes
sense
to
me.
D
D
D
B
So
some
of
this
is
we,
we
adapted
an
existing
implementation
of
java,
so
he's
seen
like
there's
four
names
for
things,
because
we
we
tried
to
reuse
the
previous
name
and
we
made
a
new
name
for
the
new
thing
and
we're
slowly
deleting
the
old
name,
but
we're
just
not
there
yet,
but
yeah.
In
any
case,
there
should
only
be
inside
of
java.
B
There
should
only
be
three
three
and
three
names
that
are
not
the
four
concepts
there
is
the
aggregation
which
is
like
what
you're
trying
to
do
an
aggregator
is
an
instance
of
an
aggregation
right.
An
aggregator
is
just
like
the
function
that
does
aggregation
but
they're,
basically
the
same
thing
and
then
accumulation
is
like
the
result
of
doing
aggregation.
It's
like
what
I've
accumulated
and
that
the
only
reason
that
exists
is
like
a
fundamental
java
thing
or
how
we
do
the
calculation
it's
like.
Where
we
store
the
memory,
it's
not
it
it
does.
B
I
I
don't
think
the
spec
is
causing
that
I
think
that's
literally
just
a
java
implementation
thing.
So
I
honestly
think
this
is
more
an
issue
with
the
java
implementation
and
should
be
a
bug
there
of
hey
your
implementation's
ugly.
Please
fix
it
and
I
totally
agree.
I
want
to
fix
that
I'd
love
to
make
that
more
clear.
B
I
don't
think
that's
a
spec
issue,
but
I
want
to
hear
from
I
don't
know
who
this
is,
but
I'd
love
to
hear
if
they're
here
more
details
on
like
what
possibly
we
could
fix
in
the
spec
here,
because
I
just
argued
that
that,
like
yes,
that's
ugly
in
java,
I
know
I
wrote
it.
I
apologize
that
should
be
a
lot
more
clear.
Some
of
what
you're
seeing
is
the
evolution
from
previously
to
new,
but
it's
yeah,
I
feel
like
that's
a
java
issue,
not
a
spec
issue.
D
D
E
B
It's
in
an
international
package:
riley,
it's
in
internal.
Anything
in
internal,
is
considered
internal
in
java,
it's
public
because
of
other
reasons,
but
it's
it's
technically
anything
internal.
If
you
see
if
you,
if
you
go
back
to
that,
that
class
you'll
see
it
has
a
header
that
says
this
is
internal,
only
details
can
break
it's
not
meant
for
end
users.
D
E
E
B
Yeah,
yeah
and
and
to
be
fair,
like
when
I
first
learned
the
java
implementation
and
tried
to
get
a
handle
on
what
these
meant
it
it.
This
was
my
best
attempt
to
give
these
three
things
names
because
they
the
and
or
better
documentation,
and
I
do
think
that
it
is
hard
for
people
to
learn
it
deserves,
maybe
a
design
doc
or
something
to
help
people
understand
those
concepts
or
to
clean
them
up.
So
I
still
think
there's
an
issue
with
java,
where
you
know
people
looking
at
the
implementation
trying
to
understand.
B
Why
do
I
do
one
of
these
things?
It's
not
necessarily
simple,
and
so
that
should
get
cleaned
up
absolutely,
and
I
could.
I
could
definitely
also
agree
that
maybe
aggregation
is
the
thing
we
use
in
specification
work
and
we
reserve
aggregator
or
whatever
we
need
to
reserve,
as
a
word
sure,
but
for
the
most
part.
I
think
this
is
an
issue
in
the
java
implementation,
more
so
than
the
spec.
F
I
also
think
the
context
here
is
that
the
this
person
is
trying
to
implement
the
javascript,
metrics,
sdk
and
they're
reading
through
java.
Just
for
inspiration,
I
I
did
look
at
the
actual
sdk
spec
and
I
do
see
both
I
both
aggregator
and
aggregation.
For
the
most
part,
it's
aggregation,
like
you,
said
riley,
but
I
think
maybe
all
they
want
is
just
for
the
sdk
spec
to
to
only
use
one
or
the
other
and
then
to
call
out,
like
you
said
that
the
aggregator
would
be
reserved.
D
Yeah
I'll
do
that
and
another
question:
if
you
look
at
the
protocol,
we
have
both
aggregation
and
aggregator.
D
G
I
can
tell
you
for
sure
what
aaron
said
that
he
was
just
looking
at
java
for
inspiration
is
100.
True,
I
was
working
with
him
on
this
yesterday
and
we
were
just
trying
to
decide
what
to
name
things
and
we
were
looking
at
the
other
implementations
for
inspiration
and
it
was
confusing.
So
we
went
back
to
look
at
the
spec
and
it
wasn't.
You
know
it
was
using
multiple
terms
also.
So
that
was
why
he
created
this
issue.
B
G
He's
not
here
because
he
he
lives
in,
I
think
india,
his
time
zone
is
not
good
for
essentially
any
hotel
calls.
Unfortunately,.
B
Okay
and
if
you
need
the
detail
of
what
accumulation
is
the
java
splits,
so
so
there's
if
you
look
at
net
you're,
going
to
see
a
difference
in
aggregator
and
accumulation
in
net,
the
aggregator
actually
maintains
its
own
state
and
so
an
aggregator.
B
Not
only
does
the
aggregation,
it
actually
keeps
its
own
accumulation
of
values
in
java,
they're
split
in
in
two,
which
is
why
we
invented
new
terms
for
aggregation.
So
we
have
an
aggregator
which
is
a
stateless
interface
that
defines
a
bunch
of
methods
and
an
accumulation
which
is
the
actual
in-memory
storage.
B
And
one
of
these
things,
you
you,
you
know,
there's
an
instance
of
and
then
the
other
ones
there's
like
lots
and
lots
of
instances,
and
you
want
to
control
how
many
they
exist
and
where
they
are,
and
that
sort
of
thing
for
memory
reasons
we
made
that
split
in
java
dot
net
did
not.
B
I
don't
know,
I
don't
know
if
we
should
specify
that
I
think
that's
kind
of
more
an
implementation
decision,
and
I
don't
know,
what's
going
to
be
best
for
java,
it's
really
like
or
sorry
for
javascript
or
typescript
or
whatever,
whatever.
Whatever
is
most
comfortable
for
you
guys,
but
those
are
two
like
design
choices
you
can
have.
If
that
helps
at
all,
got
it
yeah.
I
understand.
Okay,
thank
you.
E
E
B
Yeah
we
we
are
planning
to
define
a
lossy
translation
from
o
tlp
to
prometheus,
where,
if
you
start
with
string
string
attributes,
you
preserve
identity.
But
if
you
start
with
otlp,
you
might
lose
some
aspects
of
identity
when
you
go
down
like
the
ones
that
are
suggested
here,
but
in
terms
of
otlp
the
you
preserve
those
types,
so
you
preserve
that
identity.
B
I
have
a
really
stale
outstanding
pr
on
prometheus
data
model,
questions
that
I
think
is
relevant
I'll
link
it
there
josh
mcdonald
and
I
were
kind
of
working
on
it.
It's
my
goal
is
to
have
that
done
in
december
and
out,
but
for
for
people
who
keep
running
into
this
issue,
there
is
a
good
question
here
of,
should
we
prevent
the
metrics
api
from
allowing
particular
attribute
values
to
not
exacerbate
this
problem.
B
B
We
I
I
know
from
like
our
own
metric
back
ends
if
you
try
to
use
empty
string
as
a
as
a
label
and
you
try
to
use
it
to
denote,
like
you
know,
pre-aggregated
metrics,
in
some
weird
fashion,
things
get
really
really
really
awkward.
That
is
not
something
we
want
to
necessarily
encourage
people
to
do,
but
if
they
do
it
like
we'll
support
it
kind
of
a
thing,
but
I
I
do
think
it's
worth
raising
this
question,
and
I
now
that
I
know
this
is
coming
from
javascript.
B
It
makes
more
sense
you
know
like.
Should
we
try
to
prevent
in
the
api
folks
from
using
an
attribute?
That
is
a
key
null
attribute
just
to
prevent
that
kind
of
a
problem
right
at
the
generation
point
or
not.
I
think
that's
a
that's
a
legitimate
thing
we
should
try
to
think
about,
even
though
our
data
model
supports
this.
We
know
what
identity
means
in
otlp.
B
That
doesn't
mean
that
it's
a
great
idea
for
us
to
be
generating
these
metrics
right.
So
I
I
don't
know
I
I'm
raising
that
as
a
question
here
in
the
sense
that
you
know
we
can
restrict
that
now.
I
don't
think
it
impacts
the
apis
like
dramatically
in
any
way
to
just
limit
those
values.
D
I
I
see
jobs
I
I
can
share
what
I
I
did
when
I
prototyped
the
permissions
part,
because
the
premise
is
like
mentioned
somewhere.
If
a
tag
has
empty
value
from
the
from
the
text
format,
it
will
just
be
ignored
as
if
there's
no
such
tag.
So
so
I
use
the
permissive
label
concept
and
if
I
encounter
any
attribute
that
is
an
empty
string
I'll
just
ignore
that
attribute
title.
D
B
G
Yeah
I
mean
javascript
is
really
weird,
so
there's
there's
a
concept
of
null
and
undefined
and
not
set,
so
you
can
have
an
object
that
has
a
key
with
an
undefined
value
or
you
can
have
an
object
that
doesn't
have
that
key
and
those
are
distinct
and
then
the
value
can
also
be
null
and
essentially
anything
goes
and
because
typescript
design,
you
know
it.
It
is
types,
but
it's
not
enforced
at
comp
at
runtime.
At
all,
it's
more
of
like
a
a
strong
suggestion.
G
G
Unsaid
is
obviously
not
a
problem,
because
that
just
means
the
attribute
doesn't
exist,
but
undefined
is
definitely
there
which
we
currently
treat
as
unset,
but
null
is
actually
a
value.
So
we
need
to
know
whether
we
treat
that
as
on
set
or
whether
we
like,
if,
typically
in
javascript,
the
difference
between
undefined
and
null
is,
if
you
encounter
a
null,
it
means
the
user
like
intentionally,
gave
you
nothing
as
opposed
to
undefined,
which
frequently
means
it
was.
G
You
know
whatever
the
default
value
was
or
something
like
that.
If
somebody
gives
you
null,
usually
it's
intentional.
If
somebody
gives
you
undefined,
it's
usually
just
means
that
they're
trying
to
have
something
ignored
or
unused
or
whatever
it's
a
convention
that
not
everybody
follows,
but
that's
generally
what
it
means.
B
That
that
that's
helpful,
though,
because
that
that
does
mean
like
what
riley
is
proposing
here
of
making
sure
null
is
preserved
in
some
way
makes
sense
in
that
light,
that's
all
I
wanted
to
check
yeah.
G
Well,
yeah,
but
I
think
actually,
the
specification
disallows
null
anyways.
G
Yeah
we
can
do
like
the
runtime
checks
and
just
drop
them
and
say
this
is
not
allowed,
but
then
we
have
to
determine
what
happens
right.
Obviously
we
don't
want
to
throw,
but
users
would
be
maybe
confused.
If
nothing
happens,
so
do
we
log
or
do
we
you
know,
there's
we
have
to
decide
what
to
do.
C
B
So
the
the
tl
dr
just
because
this
might
help
so
for
otlp
to
prometheus.
We
have
to
solve
this
because
the
protocol
allows
any
value
with
nothing
in
it,
which
is
the
same
as
null
right
you,
while
the
api
is
not
allowed
to
ever
create
one
of
those
things
by
spec,
because
the
protocol
allows
it
and
there's
non-api
usages
of
the
protocol.
We
will
have
to
specify
in
the
prometheus
otlp
data
model
conversion
how
to
deal
with
this
problem.
B
B
Sorry
log
like
have
a
have
a
log
that
says
I'm
dropping
this
attribute
because
it's
null
and
I'm
not
going
to
allow
it,
because
I
wasn't
supposed
to
if
you'd
rather
wait
to
see
what
what
comes
out
from
the
data
model,
spec
and
just
align
with
what
the
collector
will
do
when
it
hits
one
of
these
things
from
a
protocol
that
doesn't
come
from
an
api.
That
also
seems
reasonable.
G
Because
we're
you
know
it's
all
beta
right
now,
anyways,
so
it
can
change
in
the
future.
I
think
what
I'll
probably
do
is
document
not
drop
it
and
I'll
I'll.
Add
a
doc
string
that
no
and
undefined
are
not
allowed
and
if
you
pass
null
or
undefined
some
undefined
behavior
may
happen
and
then
that
undefined
behavior
may
be
defined
in
the
future.
G
D
G
F
B
So
so
we're
we're
following
along
with
what
the
collector
does.
But
if
you
look
at
the
preliminary
specification,
it's
just
it's
a
simple
two-string
there,
the
there
will
probably
be
a
lot
of
debate
around
doubles
more
so
than
booleans
and
booleans
and
integers,
I
think,
are
are
more
clear.
Doubles
are
where
things
get
a
little
bit
interesting
and
then
there
will
be
a
concern
around
conflicts.
B
If
you
convert
your
typed
attributes
to
string
attributes
and
you
have
a
conflict
where
you
have
two
attributes
that
were
different
types
but
the
same
name
which
is
allowed
by
the
protocol,
but
I
don't
know
if
it's
allowed
by
the
api.
I
can't
remember
off
the
top
of
my
head
that
that
will
have
some
special
treatment.
That's
basically
going
to
be
considered
a
errors
case
for
practical
reasons.
I
just
think
if
users
do
that
in
practice,
it'll
be
an
error
case
in
general.