►
From YouTube: 2020-06-16 Spec SIG
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
A
B
B
B
B
B
B
B
E
C
C
H
F
By
the
way,
tip
tip
is
still
sick
on
her
side,
so
he
will.
He
will
not
be
joining
us,
but
yeah
and
I
see
that
he
had
a
few
items
that
he
left.
We
can
talk
about
them,
probably
without
him
anyway.
I
also
see
only
three
attendees
in
the
list.
So
add
yourselves,
please
we
have
a
few
items,
which
is
great.
Actually
we
have
a
10
910
item
so
yeah.
So
let's
start
in
one
minute,
so
we
have
more
time
to
try
to
go
through
all
of
them.
I
F
I
So
I'm
here
I
can't
talk
about
this,
so
I
mean
Carlos.
You
were
a
number
of
people
here
were
at
the
maintainers
meeting
last
week.
So
as
many
people
in
open
telemetry
know,
we've
started
the
GA
planning
process.
We're
going
to
start
this
with
the
spec
SIG's,
because
we
need
the
specification
to
drive
the
features
for
each
of
the
language
SIG's.
So
starting
this
week.
I
I
want
us
to
draft
up
a
list
of
the
features
that
we
think
that
we
need
for
GA
that
either
in
progress
and
incomplete
or
just
we
haven't
started
yet
I
saw
jaws
joined.
We
did
a
similar
exercise
in
the
metrics
spec
last
week.
We
just
need
to
do
the
same
exercise
in
a
sig
for
the
tracing
spec
and
any
other
specs
that
we
think
are
in
scope
for
GA
I.
You
know
for
for
metrics
I've
been
attending
that
one
for
a
while,
so
I
actually
had
somebody.
I
I
J
I
think
we
started.
Last
week
we
had
a
meeting
with
Andrew
about
classifying
a
bunch
of
the
issues.
Yeah,
we
haven't
got
to
the
point
of
drawing
the
line.
What
is
oil
versus
what
is
not
required
in
G,
but
at
least
we
we
clustered
the
issues
in
two
different
areas
in
different
parts
of
the
whatever
unit
influence
and
stuff.
So,
okay,
to
answer
your
question,
we
don't
know
yet,
but
we
are
working
on.
C
I
C
A
I
J
F
Trying
to
retake
your
question,
Morgan
I
would
say
that
we
don't
know
exactly
you
know
what
shoes
but
I'd.
Imagine
a
few
important
sections.
Like
aside
metrics,
we
need
to
work
on
error
reporting.
You
know
there
are
a
few,
a
few
PRS
and
issues
around
that.
So
that's
one
of
the
things.
Then
we
have
Jamal
configuration
and
sampling.
Those
are
probably
some
sugar
on
our
certifications
or
improvements
on
context.
Propagation.
Those
things
are
the
important
things
that
come
to
encode.
J
J
We
stick
with
these
name
or
we
go.
So
that's
wonderful
thing,
maybe
maybe
asking
about
this-
maybe
see
for
that
to
finalize,
because
nobody
really
looked
into
that
very
very
carefully.
There
are
a
bunch
of
issues
related
to
correlation
context
and
I
think
we
should.
We
should
put
some
more
attention
and
effort
into
that.
Okay,.
F
H
One
suggestion,
so
is
that
possible,
for
this
group
of
people
to
at
least
agree
on
a
list
of
open
issues
that
we
have
to
resolve
for
spec
version
1.0.
So
once
we
have
the
list
we
can
stay
like
like.
We
believe
these
are
all
the
issues
we
want
to
close
before
we
announce
the
first
1.0
back.
Anything
else
will
be
inspect
to
point
0
or
something
yeah.
That's
what
I
was
getting
it
yeah.
That's.
H
C
C
Logging,
but
if
that's
not
the
block
at
one
point
but
not
for
trace,
there's
like
sixty
three
open
issues
like
all
right.
Maybe
we
need
to
also
break
that
down
which
ones
are
possible
and
there
we
also
need
to
finish
tagging.
Something
like
we
got
like
how
many
on
correlation
context,
labeled
only
one
issue
in
correlation
context,
but
if
you
do
a
search
for
no
correlation
context
like
you'll,
see
that
there's
like
five
or
six
more
issues
on
that.
C
So
we've
got
to
finish
that
labeling
as
well,
then
we'll
get
the
big
groups
of
the
things
that
we're
like.
Alright,
let's
draw
the
line
here
and
see:
that's
what
we
got
to
do
in
a
move
in
order
to
bring
that
in,
but
I
mean
in
the
meantime,
I
can
be
safe
to
assume
if
we
got
some
issues
during
talked
about
at
this
meeting
its
relate
to
trace
and
it's
important.
We
should
go
at
it
because
we
want
to
get
the
trace.
1.00,
GA,
yeah,.
C
I
I
A
E
C
C
We
then
dive
deeper
into
the
specifics
of
may
be
tracing
unless
we
can
also
go
in
that,
but
like
at
least
the
grouping
of
that
this
week,
so
I've
yet
to
schedule
a
calendar
time,
today's
Tuesday,
so
it's
Wednesday,
Thursday
Friday
one
of
those
times
that
I'll
need
at
least
Bogdan
Carlos
Riley
would
weather
that
can
also
Riley
can
also
help
with
that,
but
to
be
able
to
bring
that
to
fruition
by
the
end
of
this
week.
So
that
way
by
the
next
spec.
H
And
one
one
more
question:
so
are
we
also
in
agreement
that
we're
not
in
to
accept
you
propose
to
this
bag
so
starting
from
Temple
from
today
or
later,
like
Friday,
we're
saying
any
new
ask
that
requires
a
change
in
this
bag
will
be
in
a
2.0,
because
my
var
is
like
people
will
realize.
Oh,
this
is
the
last
minute.
I
want
to
make
something
different.
All
of
a
sudden.
We
start
to
have
a
lot
of
new
issues.
H
F
D
C
Maybe
I
should
clarify
like
what
the
context
of
this
120
issues
are.
That
I
mean
to
bargain
point
like
100.
Training
issues
are
what
we
have
filed
right
now.
There
could
be
other
issues,
that's
like
there
hasn't
been
filed,
yet
that
Riley
may
be
alluding
to
a
John
IV
ruling
to
across
our
communities.
It's
like.
Oh,
we
need
something
else
to
be
able
to
get
this
to
one
point:
oh,
that's
not
gonna
be
dumb.
It
and
I'm,
not
tracking
that
within
this
week,
but
yeah.
A
C
K
Like
perhaps
Riley's
concern
is
getting
additional
structure
around
adding
new
requirements
between
now
and
hitting
1.0.
So
we
say:
okay,
these
are
the
things
we
know
we
need
to
do.
There
may
be
additional
things
that
have
to
come
in,
but
we
need
to
make
sure
that
we
can
triage
between
what
needs
to
happen
before
you
know
and
what
can
happen
after
yeah.
That's
correct,
yeah.
H
And
probably
add
a
signal
at
someone
to
say
like
we're
not
trying
to
stabilize
this
fax
we're
not
going
to
accept
any
new
ask
for
the
Twitter
API
by
default.
It
would
go
through
to
ponder
off
but
for
matrix
API.
We
give
additional
like
three
weeks
for
people
to
like
ask
something
in
the
last
minute.
I
C
That
it
would
help
if
we
had
like
a
general
statement
similar
to
what
we
had
for
I,
like
proposals
similar
to
what
we
had
for
beta
was
like
we're
having
at
one
point.
Oh
we're
expecting
certain
things
to
be
complete,
not
complete.
So
that
way,
people
can
understand
that,
yes,
if
they're
going
to
propose
something
bug,
fixes
should
be,
of
course,
be
the
thing
to
go
in
at
Balki's.
C
If
you
say
you're
gonna
be
walking
down
on
the
tracing
like
there's
a
problem
here
we
got
to
do
this
or
correlation
contacts
or
whatnot,
whatever
we
choose,
but
also
knowing
that's
like
well,
logging
is
not
it.
Logging
is
not
to
be
part
of
it.
It's
some
new
fandangled
things
coming
is
like
no
there's
not
a
chance
to
throw
in
a
wacky
new
feature.
That's
been
sitting
in
someone's
brain
if
they
want
to
get
in.
That
would
be
out
of
scope
as
well.
C
I
So
I'm,
guessing
that
the
logic
for
this
is
like
any
bug,
fixes
or
clearly
required.
Spec
behavior
still
comes
in
to
1.0,
even
if
it
comes
in
hot,
like
I
can
imagine
like.
Even
after
our
first
release
candidate
we've,
we
discovers
something
as
unspecified
across
the
the
SDKs
and
we
need
to
go,
specify
it
and
implement
it
cleanly,
and
so
that
goes
into
1.0.
I
Meanwhile,
new
features
logging,
for
example,
it's
probably
the
biggest
one,
but
there
will
be
smaller
ones,
new
features
that
are
not
going
to
make
to
meet
the
GA
date,
but
don't
introduce
breaking
changes.
Those
will
go
in
1.1
or
1.2
or
1.3
and
breaking
changes.
Where
someone
comes
in
and
says
hey,
we
should
completely
rethink
how
we
do
tracing
your
metrics.
That's
the
to
point
over
later.
That's
a
you
know,
a
major
breaking
change,
I
assume,
that's
the
logic.
We're
going
to
use
yeah.
C
I
I
think
we
call
it
so
here's
what
I
think
we
should
do.
Andrew,
Boggs
and
Carlos
like
you've
gone
this
week,
keep
categories
categorizing
all
the
issues
we
have.
We
should
either
as
part
of
your
exercise
or
early
next
week
for
things
that
we
know
we're
missing
right
for
things
that
we
know
we
need
to
get
done
before
they
are
Caesar.
Ga
is
just
and
don't
already
have
issues
for
them
great
issues.
For
just
saying
this
is
a
tracking
issue
because
we
need
week.
I
We
know
that
we
need
to
finish
the
correlation
context,
work
and
rename
it.
We
know
need
to
do
these
things
related
to
it
and
just
open
that
as
a
ga
issue.
If
there's
not
one
already,
and
so
then
we
can
at
least
get
issues
just
tracking
all
the
things
that
need
to
be
done.
Even
if
it's
just
some
design
work
look
even
if
we
haven't
started
yet.
Let's
just
get
an
issue
open
so
that
we
can
follow
it
and
then,
ideally,
we'll
have
called
out
all
the
things
we
need
to
do.
I
C
A
C
J
I
think
we
definitely
need
help
from
people
to
identify
some
of
these
things.
We're
gonna
be
able
to
categorize
and
stuff,
but
after
that
we
need
some
people
to
help
us
with
identifying.
If
we
need
something
we'll
put
our
best
in
advance
ourselves,
bunch
of
issues,
but
most
likely
we'll
miss
things.
Yeah.
H
F
Okay,
so
let's
move
to
the
next
item,
then
tear
well
she's,
not
here
meeting
times
for
new
working
groups
added
to
the
calendar
and
errors,
Thursdays
8
a.m.
Pacific
and
something
Friday,
9:00
a.m.
okay,
so
yeah
that
that's
actually
a
very
good
thing,
because
this,
as
I
mentioned
this
I
think
this
is
T,
started
to
two
of
the
important
sections
that
we
still
need
to
wrap
up.
F
H
We
figure
out
like
in
several
expec
or
like
even
the
cold
class
name
or
configuration
people
use
sometimes
the
years
old.
He
sometimes
to
use
hotel
so
I
wonder
if
there's
a
standard
way,
at
least
with
documents
in
the
spec
or
somewhere,
to
give
people
guidance.
Otherwise,
people
just
invent
like
their
own
names,.
F
I
H
H
I
C
I
F
F
Perfect,
so
yes,
then,
excited
then,
is
Morgan.
Should
the
goals
for
context
formats
in
store
in
the
SDK
repose
yeah?
This.
I
Is
just
a
quick
question
and
it
may
have
already
been
decided,
so
forgive
my
ignorance.
So
there
are
some
parts
of
Nigeria
cific
of
exporters
where
we
said
these
should
not
be
stored
in
the
main
open,
slow,
mature
repos.
They
should
be
stored
in
vendors,
private,
repos
or
in
contribute
to
contribute
post
and
I.
My
understanding
and
please
correct
me
if
I'm
wrong
is
for
resource
information
so
for
four
components:
probe
open
telemetry
that
can
determine
like
what
ec2
instance
they're
running
on
or
something
like
that.
I
I
Context
format,
yet
I
was
saying,
like
I'm,
just
trying
to
understand
my
mental
model,
so
exporters
that
are
vetted
specific,
don't
live
in
the
main,
open
share
and
repos
resource
API
is
things
that
can
can't
determine
like
what
VM
they're
running
on
in
Azure
or
AWS
I
think
do
live
in
our
main
repos
again
correct
me
if
I'm
wrong
and
similarly
my
question
was
for
context
formats.
So
certainly
we
support
b3
and
w3c
natively,
but
for
like
the
Amazon
context,
format
or
the
old
Google
one
that
will
be
going
away
soon,
but
hasn't
yet.
I
I
I
kind
of
figured
I
kind
of
assumed
they
would
be
in
the
main
repo
because
there's
only
like
four
of
them
really
and
your
people
like
it
might
be
the
case
that,
like
New,
Relic
or
Splunk,
customers
have
to
use
them
in
certain
circumstances,
so
they're
not
really
tied
to
backends,
but
I.
Don't
really
have
an
opinion
I.
Just
we
have
a
team
who
wants
to
go
implement
this
and
they're
just
asking.
Where
should
I
put
the
yes.
H
All
right
people,
okay,
come
collect
if
you
take
the
Python
masks
and
they
have
specific
headers
and
doing
that
with
like
GCP
or
ews.
Adder
is
just
similar
to
that.
What
we
have
to
put
outside
this
room
is
the
vendor
specific
exporters,
because,
yes,
the
integration
has,
we
need
someone
who
have
specific
knowledge
about
the
backend.
Yes,
I've
acted
like
I,
probably
need
to
have
a
credit
card.
Buggy
P,
double
yes,
yes,
common
core,
like
holiday,
in
how
we
interact
with
AWS
specific
header.
This
part,
I,
believe,
is
well-documented.
I
see
this.
J
I
J
Sorry
don't
hate
so
my
argument
stands
only
for
younger
beat
three
and
the
cloud
ones
like
x-ray
DCP
if
I
short
as
wine.
Sorry,
my
ignorant
suddenly
have
their
own,
but
this
will
be
probably
the
least
of
propagators
that
I
would
be
willing
to
support
in
terminating
in
the
correct.
So
to
answer
your
question:
I
think
we
we
have
to
make
a
decision
and
we
have
also
to
document
a
full
list
of
propagators
that
we
are
willing
to
support.
F
This
way
system
that
I
wanted
to
say
that
we
should
definitely
even
note
on
the
issue
degenerative
and
have
somebody
cook
up.
We
are
to
start
exploring
what
sections
you
know
need
to
be
added
and
what
kind
of
propagators
we
want
to
support.
Otherwise
we
will,
we
will
come
to
an
agreement
here
and
they
will
forget
to
add
that
to
the
specification.
F
I
Quick,
we
became
in
Australia,
people
have
met
them,
they're,
mostly
working
the
collector
they're,
about
to
start
working
on
the
SDKs
we've
also
hired
a
new
engineer.
There
I
was
wondering
if
we
could
start
rotating
the
spec
meeting
times
between
this
time
of
the
morning
and
then
a
time
in
the
afternoon,
so
that
they
could
start
ascending
that
at
the
moment,
they're
just
not
able
to
attend
any
to
the
spec
meetings.
They
can
attend
the
metrics
spec
meetings
because
those
rotate,
but
not
this
one,
I.
F
I
Make
most
of
the
sakes
now
rotating
between
times,
Christine
our
equator
team
in
Australia
they're,
certainly
not
the
only
contributors
in
the
Asian
Pacific
time
zones.
This
is
just
one
of
the
few
meetings
that
hasn't
started
rotating
yet
some
of
the
team
members
there
it
reached
out
just
because
they're
not
able
to
attend
it,
they
would
like
to
okay.
Well,
do
you
think
we
should
have
a
second
one
of
these
one?
No.
F
C
A
I
F
J
I
It's
it's
more
than
observe
I
mean
we're
gonna
be
putting
the
videos
on
YouTube
I.
Think
Sergei
is
all
over
that,
but
I
they
just
assumed
they'd
have
spec
issues
that
would
be
coming
up
and
you
know
I
can
try
and
represent
those
the
best
of
my
abilities
but
they're
the
people
actually
writing
the
code.
It's
a
lot
easier.
If
they
do
it.
I
F
I
J
Just
half
an
hour
and
see
how
it
goes,
I
mean
this
is
nothing
fixed
in
stones
or
anything.
It's
just
like.
Let's
start
with
something
and
see
how
how
much
we
need-
or
we
don't
need
for
this-
yeah,
okay,
probably
starting
with
next
week,
because
we'll
be
a
very
short
notice.
People
will
not
wake
up
at
4:00
equivalently.
If
you
don't
know
in
advance,
yeah.
I
F
J
F
Yeah
I
agree,
I
agree
with
their
that's
way
bigger
and
it
has
more
discussion
going
on
there
yeah,
okay
yeah,
so
that
is
the
number
seven
is
way
more
important
than
six.
Six
is
Molly.
No
six.
We
should.
We
should
be
able
to
merge
it
after
you
take
a
look
down.
It's
small
enough
for
seven
yards.
What
be.
G
And
yeah
have
a
little
bit
of
a
discussion
about
it.
There
was
recently
a
PR
to
add
both
array,
values
and
map
values
for
four
attributes
that
was
merged
to
the
collector
and
as
that
PRI
was
coming
through
I
kind
of
revisited
this
issue
and
started
thinking
about
it
a
little
bit
more
and
like
on
the
surface.
Everything
seemed
okay
to
me
about
it,
but
as
I
started
to
think
it
through
I
started
to
come
up
with
some
reservations
about
adding
this
mainly.
G
This
seems
like
a
lot
of
work,
so,
if
you're
exporting
to
like
Zipkin
or
Jaeger,
for
example,
you're
gonna
have
to
do
this
in
process
so
really
for
every
key
for
every
attribute
for
every
span.
You're
going
to
have
to
derive
that
key
by
flattening
this
kind
of
nested
structure
in
process
and
send
it
off
for
backends
that
can
ingest
ot
LP
natively
unless
they
can
store
this
nested
structure,
they're
gonna
have
to
flatten
at
that
point
in
time.
It
just
seems
like
a
lot
of
work
when
we
already
kind
of
have
this.
G
This
dotted
string
notation
for
our
attributes
and
I.
Think
that's
kind
of
the
point
in
this
PR
was
that
this
dotted
string
kind
of
notation,
like
HTTP,
URL
HTTP
method,
is
really
kind
of
like
a
nested
map
in
disguise
and
I
kind
of
agreed
with
that,
but
ultimately
I
think
that
it's
it's
kind
of
a
compact
version
of
a
nested
map
and
there
are
like
some
efficiencies
to
be
gained
from
it,
both
kind
of
from
the
tracing
client,
side
and
kind
of
on
the
export
ingest
side.
G
Other
things
that
kind
of
came
to
mind
as
I
started
thinking
through
this
a
little
bit
more
is
like
right
now.
You
know
we
can
do
things
in
the
tracing
clients
to
ensure
that
we
have
like
zero
runtime
allocations
for
like
common
keys,
common
semantics
conventions,
just
by
having
constant,
constant
strings
in
that
dotted
notation,
and
we
kind
of
lose
that
if
we
move
into
this
nested
Maps.
G
Structure
and
then
kind
of
like
lastly,
having
written
some
code
that
does
this
before
to
flatten
out
these
nested
structures
like
stuff
gets
really
weird.
If
you
go
from
a
map
to
an
array
to
a
map
again-
and
you
want
to
flatten
into
a
key
so
say,
for
example,
you
have
like
a
user
with
an
array
of
subscriptions.
The
subscription
has
like
an
ID
and
a
name.
G
In
an
arrays
there's
one
thing
that
I
commented
there
I'm
totally
cool
with
arrays
I,
actually
have
no
problem
with
them.
It's
like
once
you
add
the
nested
Maps
that
things
start
to
come
on
unhinged
and
things
can
get
kind
of
very
deeply
nested
I
think
arrays.
Allow
you,
a
very
shallow
level
of
nesting
and
kind
of
you
know,
give
you
kind
of
that
list,
property
that
often
comes
up
with
things.
G
J
G
I,
don't
think
it's
a
problem
as
long
as
the
things
in
your
in
your
array
are
like
simple
types:
I
think
it
gets
more
of
a
problem
when
the
things
in
your
array
are
like
a
map
and
you
have
to
keep
going
further
down
in
in
the
nested
structure.
Mm-Hmm
like
right
now
we
limit
the
arrays
to
you
know:
rules
numbers
strings,
so
you
kind
of
stop
at
that
array.
J
One
of
the
thing
that
I
heard
from
people
complaining
was
mostly
about
having
a
better
way
to
group
things
like
okay.
All
these
attributes
are
about,
let's
say
HTTP,
so
they
feel
having
mapped
support
for
that
and
again
I'm,
not
necessarily
supported
format
but
I'm
trying
to
see
if
that's
good
the
case
or
not.
They
said
if
we
have
a
map,
it's
much
clearer
that
all
these
things
are
grouped
together
under
HTTP,
then
slightly.
G
Yeah
and
and
that
that's
the
example
in
that
facilitation
issue
and
I-
admit
the
first
time
that
I
read
through
it
I
kind
of
thought:
hey,
you
know
they
have
something
here.
This
is
this
dotted
like
HTTP,
URL,
HTTP,
dot,
method,
HTTP,
whatever
there's
you
know
more
than
a
handful
of
attributes
that
could
be
prefix.
Http
is
kind
of
like
this
map
in
disguise,
and
this
dotted
notation
is
kind
of
like
it
is
kind
of.
G
Ultimately,
you
know
a
map
and
it
could
be
represented
as
one
but
as
I
went
to
the
exercise
of
thinking
about
how
anyhow
tracing
back
ends
are
going
to
handle
this
they're
going
to
need
a
key
value
pair.
So
you're
gonna
have
to
flatten
this.
So
that
seemed
a
little
weird
to
me
so
and
then
kind
of
the
next
thing
that
I
was
being
anything
about.
It
is
a
lot
of
our
SDKs
have
helpers
for
for
semantic
conventions,
and
these
end
up
giving
you
the
property
that
you
can
have
zero
runtime
allocations
for
every
key.
G
That's
a
semantic
convention,
whereas
you
lose
this
with
this
map.
Notation
and
I
was
one
of
the
other
things
that
I
posted
on
the
spec
issue.
That's
linked
there,
it's
just
kind
of
like
how
many
objects
do
we
need
to
represent
this
with
the
data
string
notation
and
how
many
objects
do
we
need
to
represent
this
with
the
nest
in
map
notation
and
then
that's
kind
of.
G
If
you
create
everything
every
time,
but
with
the
dotted
string
notation,
you
can
take
it
a
step
further
and
you
know
reduce
reduce,
at
least
for
the
keys
this
to
zero
runtime
allocations
and
then
yeah.
So
there's
a
lot
of
efficiency,
I
think
by
having
the
dotted
string,
notation
and
well
I
agree.
There's
a
nice!
Oh.
L
I've
been
here
a
counterexample
I've
seen
some
libraries
not
know
tell
library,
but
existing
library
should
go
where
they
take
advantage
of
goes
structure
tagging
to
annotate
the
fields.
So
you
have
one
structure
that
has
five
values
in
it
and
it
has
structure
tags
letting
you
annotate
the
names
of
those
fields,
and
then
you
take
one
value.
You
stick
it
in
as
the
value
for
an
attribute.
L
You
know,
since
it
has
five
values:
you're
you're,
creating
that
nested
map
structure
but
you're,
using
a
built
in
facility
of
the
language
so
that
you
don't
have
to
have
any
allocation
set
as
well,
and
there
are
examples
of
languages
doing
that
already
so
I
guess
I
was
wondering
if
this
is
like
necessary
or
I,
don't
see
its
environment
allocations.
I.
L
Think
I.
Think.
Your
point,
that
is
that,
like,
if
you
see
backends,
are
gonna
have
to
flatten
these,
because
there's
no
support
for
for
structures
like
sort
of
the
structured
data
and
I
mean
I,
think
implicitly,
you're
suggesting
we
shouldn't
just
put
those
in
straight
form
and
give
them
to
those
backends.
Because
then
those
bad
guys
will
be
completely
useless.
I
think
if
you
can't
recognize
map
structure-
and
we
give
you
a
string
of
text
here-
you're
not
gonna,
get
any
value
than
that,
so
you
can
do
the
conversion
bounce.
G
G
Do
not
need
a
please
support.
These
nested
structures
and
I
could
be
ninety
used
in
this
area
and
for
ones
that
don't
we
are
going
out
to
flatten
these
all
into
the
status
string,
notation,
so
I
guess
the
concern
I
had
like
why.
Why
not
just
stick
with
dotted
string
notation,
because
we
can
do
this
with
zero
run
time
allocations
and
save
everybody.
The
trouble
yes.
J
J
J
L
G
Yeah
I
mean
ultimately
I
think
this
I
don't
know
that
we're
gonna
resolve
this
today.
I
just
wanted
to
kind
of
like
raise
this
issue
and
have
people
think
about
think
about
it.
Think
about
your
tracing,
back-end,
think
about
your
export
needs.
Think
about
updating
like
years
of
Kiner,
jäger
exporter
in
your
sdk
to
flatten
stuff
and
just
like
experiment
with
things
and
see.
H
I
want
to
make
the
first
one
is
I
notice,
like
Microsoft,
will
do
some
fertilizer
when
we
like
try
to
convert
from
a
structured
data
to
something
like
food
out
bar
and
we
realized.
Oh,
like
people
already
put
like
food
bar
in
their
names.
So
we
got
to
escape
the
string,
and
this
is
very
painful,
so
I
think
here
we
want
to
take
the
license
and
avoid
that
like
escape.
H
At
least
we
want
to
know
what
the
user
can
put
in
the
name
and
when
we
want
to
invent
something
like
convert
from
a
structure
data
to
hierarchical
name.
We
know
we're
not
into
studying
on
the
others
toast
the
the
the
techno
one
is
for
the
schema,
flattening
notice
like
in
the
C++
sake.
We
face
an
issue
where
we
have
the
Behrend,
and
now
we
see
there's
a
proposal
in
aspect
range
I
had
nested
data
type.
We
start
1/2
question
like.
Are
we
responsible
for
checking
the
like
loops?
F
L
Below
yeah
I'm,
not
the
topic
of
cycle
detection
came
up.
That's
a
real
issue.
It's
a
safety
issue
for
using
oh
yeah,
I.
Think
of
it
as
a
logging
issue
like
this
is
an
issue
that
logging,
if
you
had
thought
to
address
or
explicitly
not
address,
but
I.
Think
Matt's
point
going
back
to
the
beginning
here
is
that
this
is
not
something
traditionally
that
tracing
back
hand
would
ever
care
about
we're
forcing
them
to
care
about
it.
We
put
this
through
the
standard,
so
I
don't
know.
L
E
L
F
G
So
this
is
come
up
before
it's
usually
me
asking
this
question
and
I'm
actually
supposed
to
be
writing
some
clarifying
language
for
the
spec,
around
resources
and
kind
of
one
of
the
things
that
keeps
coming
up.
Is
that
the
reason
why
a
resource
why
every
span
has
a
reference
to
a
resource
is
that
you
can
have
multiple
tracer
providers.
G
So
I've
yeah
I've
been
ready
to
write
this
a
few
times
and
these
questions
kind
of
keep
coming
up
in
various
SIG's
and
I.
Just
kind
of
wanted
to
take
one
step
back
and
try
to
understand
this.
Multiple
tracer
provider
situation,
because
it
is,
it,
is
listed
in
the
spec
as
a
it's
actually
listed
under,
should
not
a
must
that
you
can
have
multiple
tracer
providers.
You
normally.
G
Global
tracer
provider,
but
you
should
be
able
to
instantiate
multiple
in
process,
and
all
this
just
seems
a
little
bit
weird
to
me
because
well
the
thing
that
I'm
trying
to
clarify
is
how
how
does
this
multiple
tracer
provider
situation
work?
There's
really
no
API
to
interact
with
more
than
one
tracer
provider.
It's
like
there's
not
only
like
a
trace
of
provider
provider
to
like,
or
for
anybody
to
use
this.
G
J
J
There
is
a
good
question
if
we
should
allow
the
same
instance
of
exporters
to
be
hooked
into
multiple
trace
providers.
I
have
no
good
question
about
this
good
answer.
Sorry,
maybe
maybe
the
limitation
that
you
are
looking
for
is
actually
that
you
cannot
share
the
same
instance
of
a
Spain
exporter
to
multiple
trace
providers,
even
even
if
the
user
creates
multiple
trace
providers,
which
is
fine,
you
just
have
to
create
a
different
exporter
instance
for
every
of
these,
so
I've
become.
L
Users
asking
for
this
and
my
impression
metrics
and
go,
and
my
impression
is
that
the
reason
why
people
ask
for
this
is
that
they
would
like
to
have
her
per
tracer
of
her
provider
resources
and
we
haven't
given
them
an
API
for
resources.
Therefore,
they
are
saying:
ok,
I'll
just
create
my
own
provider
with
each
of
the
resource
for
each
one
and
I'll
just
attach
those
to
my
exporters.
So
it's
a
very
any
valid
and
requesting
and
reasonable
I've
started
to
implement
that
support
in
the
metrics
based
in
kafir.
L
L
J
L
Slope,
you
never
again
would
agree
on
that
like
yes,
if
my
process
has
shard
17
as
a
resource,
that's
because
the
entire
process
is
described
by
start
17.
Now,
if
I
have
another
sharp
shard,
18
and
I
want
to
have
all
my
traces
in
shard
18
be
automatically
label
resource.
Is
the
concept
I'm
looking
for
whether
or
not
like
I
think
that
your
your
statement
that
resources
are
the
process?
This
is
not
all
the
times.
J
L
Same
process,
these
nose
so
there's
some
modular
code,
the
instrumentation
module
and
it's
saying
every
spare
not
create,
belongs
and
start
18.
So
why
should
I
attach
that
to
every
span?
It's
a
static
from
my
point
of
view
in
this
module
code
and
I'm
just
trying
to
say
why
this
demand
come
out.
I
I.
J
J
We
can
have
a
different
object,
called
metadata
or
whatever
I
think
we
should
very,
very
clear,
clearly,
scope,
scope,
the
the
scope
scope,
the
the
the
where
we
put
things
the
whole
idea
of
resource
was
was
to
describe
the
application,
describe
the
the
process
running
and
stuff,
and
we
we
can
have
another
object
which
has
again
repeated
attributes
and
stuff.
We
wish
serves
a
different
purpose
than
than
resource.
J
Don't
get
me
wrong,
I'm,
not
saying
we
should
not
give
the
user
dis
coping
thing
which
I'm
hearing
right
now
he's
just
like
I,
don't
want
them
to
abuse
the
resource.
I
think
the
resource
was
with
this
design,
with
the
idea
of
describing
the
application
describing
the
the
process
and-
and
there
may
be
implementation
that
rely
on
that-
that
all
these
informations
are
describing
the
process,
not
a
scope
inside
the
process,
and
we
can
give
them
another
level.
Where
is
the
scope
level,
and
we
can
have
that?
Does
it
make
sense?
What
I'm
trying.
L
J
G
L
I
got
the
dependency
injection
question
like
different,
like
you
just
do
dependency
injection
differently.
So
so
that's
probably
why
you
feel
confused
right
because
for
me
it
doesn't
seem
like
a
phone
call
and
go
you
just
create
yourself,
a
new
SDK.
If
that's
what
for
left
letter
now,
I've
got
to
another
one:
I've
got
three
I
just
have
to
keep
a
pointer
the
thing
I'm
using
and
there's
one
that's
global,
which
is
very
special
because
we
have
to
deal
with
Emily
but
the
otherwise.
You
just
create
your
own
providers
and.
L
G
So
I
understand
that,
like
in
a
world
where
you're
doing
almost
100%
manual
instrumentation,
you
can
manage
all
of
your
tracer
providers
and
it
all
works
out.
But
in
a
world
where
you
have
mostly
auto
instrumentation,
like
everything,
is
going
to
be
going
through
your
global
tracer
provider
and
to
get
something
to
go
through
when
these
other
ones.
It's
going
to
be
like
a
lot
of
kind
of
manual
management
on
your
behalf
and
it
so
it
kind
of
seems
yeah.
G
J
To
be
continued,
yes,
one
thing
that
I'm
hearing
from
you
mad-
maybe
you
want
to
file
an
issue-
is
tracer
provider
versus
auto
instrumentation
and
what
tracer
providers
should
auto
instrumentation
libraries
use
in
this
case,
I
think
I
think
I
heard
from
you
that
most
likely,
all
the
other
instrumentation
will
use
only
the
global
tracer
provider,
which
is
fine
answer.
Probably
we
should
document
that,
but
in
case
of
manual
instrumentation
as
just
pointing
we
can
user
can
do
whatever
they
want.
They
can
get
more
more
tracer
providers
and
we
cannot
stop
that
correct.