►
From YouTube: 2022-03-01 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
D
D
Sweet
okay:
let's,
let's
start
thanks
for
joining
the
first
item
in
the
agenda,
is
json
serialization
to
hotel
data
to
profile.
C
Yep,
I'm
happy
to
provide
some
color
and
context
to
this.
If
that's,
okay,
all
right,
so
this
issue
has
been
opened
for
a
little
while
and
we
had
some
very
good
discussions
on
it.
I
think
it's
coming
kind
of
to
a
close
about
what
we're
trying
to
achieve
in
terms
of
scope
and
in
in
terms
of
of
you
know
what
this
sterilization
should
entail.
C
Now,
there's
additional
discussions
about
the
best
way
to
to
render
that
as
a
buff
model,
which
I
think
is
good
and
would
be
great
to
have,
but
it
could
be
a
separate
pr,
so
it
can
be
kind
of
you
know.
C
We
don't
want
to
tie
too
many
things
to
this
experimental
proposal,
so
we
currently
have
one
approver
who
has
accepted
this,
this
pr
looking
to
get
another
one,
and
I
believe
in
that
case
we
could
merge
this
and
open
a
new
issue
to
map
the
photo
buff
model
to
it,
because
there's
there's
more
to
to
that
of
the
discussion,
and
so
I
just
want
to
make
sure
like
you
know,
if
anybody
has
any
comments
or
anything
at
all,
please
like
bring
it
up
now.
It's
it's
a
good
idea.
C
C
Oh,
I
think,
there's
just
a
discussion
between
the
different
actors
on
the
spec,
the
best
way
to
map
it
to
a
photographer
model,
which
is
a
fair
and
very
discussion
to
be
had,
and
there
were
some
questions
out
to
bogdan,
but
I
don't
think
had
a
chance
to
reply
and
I'm
just
not
qualified.
Actually,
I
mean
you
know
to
be
honest
right.
C
I
I
don't
have
any
qualifications
about
the
best
way
to
imagine
photograph
and,
as
far
as
I
can
tell
a
lodge
this
specification
to
the
oltp,
slash
json
representation,
which
is
mapped
to
the
http
representation
right
now,
but
it
could
be
more
generic
going
forward
and
all
I
wanted
is
to
also
just
avoid
these
issues
this
pr
to
become
too
much
of
a
of
a
bigger
big
rock.
If
I
can,
that
makes
sense,
so
you
know
I'm
game
for
if
you
think
we
can
fix
and
get
to
clarity,
I'm
game
for
it.
C
But
right
now
it
feels
like
there's
just
a
few
too
many
things
to
consider
and
a
few
well-meaning
people
who
need
to
come
together
and
discuss
this
with
the
time
and
depth
that
this
requires.
B
Just
to
make
it
clear,
I
guess
probably
what
you're
saying
was
partially,
maybe
triggered
by
my
comment
there.
I
think
conceptually
what
you
have
in
the
pr
is
good.
My
comment
was
more
more
kind
of
an
editorial
right.
How
do
you.
C
B
To
the
particular
portion
of
an
existing
specification,
which
is
the
json
format,
json
serialization
format
for
otlp
from
this
part
of
the
specification
right
and
I
think
you're
completely
right
that
can
be
refined
in
a
separate
pr.
I
don't
think
that's
a
blocker
at
all.
B
Know
as
soon
as
there
is
a
clear
understanding
that
this
is
experimental
and
may
be
changed
and
we
may
break
it,
I
am
completely
fine
with
merging
it,
as
is.
C
D
Yeah,
I
think
that
one
last
thing
is
that
for
for-
and
I
agree
that
quite
often
we
want
to
do
too
many
changes
on
top
of
something
so
for
now,
probably
the
last
follow-up
once
it
gets
merged.
Is
that
just
we
feel
issues
for
the
remaining
comments,
but
you
know
so
we
don't
feel
like
any
feedback
was
lost,
otherwise
good
to
merge.
I
would
try
to
review
that
myself
by
the
way
yeah
yeah.
I
would
try
to
review
that
myself.
I
did
review.
C
D
A
couple
of
weeks
ago,
but
there
was
a
lot
of
this
question
by
then,
but
now
that
I
saw
that
digital-
and
I
don't
review
that-
and
this
isn't
confident
I
will
take-
I
will
put
the
second
pair
of
ice.
So
hopefully
we
can
get
this
merged
between
today
and
tomorrow.
D
Gotcha
all
right.
Thanks,
everybody,
perfect,
okay,
moving
forward,
then
let
me
see
it's
the.
B
D
B
Yes,
yes,
it's
kind
of
an
announcement
and
and
the
request
for
comments,
requests
for
reviews.
The
logging
seek
starting.
I
guess
we
started
last
quarter.
We
identified
the
number
of
issues
that
we
needed
to
resolve
in
order
to
declare
the
log
data
model
stable.
B
B
If
you
have,
if
you
know
anyone
who
may
have
an
opinion
about
the
log
data
model-
or
you
have
an
opinion
about
it,
now
is
the
time
to
speak
right
unless
we
hear
objections,
we're
moving
forward
and
we're
declaring
the
data
data
model
stable,
the
intent
is
to
do
it
in
march.
Probably
I
would
say
we'll
keep
it
open
for
a
couple
weeks
and
unless
we
hear
objections
and-
and
we
discover
some
things
that
we
believe
are
important
to
be
resolved,
then
this
is
happening.
Please
review
the
data
model.
B
This
is
about
data
model
only
for
now,
and
if
you
have
any
thoughts
comments
primarily,
I
guess
objections
then
then
post
there.
If
not,
then
then
we're
moving
forward.
The
next
step
after
this
will
be
finalizing
the
the
otlp
log
data
protobufs,
which
is
separate
from
this
one.
But
this
one
is
about
the
logical
data
model
of.
D
D
Sweet
next
item
is
about
instrumentation
library
being
renamed
to
instrumentation
scope.
E
Yeah,
so
I
just
wanted
to
bring
this
up
here.
There's
the
the
change
from
instrumentation
library,
instrumentation
scope,
I
think,
has
broader
impact
than
it
may
have
been
assumed
when
we
made
the
spec
change,
we're
starting
to
see
that
as
we
look
at
the
ramifications
of
the
change
to
otlp-
and
I
think,
while
the
current
stability
guarantees
for
the
otlp
data
model,
say
that
we
can
change
the
field,
names
and
method,
names
or
message.
E
Practically,
I
think,
we're
beyond
the
point
at
which
that's
appropriate
for
the
stable
data
types
such
as
traces
and
metrics.
We
have
people
that
are
implementing
constructing
these
messages
and
changing
even
even
generated
code
is
still
going
to
impact
code
that
uses
that
generated
code.
E
B
So
a
couple
points
here
anthony.
So,
let's
start
maybe
with
with
with
the
desirability,
do
we
even
want
this
change?
I
think
it's
important
to
make
sure
that
we
don't
have
a
decent
amount
of
names
right
in
in
what
is
described
in
the
specification
and
what
we
have
in
in
the
in
the
protocol.
Right,
it's
important
naming
is
important.
Are
we
allow
it
to
do
this
change
formally?
Yes,
now
the
question
is
whether
there
is
an
acceptable
way
to
handle
this
change.
B
B
I
think
we
do
see
a
way
to
handle
the
the
changes
for
json
format
in
a
graceful
graceful
way
we
can
make
the
receivers
accept
both
names
for
for
a
while
for
how
long,
however
long
we
want
it
to
be
and
for
the
exporters
maybe
have
an
option
to
double
publish
right,
which
also
solves
the
the
the
use
case
when
you
cannot
actually
make
the
receiver
accept
both
names.
B
B
E
I
think
for
this
particular
change,
and
at
this
point
in
time,
we've
done
a
review
of
at
least
public
repositories
using
the
interface
in
the
go
sdk
that
exposes
generated
types,
and
we
don't
see
any
problematic
uses
of
that
they're,
mostly
constructing
the
implementations
and
holding
the
implementations
that
are
provided
by
our
sdk.
That
will
be
updated
when
we
update
our
sdk.
E
So
the
concern
about
users
having
generating
generating
or
filling
in
these
generated
structs
is
at
least
in
public
repositories,
not
something
we're
seeing.
Presently.
My
concern
is
is
less
about
the
particular
change
that
we're
talking
about
right
now
and
more
about
the
stability
of
otlp
going
forward.
C
B
Yeah
yeah,
no,
I
I
with
that.
I
totally
agree,
I
think,
and
now
is
the
time
right,
especially
if
we
are
able
to
declare
the
logs
stable
as
well.
We're
going
to
have
three
stable
signals
essentially-
and
now
is
a
great
time
to,
I
guess,
add
more
restrictions
and
say
that
the
stability
guarantees
also
apply
to
to
the
names
to
the
json
format.
So
I
I
completely
agree
with
you
and
that
needs
to
be
done
and
sooner
rather
than
later,
I
believe
so
as
a
principle.
B
Yes,
I
think
I
agree
completely
agree
with
you.
I
I
just
would
like
this
to
be,
maybe
hopefully
one
last
change
and
I
do
not
anticipate
any
further
changes
necessary
right,
because
well,
traces
are
done.
Metrics
are
done
from
the
perspective
of
stability
of
data
model
and
then
the
format
if
logs
are
done
then-
and
I
I
don't
see
any
other
open
unresolved
issues
which
could
be
leading
to
further
mimic
changes
or
other
other
breaking
changes
in
the
generated
code
either.
B
B
D
Yeah
like
we
were
to
say
that,
from
from
this
point,
we
have
this
nuance.
Let's
say
based
on,
we
already
have
that
we
will
not
be
breaking.
The
names
is
something
that
could
be
achieved
after
this
change
and
after
the
locks
data
model
has
been
marked
stable.
Is
that
a
promise
we
could
do
the
grant?
You
think.
B
I
think
we
should
do
that
promise
how
quickly
we
can
do
that.
I
think
that's,
that's.
That's
an
open
question
right.
I
I
think
it
will
be
useful
to
to
do
the
exercise
of
going
over
all
of
the
protobufs
making
sure
that
the
names
are
proper.
Everything
is
as
we
expect.
B
If
there
is
anything
else
that
needs
to
be
done,
maybe
do
it
do
it
maybe
at
once.
Maybe
I
don't
know
right
and
anyway
I
would
say
we
can
probably
do
it
better
than
we
are
required
formally.
We
can
aim
for
for
more
graceful.
I
guess
transition,
hopefully
for
for
all
of
the
changes
that
we
need
to
do
and
once
we
do
that
pass
and
we're
sure
that
the
names
are
proper.
B
If
there
is
known,
then
then
I
can
rework
this
this
pr
to
turn
it
into
a
more
graceful
transition
where
we
don't
do
a
breaking
change,
but
rather
we
we
introduce
the
fields
as
additional
additional
fields
which
which
you
can
then
which
we
can
then
handle
in
the
collector
properly
and
in
the
sdks
as
well.
B
That's
doable,
I
think,
but
what
is
probably
not
doable
if
there
is
anything
that
blocks
a
particular
sdk
particular
language
sdk
from
like
they
are
unable
to
do
it
in
in
a
non-breaking
manner
for
the
tracing,
which
is
a
requirement
right
now.
So
if
there
is
any
seek
that
that
believes
that
it's
not
possible,
then
this
pr
needs
to
be
blocked
and
we
need
to
rethink
what
we're
doing.
I
think
what
I'm
hearing
from
anthony
is
that
that's
not
the
case
at
least
for
for
gold
right.
B
E
I
think
there
will
be
potentially
compile
time
breaking
changes
if
we
do
it,
as
stated,
but
I'm
not
aware
of
any
code
that
will
actually
break
by
that
it
would
be
non-traditional
use
of
our
sdk.
If
someone
is
doing
that,
it's
slightly
expected,
but
not
not
the
way
it's
normally
going
to
be
used.
So
I
don't
anticipate
that
there
will
be
any
changes.
I
think
if
we
were
to
have
both
fields
in
parallel,
we
would
be
able
to
do
it
without
any
breaking
changes,
even
compile
time
breaking
changes.
B
Okay
and
I
think,
to
handle
the
json
sterilization
properly
gracefully,
then
we
will
need
to
have
the
fields
in
parallel.
So
I
guess,
then,
that's
what
we
go
with
in
that
case
right
so
anyway.
Let
me
let
me
have
a
look
at
how
do
we
handle
with
with
with,
if
we
do
not
rename
the
field,
but
rather
we
introduce
new
fields.
How
does
that?
What
does
that
look
like
on
the
wire,
because
on
on
the
wire?
That
means
that
we
have
to
double
publish
in
that
case?
Otherwise,
it's
not
going
to
work
right.
B
Yeah,
okay,
but
let
me
think
I
don't
know,
I'm
not
so
sure
about
that.
So
maybe
what
we
can
do
is.
B
E
B
Okay,
so
I
guess
let's,
let's
take
this
offline
so
that
we
don't
use
all
the
time
and
I'll
post
the
comment
there.
D
D
That
makes
sense.
Thank
you
so
much
for
that.
Looking
forward!
Okay,
now
we
talk
about
metrics.
Please
really
do
you
feel
like
driving.
F
F
So
so,
if
you
look
on
the
left
side
like
this,
allow
multiple
instrument,
callback,
the
api
spec-
is
already
released
and
stable.
If
this
requires
us
to
touch
the
spike,
I
would
actually
suggest
that
we
move
this
to
a
future
release
that
doesn't
mean
we
we
want
to
stop
it
like
people
can
still
make
pr
discuss
on
that,
but
that
shouldn't
block
any
current
release.
F
Because
I
I
thought
you
marked
this
as
a
as
a
cable
release
project.
Do
you
think
you're
okay,
without
moving
it
to
a
future
release.
G
Yes,
hi,
I
did
not
mean
to
have
that
one
be
a
blocker.
I
think
the
one
we
should
be
discussing
is
linked
below.
F
Yeah
yeah,
so
my
goal
of
this
is
by
cleaning
up
this
project
board.
I
want
to
tell
everyone
here
if
there's
some
some
issue
on
this
board,
that
means
it's
a
real
blocking
issue
for
us
to
ship
the
stable
release
and
depending
on
which
section,
for
example,
if
it's
a
blocking
issue
for
the
example,
maybe
we
can
still
ship
the
version
as
a
mix
by
marking
the
example
as
feature
freeze.
F
Currently
it
seems
like
the
people
reach
out
to
me
and
and
asking
those
questions
I
I
figure,
there's
a
there's
a
we're
liking,
some
clarity,
so
you're,
okay
with
us,
marking
this
as
future
release.
Just
to
remove
that
from
the
board.
I
can
create
a
separate
board
saying
these
are
the
important
things
for
metrics.
G
Okay,
riley,
if
that
helps,
I
don't.
I
don't
see
that
being
helpful
to
me,
but
yeah.
If
you
enable
multi-instrument
callbacks
in
the
metric
api
can
be
moved
to
after
ga,
it's
not
marked
as
required
for
ga,
which
is
why
I
see
this
as
not
confusing.
The
same
goes
for
all
the
others
in
the
to
do
column.
It's
this!
It's
the
ones
that
are
in
progress
and
I
think
particularly
move
metrics
back
to
sd
to
sdk
spec
to
mixed,
which
has
a
blocker.
We
should
be
discussing
right
now,
so.
F
F
F
We
know,
but
it
seems,
there's
a
problem.
People
can
discover
minor
issues
and
I
I
I
think
I
want
to
leverage
the
time
here
to
give
everyone
clarity.
Do
we
think
this
issue
is
a
blocker
or
not
by
default?
I
I
would
prefer,
like
all
the
issues
are
not
blocking
the
issue,
but
sometimes
people
do
do
have
a
strong
opinion
and
I
want
to
make
sure
those
voices
are
heard.
D
So
no
comments,
then
I
mean
I
don't
know
like
whether
you
want
to
go
over
each
item
or
just
wait
for
somebody
to
raise
the
boys
here.
You
know
because
I
see
quite
a
few
items.
I
don't
know
what
they're
going
through
through
all
of
them.
D
H
H
I
shouldn't
speak
too
much
for
him,
but
like
he,
he
seemed
to
think
that
the
the
clarification
that
he
was
looking
for
actually
was
not
needed.
Though
I
haven't
looked
at
the
recent
comments,
so.
G
F
F
Remember
like
like,
when
we
ship
the
stable
version
of
the
trace
back,
we
have
a
friday
weekly
meeting
that
the
set,
how
folks
they
treat
all
the
issues
to
make
sure
we
give
clarity
to
everyone
which
issue
is
blocker.
Currently,
I
I
think
maybe
we're
lacking
some
clarity,
and
so
folks
don't
know
if
they
want
to
spend
energy.
Where
are
they
going
to
focus
on
that's
one
issue:
I'm
trying
to
solve
another
issue
is
the
language
isd
case.
The
themes
like
for
java
javascript
and
go
they're
still
in
progress,
so
maybe
we
can.
H
G
D
Yeah,
sorry
friday,
I
remember
correctly
used
to
work
well
for
a
lot
of
people
like
we
didn't
have
so
many
meetings.
So
let's
try
that.
I
F
H
I'm
sure
yeah
I
can.
I
can
talk
so
yeah.
This
is,
it
might
be
a
minor
one.
So
this
came
out
of
a
conversation
with
the
folks
from
the
dot
net
sig.
We
have
the
ability
to
basically
automatically
configure
a
metric
reader
by
when
you
choose
which
exporter
you
want
to
use.
H
H
So
this
raised
the
question
of.
Should
we
declare
a
default
metric
reader
type
for
that
should
be
paired
with
these
push-based
exporters
at
the
spec
level,.
H
And
should
it
be
periodic,
that's
that's
the
the
initial
stab
that
I
put
into
this
pr,
but
if
not
periodic,
then
I
guess
the
question
becomes
what.
G
To
me
there
was
never
really
a
question
I
mean.
I
think,
that
that
this
manual
reader
is
not
something
we
specified,
or
at
least
I
wasn't
aware
of
it,
and
it
does
sound
like
something
that
some
optional
use.
You
know
you
might
find
an
optional
use
for
this
when
you're
customizing,
something
but
like.
G
Does
anyone
realistically
expect
to
to
configure
an
exporter
through
an
environment
variable
and
not
get
that
type
of
behavior?
I
doubt
it
so
I
would.
I
would
call
this
minor
and
say
yes,
but
I
I
was
waiting
for
you
to
describe
it
in
person,
because
I
didn't
quite
understand
why
I
was
needed
either.
H
Riley,
if
you
recall,
I
think
it
was
it
was
a
number
of
months
ago.
Things
have
changed
around
quite
a
bit,
but
there
was
you
were
posing
some
questions
about.
I
think
in
the
context
of
the
console
exporter
thinking
that
maybe
periodic
would
not
be
desirable
because
you
were
invited
envisioning,
some
interesting
use
cases
where,
like
maybe
maybe
there
was
an
interactive
kind
of
application-
that
yes.
F
Yeah,
so
so
here's
my
consideration
depending
on
the
type
of
the
application.
If
it's
a
service,
I
can
definitely
see
the
the
usage
of
periodic
if
it's
a
command
line
tool
that
runs
for
three
seconds
and
quickly
exit,
the
periodic
seems
to
be
less
useful.
So
my
my
question
at
the
time
for
the
donut
console
exporter
was
mainly
around
what's
the
proper
variable
and
it
seems
we
don't
have
a
good
understanding
if
by
default
we
use
one
minute.
I
would
say
one
minute,
probably
works
better
for
otlp
for
something
but
for
console.
F
My
understanding
is
it's
a
very
interactive
thing
for
developers
to
see
the
output
in
a
near
real-time
manner.
So
my
question
was:
do
we
think
that,
like
we
have
a
good
understanding
about
the
scenario
and
the
interval,
if
we
don't,
then
let's
don't
put
any
interval
there.
We
ask
the
developer
to
explicitly
put
the
interval
that
they
expect
in
their
code
and
once
we
have
a
good
understanding
we
can.
We
can
introduce
the
default,
which
is
an
additive
change
instead
of
a
breaking
change.
G
Hope
that
gives
some
context,
so
so
your
concern
really
is
what
the
default
interval
is
not
whether
it's
periodic
paragraph
exporter
yeah.
I
mean
your
example.
Didn't
sound
too
too
concerning
to
me,
if
you,
if
you
are
a
command
line
application
and
you
set
up
a
push
interval
and
the
default
is
one
minute
or
15
seconds
or
whatever
seems
reasonable,
and
you
exit
after
three
seconds.
You
should
shut
down
and
flush.
Your
metrics
and
you'll
see
them
after
three
seconds.
Nobody
will
nobody
will
care
exactly
so.
Could
we
decide.
H
H
F
G
Yeah
I
would
like
to
spend
a
moment
on
here,
because
I
think
I
mean
I've
been
triaging
these
issues
every
week.
Personally,
I
hadn't
I've
seen
all
of
them,
and
I
think
that
the
only
I
mean
we
really
should
be
discussing
this
one
here
and
now.
Okay.
So
if,
as
far
as
I'm
concerned,
this
is
the
only
blocker
that
we
really
need
to
settle,
given
what
I've
seen
so
just
to
because
riley,
could
you
click
into
the
blocker
issue
yeah?
G
G
When
I
first
read
the
the
issue
I
felt
like
it
was
just
asking
to
clarify
the
text
and
when
I
finally
studied
it
in
depth,
I
realized
that
it
was
actually
asking
to
clarify
something
about
composing,
multiple
readers
and
or
exporters
with
sorry,
one
reader
and
or
exporter
with
multiple
providers
that
is
sort
of
a
buried
in
the
text
of
the
description
in
the
issue.
But
it
comes
in
to
be.
G
It
comes
to
be
the
most
important
part
of
this
topic,
so
at
first
I
don't
see
a
problem,
but
second,
it's
calling
for
us
to
specify
what
happens
and
shall
the
sdk
support,
say:
multiple
exporters,
multiple
providers
per
exporter
or
multiple
providers
per
reader
and
I've.
Given
a
lengthy
explanation
for
my
opinion
here,
I
want
us
to
try
to
resolve
this
issue.
G
To
me,
the
the
the
conclusion
that
I
reached
is
that
there's
there's
no
right
answer
to
this
question
of
whether
the
sdks
should
support
multiple
providers
per
exporter.
G
How
can
I
with
a
running
sdk,
erase
submetrics
from
runtime,
and
we
haven't
given
a
way
to
do
that,
and
I
think
we
probably
shouldn't
give
away
to
do
that.
But
one
way
to
accomplish
that
goal,
which
was
described
in
2232,
is
to
create
one
meter
provider
every
time
you
want
to
create
some
new
module
and
then
delete
that
meter
provider
by
shutting
it
down
after
you're
done
now.
G
That
way,
the
exporter
can
forget,
metrics,
because
the
meter
providers
disappeared
and
the
requirement
is
that
the
exporter
is
never
going
to
be
responsible
for
aggregation.
It's
the
meter,
reader,
that's
responsible
for
aggregation
and,
and
the
outcome
of
that
is
that,
if
you
are
a
user
who
wants
to
do
this
crazy
connection
of
multiple
providers
to
one
exporter,
it's
your
responsibility
to
prevent
single
writer
rule
violations.
That's
that's
all
I'm
saying
here.
I
believe
we
could
resolve
this
issue.
That
is
complicated.
F
G
F
F
Yeah,
but
I
I
would
say
this
is
not
a
problem
because
we
don't
even
want
to
support
an
exporter
being
shared
by
multiple
providers
that
never
happened
for
traces
and
by
default.
I
wouldn't
support
that
in
matrix.
If
you
see
a
problem,
describe
your
problem
and
see
how
we
can
give
some
recommendation,
but
don't
assume
an
exporter
will
be
shared
among
multiple
providers.
This
gives
additional
benefit
that
for
long
stresses
metrics
they
have
some
consistency.
F
J
J
F
Is
that
possible
to
to
do
this
as
a
special
logic
in
the
premier
36
partner,
for
example?
I
can
imagine
one
scenario.
Is
we
just
tell
people
in
this
way?
We
don't
support
that.
If
you
want
to
export
to
premises,
you
can
have
multiple
exporters
binding
to
different
endpoints
and
configure
your
scripter
to
reach
out
to
multiple
endpoints
and
people
are
saying.
Oh,
it's
a
show.
Stopper.
G
F
I'm
not
saying
doing
the
matrix
pre-aggregation,
I'm
saying
the
the
underlying
transport
once
it
receives.
Some
scraper
call
it
it
understands.
There
are
multiple
permissive
exporters
and
it
can
collect
all
the
results
from
those
exporters
and
and
respond
with
a
combined
result.
I
mean
this
can
be
a
special
treatment
in
the
permissive
exposure.
Implementation,
not
necessarily
touch
the
sdk
design.
G
G
Though
I
mean,
if,
if
we
just
embrace
this
and
say
an
exporter
can
share
multiple
readers,
then
the
prometheus
will
go
once
it
gets
to
its
request.
It
will
go
to
each
reader
and
it
will
read
through
each
reader
and
it
will
dump
the
output
into
the
connection,
and
the
condition
I'm
worried
about
is
the
user's
fault.
If
they
do
that,
which
is
to
say
that
they
produce
the
same
stream
from
multiple
sdks,
your
fault,
your
prometheus
is
going
to
see
the
same
stream
twice.
F
Yeah,
I'm
I'm
concerned
about
the
spike,
giving
giving
some
hint
that
we
want
exporters
to
be
shared
the
current
tracing
spec.
I
I
I
never
said
anything
about
exporter
being
shared
and
in
open
time,
36
plus
plus.
I
remember
people
started
by
making
the
assumption
that
exporters
can
be
shared.
They
did
the
reference
counting
and
then
they
have
other
issues
and
eventually
I
I
I
think
the
direction
is.
We
want
the
exporters
to
be
solely
owned
by
the
provider.
G
I
guess
I
don't
see
why
the
exporter
needs
to
be
owned
by
the
provider.
In
any
case,
this
original
issue.
Here
there
are
two
original
issues
here.
One
is
saying
it's
not
clear
who
owns
what?
In
other
words,
if,
if
the
provider
owns
the
reader
or
the
or
or
the
exporter
owns
the
reader,
we
can
resolve
that
here
without
necessarily
commenting
on
whether
multiple
exporters
are
required.
Yeah.
My
proposal
is
that
the
meter
provider
owns
the
reader
there's
one
to
one
between
meter
providers
and
reader.
G
G
Multiple
sdks
ought
to
be
able
to
share
that,
but
but
there
are
differences,
of
course,
if
you're
pulling
from
multiple
meter
providers,
you're
going
to
end
up
seeing
all
the
data
in
one
place
and
if
you're
pushing
through
the
same
exporter
from
every
sdk,
it's
going
to
be
independent,
you're,
going
to
end
up
pushing
through
the
same
connection
but
they're
not
going
to
be
synchronized.
G
I've
thought
through
this
all
it
doesn't
seem
to
create
any
problems,
at
least
in
any
case,
the
the
position,
the
the
request
was
to
clarify
the
ownership
semantics
and
then,
in
my
opinion,
this
request.
2232
is
still
looming
and,
if
you
read
through
it,
it's
because
we
were
trying
to
integrate
the
micrometer
in
java
and
micrometer
is
being
called
out
is
extremely
important
here.
If
we
can't
support
the
micrometer
uses,
we
might
not
be
done,
and
my
solution
proposed
for
this
issue
also
solves
that
issue.
That's
the
reason
why
I
like
this
proposal.
F
G
I
see
2232
is
close
to
believing
a
blocker.
It
was
certainly
held
up
for
the
reason
behind
2317,
but
it
didn't
solve
the
issue.
2317
didn't
solve
this
entirely.
G
Can
be
I
it's
the
other
issue,
that's
not
clear
the
spec
yeah.
What
happens
when
you
combine
multiple
readers
for
one
exporter?
That's
just
really
unclear
right
now,
and
I
want
to
make
sure
that
we
clear
clarify
that
in
any
case,
there's
a
one-to-one
between
readers
and
meter
providers
and
exporters
do
not
aggregate.
That's
you
don't
have
to
say.
G
G
If
you
roll,
if
you
scroll
down
just
one
page
riley,
you
can
see
my
proposal.
I
th
these.
These
are
the
bullet
points
that
I
would
write
to
solve
this
issue
and
2232.
F
G
Those
are
the
ones
asked
from
2232.
Yes,
my
rationale
for
choosing
this
proposal
for
this
issue
is
that
it
also
salts
from
h32.
F
G
K
Yeah,
I
I
think
point
one
does
solve
the
the
issue
here
again.
This
is
one
of
the
javascript
maintainers,
that's
in
asia,
and
can't
attend
this
meeting.
But
I've
spoken
with
him
about
this
issue
and
I
think
he's
not
looking
to
like
implement
the
multiple
sdk
situation
he's
just
as
a
maintainer
wondering
how
we
should
handle
that
and
whether
we
need
to
support
it.
I
think
it's
more
of
a
almost
a
documentation
issue
more
than
a
technical
issue
for
him.
G
And
I
think,
maybe
that
that
leads
lingering
confusion,
which
is
that
the
metric
reader
may
be
created
through
a
factory
as
a
result
of
this
pattern,
which
is
something
jack
had
commented
on
above
in
the
same
thread
and
that's
fine,
I
mean,
I
think
it's
a
language
level
concern
how
you
set
this
up,
because
readers
might
need
to
be
bound
after
you
create
your
writer.
G
F
Yeah,
I
I
think
that
on
the
the
first
one
great
appreciate
it,
okay,
I
guess
that's
all
so.
I
F
H
G
Good
question
yeah
that
one
I
don't
know,
I'm
I'm
open
to
considering
that
to
be
a
clarification
or
a
future
change.
I
have
not
had
the
chance
to
catch
up
with
that
issue.
It
seemed
like
it
was
lower
priority
to
me.
H
G
Yeah,
as
I
recall
last
week
this
at
this
time,
we
decided-
we
were
gonna
think
about
this
issue
for
a
week,
and
I
don't
know
if
anyone
has
any
new
thoughts.
I
I
I
was
on
vacation,
so
I
don't
have
any
good
thoughts.
If
there
is
something
you
think
we
could
do
to
make
it
sort
of
acceptable
for
ga
and
solve
it
later,
then
that's
what
we
should
probably
do,
and
maybe
that
means
just
specifying
cumulative
for
now
and
having
no
way
to
choose
delta.
That
would
be
okay,
perhaps.
G
C
G
Thinks
it's
interesting
frankly,
light
step
has
a
third
preference
that
I
don't
even
want
to
talk
about
right
now,
which
is
only
deltas
for
synchronous
instruments,
meaning
for
the
counter.
Only
because
that's
the
one
that
you
save
a
lot
of
memory
on
and
and
there's
no
reason
to
spend
extra
memory
to
convert
cumulative
asynchronous
counters
into
deltas.
That's
not
useful
to
us
just
extra,
but
I
don't
want
to
delay
this
conversation.
I
would
be
happy
with
just
cumulative
or
the
one
that
didn't
trace
the
new
relic
wants,
which
is
just
monotonics.
F
Delta
yeah,
I
mean
we're
not
saying
by
default.
We
want
people
to
do
the
cumulative
to
delta
conversion,
we're
saying
we
give
people
an
option
and
later
we
can
give
people
better
options.
That's
not
a
blogging
issue,
we're
saying
we
gave
you
two
options.
Maybe
that
option
today
is
not
ideal
well,
but.
G
F
G
F
G
F
G
F
F
We
never
see
this
is
enforced
right
because
the
user
cannot
enforce
the
back
end.
Whatever
the
user
say,
the
backhand
has
the
right
to
refill,
refuse
that,
because
it
simply
cannot
support
it.
Even
for
even
for
cumulative
the
backhand
can
say.
I
don't
support
any
cumulative,
I'm
going
to
do
something,
I'm
going
to
drop
your
data.
It
is
the
freedom
of
the
explorer
right.
G
G
G
G
So
if
I
set
up
an
exporter
to
light
step,
I
actually
only
want
my
counters
to
be
converted
to
deltas
and
that's
a
preference,
that's
different
than
any
of
the
ones
we're
discussing
right
now,
and
this
is
why
I
wrote
in
that
that
you
should
have
a
preference
which
is
like
basically
a
five-way
choice
for
any
of
the
instruments
that
have
a
temporality.
The
exporter
can
choose
and
that
way
I
could
plug
in
my
particular
different
preference.
That's
not
the
same
as
anyone
else's,
and
I
don't
need
to
have
a
name
for
that
preference.
G
I
just
have
a
hook
which
I
would
be
happy
with,
but
then
the
conversation
moved
towards
having
two
named
preferences,
maybe
that
you
could
set
by
an
environment
variable
that
would
not
be
the
same
as
the
hook
and
the
two
named
preferences.
I
just
want
to
make
sure
that
those
are
useful
preferences
and
I
don't
believe
that
the
one
that
always
delta
is
going
to
be
make
anybody
happy.