►
From YouTube: 2022-06-08 meeting
Description
cncf-opentelemetry meeting-2's Personal Meeting Room
B
Okay
yeah,
so
I'm
in
the
west
coast,
I'm
in
redmond,
fidget
sound.
A
So
maybe,
while
others
join
tigran,
could
you
help
me
understand
what
typically
happens
once
we
agree
on
the
otep?
A
Do
we
have
to
raise
another
pr
for
change
to
the
spec.
C
Yes,
what
what
is
proposed
in
the
authentic
needs
to
be
propagated
to
the
specification?
C
Typically,
some
more
refinement
happens
there
if
necessary
and
rotops
can
also
cover
other
areas,
not
just
specification.
That's
why
kind
of
this
two-step
process,
the
one
that
you
have
is,
I
guess
primarily
for
the
spec.
So
it's
mostly
going
to
be
updating
the
existing
specification
section
with
what
you
have
there.
C
A
C
Yeah,
that's
that's
true
and
that's
that's
kind
of
unfortunate.
I
was
hoping
for
more
people
to
see
and
comment
on
this.
What
is
very
likely
to
happen
is
that
people
will
have
opinions.
We
just
don't
know
about
those
opinions
yet
and
after
a
while
most
likely,
when
the
implementations
start,
we
will
start
seeing
those
opinions
and
I've.
Unfortunately,
opinions
are
also
going
to
be
quite
valid
in
some
cases
it's
not
like
we
can
disregard
them.
C
So
I
think
what
what
really
is
going
to
happen
is
we're
not
going
to
declare
the
whatever
is
the
result
of
the
authep
as
a
stable
specification
immediately
anyway,
so
whatever
we
decide
to
do
today,
let's
say
we
decide
with
on
what
the
api
shape
is.
It's
still
going
to
be
marked
as
experimental
in
the
spec.
That's
my
expectation,
and
we
will
want
to
give
it
a
bit
more
time,
but
but
we
will
encourage
the
the
different
language
things
to
start
implementation
actually
right.
C
E
C
C
We
shouldn't
think
of
it
as
being
the
final
saying,
and
there
is
nothing
that
can
be
changed
after
that,
although
it's,
I
guess
useful
for
us
to
make
up
our
minds
right
and
and
let's
say,
try
to
try
to
stick
to
it,
but
again
it's
not
going
to
be
set
in
stone.
Yet
that's
my
opinion,
yeah
okay.
So
so
I
guess
we
have.
We
have
the
the
people-
I
guess
here
so
the
the
important
topic
right.
C
What
we
decided
to
do
last
time
is
we
want
to
make
the
decision
on
whether
it's
going
to
be
one
one
unified,
I
guess
events
and
login
api
or
it's
going
to
be
two
different
apis.
C
C
I
don't
want
to
restart
this
same
discussion
again,
but
if
anybody
has
any,
let's
say
significant
new
arguments,
let's
talk
about
those.
If
you
have
any
so,
does
anybody
think
that
they
have
something
to
say
important
that
hasn't
been
yet
discussed.
B
C
B
It
previously,
but
my
preference
would
be
a
separate
api
so
that
if
we
can
want
or
may
have
the
option
of
moving
it
onto
a
span
as
well,
so
it's
the
same
api
for
events
regardless
of
the
transport.
F
I
I
would
just
add
on
to
what
nev
said
that
that
has
been
attending
the
client
side
sake
and
at
one
point
he
mentioned
that
in
his
mind,
eventually
the
span
events
api,
the
span
events
would
be
changed
to
potentially
change
to
use
the
log
data
model.
F
So
I
don't
know
like
if
from
you
know,
I
don't
have
that
perspective.
I
don't
know
like
if
there's
if
this
is
a
shared
shared
vision
among
the
tc
members
or
if
it's
just
ted's,
that's
idea,
but
I
just
want
to
throw
it
out
there.
C
It's
ted's
idea.
I
don't
think
it.
C
But
it's
not
rejected
either
it's
it's
a
possibility,
but
we
cannot
remove
the
span
events
anyway.
It's
part
of
the
stable
specification
now
so
what
may
happen?
Is
we
say
that
okay,
it's
obsolete,
we're
not
going
to
use
it
anymore.
We
deprecate
it
and
recommend
using
the
new
one,
but
it's
not
going
to
be
deleted
anyway,
but
I
I
think
it's
it's
it's
a
valid
discussion.
It
can
happen
in
the
future.
C
G
I
feel
that
this
was
like
discussed
like
back
and
forth
so
many
times,
and
probably
this
was
also
brought,
but
like
my
thinking
right
now.
After
all
of
these
discussions
is
that
maybe
we
should
just
have
the
events
api
because
it's
like
well
defined
what
we
need
to
achieve
there
and
if
we
need
to
have
like
separate
api,
we
can
always
add
it
later.
It's
easier
to
add
than
remove
things
essentially.
C
That's
that's
not
entirely
true,
because
if
we
have
an
events
api,
we
can
no
longer
say
that
in
the
future
we
have
one
unified
and
logging
api.
So,
and
also
it's
not
true,
because
we
already
have
logging
related
capabilities,
we
implement
appenders.
There
is
actual
code
implemented
there
for
log4j
for
log
back.
There
are
implementations
that
use
it.
G
G
Maybe
I
need
to
like
look
look
back
at
the
autops,
but
my
impression
was
that
there's
like
one
thing:
that
is
what
is
provided
in
the
sdk
and
essentially
this
layer
that
provides
interoperability
with
the
existing
login
libraries
and
the
other
is
providing
like
the
whole
set
of
apis
with,
let's
say,
log
event
or
like
whatever,
whatever
it
was
called
in
the
in
the
poc.
Essentially.
C
Right
in
my
mind,
those
are
again
apis
right.
They
have
different
target
personas,
but
they
are
apis
that
we
provide
for
people
to
to
call.
But
anyway,
I
guess
so.
My
understanding
so
far
has
been.
That
is
that
the
opinions
are
split
here
right.
I
guess
santosh
and
I
I
think
were
in
favor
of
having
one
api
most
others.
If
I'm
not
wrong,
think
that
it
needs
to
be
separate
apis
and
probably
some
people
don't
have
a
strong
opinion
one
way
or
another
in
these
situations.
C
I
guess
we
have
a
couple
of
ways
moving
to
move
forward
right
either
we
ask
for
for
a
tc
member
to
to
to
be
a
tiebreaker.
Essentially
right-
and
here
we
have
again
two
sub
options.
Either
I
can
be
the
that
tie
breaker
or
we
find
somebody
who
is
more
impartial
because
they
they
don't
have
their
own.
I
guess
initial
opinion
here.
That's
fine
either
way
right.
If
you
guys
think
that
you
want
me
to
be
that
person,
I
can
do
that.
C
If
you
want
another
tc
member
to
decide,
that's
let's
find
it
as
well
or
I
guess
and
again
we
don't
have
to
go
for
that
right.
We
can
also
say
that
we
don't
want
actually
one
person
to
make
this
decision.
We
want
another
form
of
decision
making.
That's
that's
okay
with
me
as
well.
I,
but
I'm
just
putting
these
options
on
the
table
so
that
you
guys
can
tell
whether
you
want
to
proceed
one
way
or
another.
C
So
if
you
think
that,
for
the
sake
of
time
I
guess
to
to
and
for
to
be
able
to
make
progress,
I
guess
the
best
is
that
we
make
the
decision
now
and
now
means.
I
guess
I
make
the
call
if
you
don't
want
that.
That's
completely
fine!
I
am
not
eager
to
be
that
person
we
can
go
and
find
one
more
other
tc
member
or
if
you
have
other
proposals
of
resolving
this,
I'm
happy
with
that
as
well.
C
So
those
are,
I
guess,
the
three
options
that
we
have
right
now
tell
me:
what
do
you
want
to
do.
H
Sorry
I
joined
late,
but
I
support
you
making
the
decision
tiger
and
I
think
you've
been
very
focused
on
this
and
I
think,
as
jack
said
last
week,
we
I
don't
think
either
of
these
decisions
is
going
to
be
the
wrong
decision.
They're
they're,
both
fine
decisions.
I
think-
and
it's
just
sort
of
an
optimization
problem
here.
So
I
think
either
way
is
okay
and
you
should
make
the
call,
in
my
opinion,.
C
And
just
to
make
it
very
clear
right,
I'm
not
going
to
change
my
opinion
in
a
second
right,
I'm
going
for
for
one
api
just
to
just
to
make
it
very
clear
if
I'm
doing
that
decision
that
that's
going
to
be
one
api
with
two,
I
guess
branches
that
we
discussed
with
event
builder
log
builder
and
all
that
stuff
up
to
you
guys.
I
see
navy
saying
vote,
that's
fine
with
me
as
well!
C
If
you
guys
collectively
decide
that
we're
going
with
a
voting
approach,
I
I
personally
don't
think
that's
the
best
approach
to
make
decisions
on
the
design,
but
if,
as
a
community,
you
want
to
do
that.
That's
okay
as
well!
So
I'm
not
I'm
not
trying
to
exercise
any
right
here
as
a
pc
member.
That's
fine
with
me
as
well.
D
A
The
limited
folks
here
right,
I
think
we
yeah.
C
C
No,
I'm
saying
it
doesn't
have
to
be
a
vote
by
the
open,
telemetry's
rules.
If
there
is
no
agreement
on
an
approach
or
a
design,
a
tc
member
makes
the
call.
That's
that's
that's
I
guess
what
the
rules
say
or
or
the
tc
member
may
make
the
call
right.
They
don't
have
to.
It,
doesn't
have
to
be
voting
and
the
tc
members
have
have
that
ability.
Let's
say
so
right.
I
C
A
Is
there
a
precedence
to
changing
what
has
been
upgraded.
C
Well,
I
mean
it's
yeah,
it's
an
experimental
section
right
of
the
specification.
It's
completely
open
for
changing.
Yes,
it
will
be.
I
guess
it
will
require
justification
right.
So
you're
not
going
to
just
say:
oh
no,
it's
a
wrong
decision.
No
we're
just
changing
our
mind.
If
there
is
new
evidence
there
is
justification,
then.
Yes,
the
specification
that
is
marked
as
experimental
is
subject
to
change
to
significant
changes
as
well,
including
changes
like
that,
like
complete
restructuring
of
the
api,
is
fine.
That's
that's
not
without
I
guess,
but
we
can
do
that
right.
Okay,.
E
C
C
It's
fine
if
people
want
to
prototype
a
different
approach
as
well
and
use
that
as
an
argument
in
favor
of
that
different
approach,
that's
okay!
But
if
we
have
a
if
we
have
a
specification
which
says
this
is
the
shape
of
the
api,
we're
also
going
to
have
line
items
in
the
compliance
matrix
and
then
the
the
language
sigs
are
supposed
to
fill
that
compliance
matrix
with
the
with
whatever
features
they
did
implement.
C
If
it's
going
to
be
if
the
implementation
is,
has
a
different
shape
of
the
api
they're,
just
not
going
to
be
able
to
do
that.
So
that's
that
approach
is
undesirable.
We
should
not
encourage
that
right
and
again,
prototyping
is
fine,
but
that
shouldn't
be
the
official
open,
telemetry
sdk
implementation,
even
though
that
official
one
is
still
experimental,
the
official
approach
should
comply
with
whatever
the
specification
says.
C
No,
not
really.
The
thing
is
that
the
following
you're
saying
every
so
people
go
and
ignore
the
spec
they
implement
it
differently.
What's
the
point
of
the
spec,
then
it
shouldn't
be
happening.
If
people
disagree
with
the
spec,
we
should
change
the
spec
and
then
people
can
implement
the
other
approach
right.
B
What
I'm
saying
is
both
of
these
are
interfaces,
and
they
just
happen
to
always
be
implemented
in
the
same
class.
I
know
from
a
from
a
client
perspective,
especially
in
the
browser.
I
can
definitely
see
cases
and
I
have
cases
where
clients
only
send
events.
They
they
don't
want
logs.
E
I
know
I
don't
actually
think
you
would
have
the
ability
to
have
like
you
could
have
one
implementation
of
the
of
the
interface
that
served
both
purposes,
but
I
don't
think
if,
if
we
went
down
the
approach
of
having
like
two
apis
like
what
that
what's
kind
of
implied
in
that
approach,
is
that
you
have
two
separate
declared
interfaces,
one
for
events,
then
one
for
logs
and
the
implementation.
Can
you
know
if
you
support
multiple
inheritance
can
can
implement
both
of
those
interfaces,
but
you,
you
should
have
two
separate
interfaces.
E
If
we
go
down
that
approach
and
in
contrast,
if
we
decide
on
a
single
unified
api,
we
you
it
implies.
We
only
have
one
interface.
C
So
I'm
sure
you
guys
can
structure
the
underlying
implementation
in
a
way
that
will
keep
this
options
open
for
you
right,
so
that
you
can
refactor
it
relatively
easily,
because
you
are
aware
of
this
discussion,
you
know
that
things
may
change.
I
don't
see
that
as
a
hugely
complicated
refactoring.
If
we
change
our
mind
in
the
future
right,
if
that
happens,
I
think
it's
possible,
if
possible,
to
make
this
change
without
full
rewrite
of
whatever
is
being
implemented
right
now,.
E
I
I
do
have
one
additional
argument,
or
maybe
it's
a
restatement
of
an
existing
argument,
but
I
just
so
if
we
were
to
take
this
to
a
vote.
I
agree
with
what
people
have
been
mentioning
about
votes
being
imperfect,
especially
because
it's
it's
a
relatively
small
group
here
that
isn't
representative
of
all
the
opinions.
E
So
I
don't
think
that
that's
a
perfect
way
to
resolve
this,
but
if
we
were
to
take
a
vote
right
now,
I
would
choose
for
separate
apis
as
well
and
the
the
argument
that
is
the
strongest
for
me
is
that
with
separate
apis,
you
can
enforce
that
the
caller
has
to
choose
a
domain
when
you're
obtaining
an
event
emitter
with
a
single
api.
E
It's
it's
really
easy
for
someone
to
ignore
the
the
documentation
or
the
advice
that
you
should
include
a
domain
and
and
and
not
included,
and
I
think
we'll
will
find
that
lots
of
events
end
up
in
the
default
domain,
whatever
whatever
that
mechanism
ends
up
being.
So
that's
my
argument
for
for
separate
apis.
Is
it
really?
It
really
forces
the
issue
and
really
encourages
the
domain
in
a
much
stronger
way.
A
Does
it
not
depend
on
how
the
interfaces
actually
are
defined
like
you
could
still
have
a
log
unified
interface,
but
while
creating
events,
you
know
how
the
signatures
specifically
mention
about
events
and
and
then
mandate
the
domain
there.
E
You
could
do
that
so
at
the
individual
event
record
level,
you
could
have
an
api
that
accepts
an
event
name
and
event
domain,
but
that's
pushing
the
domain
down
to
the
record
level
when
I
think
that
it
should
be
up
at
the
the
scope
level
so
that
you
don't
have
to
include
it
on
every
single
record
and
you
don't
have
you
don't
have
to
include
it
and
and
and
furthermore,
like
you,
don't
have
the
ability
to
include
it
at
the
record
level.
It's
I
think
the
ergonomics
are
reduced.
C
C
C
That
argument
is
not
as
strong
for
me
as
the
fact
that
we're
losing
the
consistency
with
the
rest
of
the
open
telemetry,
and
I
I'm
going
to
continue
playing
that
the
draw
of
a
person
who
tries
to
to
kind
of
bring
the
voice
of
all
of
open
telemetry.
Not
just
of
the
logging,
seek
right
into
this
discussion
so
that
that
doesn't
change.
My
mind.
B
So,
just
broadening
a
little
bit
so
I
know
morgan
was
pushing
for
effective
profile
events
or
I'm
sorry
profiling.
To
be
a
new
signal
to
me,
I
see
profiling.
Really
that's
just
going
to
be
spitting
out
events.
So
that's
where
I
see
this
event
api
as
as
being
used
so
the
domain
for
a
profiling,
one
would
be
profile
or
whatever
it
gets
called,
and
I
also
see
the
you
know
potential.
B
B
C
B
Yeah
and
eight
o'clock
for
me
friday
morning,
like.
C
Yeah
yeah,
okay
anyway,
I
guess
that's
that's
yeah
related,
but
I
don't
want
to
over
complicate
our
discussion
by
by
bringing
more
more
and
more
so.
I
do
agree
with
you
by
the
way
that
probably
profiling
needs
to
be
implemented
in
the
form
of
this.
These
same
events,
but
a
lot
of
people
in
that
work
group
have
a
different
opinion.
So
it's
not
a
given
that
that
is
exactly
what
will
happen.
C
We,
I
don't
know
right,
we'll
see
anyway,
so
we
can
keep
going
with
more
thoughts
or
or
we
can
move
forward
and
have
a
vote
on
whether
you
guys
want
me
to
be
the
tiebreaker
or
no,
let's
vote
on
that.
I
guess:
what's
the
right
way
to
vote
in
zone,
there
is
some
sort
of
reaction.
I
think
that
you
can.
C
C
C
C
Okay
cool.
So
let's
know
if
we
count
what
we
have,
how
many
we
have
one
two,
three,
four,
five,
six
six
four
and
how
many
against
one.
C
Okay,
so
let's
do
that,
let's
go
with
one
api,
let's
be
very
clear
that
this
is
not
final.
C
If
there
is
new
arguments
to
be
heard-
and
maybe
even
from
new
people
who
were
not
part
of
this
discussion,
we
are
completely
open
to
changing
our
mind
as
people
who
will
be
doing
the
implementation.
Please
also
take
this
into
account
right
structure,
your
code,
in
a
way
that
making
this
change
is
not
going
to
be
a
huge
pain
for
you
sounds
good.
C
C
A
Again,
coming
from
a
requirement
from
the
client
side
telemetry,
where
we
have
a
need
to
support,
attribute
values
to
be
further
objects
and
not
just
primitive
types,
and
I
think
you
mentioned
in
one
of
the
issues
that
you
know
the
log
records
the
attributes
in
log
records.
The
spec
allows
the
attribute
values
to
be
anything
not
not
restricted
to
primitives,
so
that
there
were
two
questions
you
know
is
that
applicable
even
to
the
span
events
or
only
to
the
log
records?
A
C
So
let
me,
I
guess,
give
you
a
bit
historical
context
here.
This
limitation
was
written
when
we
were
discussing
the
tracing
api
like
a
couple
years
ago,
and
many
vendors
expressed
concerns
that
their
proprietary
protocols
and
their
backends
don't
support
the
concept
of
spawn
attributes
having
complicated
types
essentially
right,
and
because
of
that,
we
we
added
that
limitation
to
the
spec,
to
where
it
was
at
the
time
that
the
tracing
specification
matrix
wasn't
given
starts,
or
maybe
it
was,
but
it
was
in
the
experimental
stage
so
that
that
was
explicit.
C
I
guess
that
was
written
with
the
tracing
in
mind.
Right
later,
when
we
started
working
on
logging,
it
was
clear
that
in
the
logging
world
you
have
already
have
data
structures
formats
where
you
do
want
to
have
more
more
nesting,
more
complicated
data
structures
right
with
nested,
the
key
value,
pairs
objects
and
all
that
stuff,
more
json-like
structure.
And
so
when
the
data
model
for
logging
was
discussed
and
written,
we
made
it
explicit
there
that
this
has
different
definition
of
what
is
allowed
in
the
attributes
for
both
logging
and
traces
in
otlp.
C
We
use
the
same
definition
of
attribute
value,
it's
an
any
value
type
ending
value
and
it
allows
arbitrary
nesting.
However,
because
the
tracing
specification
is
written
as
it
is
written.
The
implementations
limited
the
open,
telemetry
api
and
sdk
implementations
have
this
limitation
in
the
tracing
area.
C
I
don't
think
we
need
to
have
the
same
limitation
or
can
even
have
the
same
limitation
in
the
logging
area.
We
need
this
flexibility
for
logs
now
I
guess
the
question
is,
and
I
saw
maybe
open
the
issue
there
right
do
you
do
we
want
to
lift
the
limitation
for
traces?
I
don't
know.
I
think
we
should
discuss
this.
I
suspect
that
most
of
the
vendors
that
had
this
limitation
will
continue
having
this
limitation.
So
probably
they
will
be
against.
B
It
it's
more
okay,
so,
like
the
the
the
spec
issue
that
I
created
is
it's
unclear
from
the
spec.
If
you
read
the
spec
one
way
it
already
is
lifted
and
in
the
case
of
the
javascript
api,
you
can
pass
nested
objects
because
a
span
attribute
is
an
attribute.
So
there
is
nothing
stopping
you
to
do
that
today.
So
really,
this
is
just
trying
to
clarify
it
to
say
which
I
think
I
had
my
the
original
part
of
the
issue.
B
You
know
which
is
a
bit
of
a
problem
because
the
way
protobuf
is
defined,
we
should
have
them
as
either
unified
or
separate,
and
I
know
if
we,
if
we,
if
we
go
down
the
separate
path,
it's
going
to
break
the
product
by
definition,
because
the
ids,
but
my
preference
of
course
would
be
to
allow
allow
as
a
common
thing.
You
know
as
per
the
attribute
collections
definition
which,
when
I
was
talking
to
santos
earlier
today,
if
you
read
that
one
way
that
even
the
attribute
collection
is
unclear,
whether
that
means
nesting.
B
A
Just
to
clarify,
I
don't
think
never
I
think
you
can
correct
me
if
I'm
wrong,
I
don't
think
the
we
need
the
trace,
so
the
spans
attributes
themselves
to
be.
You
know
having
the
support.
We
are
only
talking
about
span,
events,
attributes
and
the
span
events
to
have
this
support.
Well,.
B
Well,
the
the
issue
is
around
the
specification.
The
specification
does
state
that
it's
fun
here
again,
but.
A
C
So
I
I
do
agree
with
you.
I
think
it's
valuable
to
have
this
uniformness
in
the
spec
for
traces.
So
I
would
support
that
notion
that
we
remove
this
limitation
and
just
say
that
the
the
attributes,
the
attribute
values,
are
allowed
to
be
nested
for
traces
for
span
events
for
response
for
metrics
for
logs
for
for
everything,
for
the
resources
as
well.
But
I
don't
know
if
it's
going
to
be
accepted.
I
can
tell
you
that,
even
though
you're
saying
the
specification
is
unclear,
you
you
think
that
it
allows
this
nesting.
C
B
We'd
have
to
say,
as
of
version
x,
anything
supports
version
x,
respect
which
gets
us
into
the
big
version
discussion.
It
would
either
flatten
or
not
button
depending
on
something.
E
E
I
think
collection
it
refers
to
a
set
of
key
value
pairs,
and
so,
like
a
you
know,
a
single
key
value
pair.
It
may
have
values
that
are
primitives
or
arrays
of
primitives,
and
an
attribute
collection
is
is,
is
one
or
more
of
those
key
value
pairs.
B
But
that's
right,
it's
unclear
you
can,
which
is
the
discussion
I
had
with
santosh
earlier
I
read
collection
as
nested
santosh
credit
is
irrational,
so
yeah
either
way,
there's
a
clarification
required
there
somewhere
yeah
yeah.
C
Definitely,
let's
clarify
it.
That
was
absolutely
not
the
intent
that
can
be.
That
cannot
be
nested.
There
is
not
allowed,
but
we
need
to
reward
this
anyway,
once
we
have
the
the
logging
api
in
the
picture
this.
This
cannot
stay
this.
This
way
right.
It's
it's
a
common
area
of
the
specification
and
it
talks.
It
doesn't
say
that
what
is
written
here
applies
to
traces
and
metrics.
Only
so
it's
a
contradiction
in
a
way
to
what
later
the
logging
area
says.
C
E
Supporting
nested
attributes
would
be
challenging
or
not
trivial,
in
in
java
as
implementation.
So
I
I
don't
know
off
the
top
of
my
head
like.
If
it's
feasible
it's
minimally
challenging
it
may
not
be
feasible.
I
don't
I'm
not
sure.
C
Okay,
so
I
I
guess
going
back
to
your
original
expression
santosh,
so
you
you're
concerned
about
how
this
is
implemented
right.
What
it
looks
like
in
the
in
the
code
essentially
do
we
have
different
data
types
for
the
log
record
attributes
and
for
the
span
attributes,
for
example,
is
that
what
you're
asking.
A
Yeah,
I
I
think
I
hear
you
saying
that
instead
of
keeping
them
separate,
you
know
maybe
we
should
just
update.
You
know
our
aim
for
respect
to
update
that
update
with
the
new
support
overall
everywhere.
C
I
think
that
would
be
great
to
do,
but
I'm
not
sure
we
will
be
able.
I
think
there
will
be
objections
to
this
and
also
implementation-wise,
I'm
not
completely
sure.
If
there
is
like
object
set
right.
It
may
not
be
easy
to
do
that.
A
That
implementation
challenge,
I
think
we
will
have
to
face
that,
even
if
we
restricted
the
log
records.
C
There
is
additional
challenge
there
for
trace.
Is
that
whatever
you
do,
it
needs
to
be
backwards,
compatible
change?
We
cannot
break
the
existing
code,
so
we
will
have
to
work
within
the
limitations
of
the
currently
exposed
notion
of
options.
We
can't
break
it.
It
needs
to
look
look
the
same
at
least
right
somehow.
So
I
don't
know
if
that's
possible.
A
One
one
possibility
is
to
you
know,
take
advantage
of
the
name
spacing
concept
in
the
attribute
keys,
so
we
could
say
that
anytime
we
have
an
a
dot
b,
dot
c
equal
to
you
know
some
value.
It
will
be
equivalent
to
an
object
with
the
key
a
having
further
an
object.
You
know
with
the
with
the
key
b,
whose
value
is.
A
A
value
with
a
key
c,
so
if
we
consider
them
as
equivalent,
you
know
that
could
be.
C
That
creates
an
ambiguity
right,
so
you
have
something
like
service
dot
name
as
a
semantic
convention
for
the
attribute
name
right.
Does
it
mean
that
service
is
now
the
attribute
and
name
is
a
sub
attribute
on
that,
but
that's
a
very
different
shape
of
data
right,
so
you're
you're,
forcing
I
guess
the
recipients
to
try
to
kind
of
figure
out
this
equivalence
all
the
time
when
they
receive
this
data.
I
think
it
complicates
things
a
lot,
even
if
you
say
that
they
are
equivalent
you're,
also
outlawing.
C
A
C
B
C
C
Yeah,
so
here's
let
me
find
that
document.
I
think
I
wrote
it
like
more
than
a
year
ago.
C
About
entities
in
the
collector
and
let's
see,
if
I'm
finding
the
right
document
here.
C
C
B
I
guess
that's
why
I
open
the
spec
is
to
start
the
discussion,
but
we're
not
really
getting
a
lot
there
and
why
I
put
it
into
the
spec
meeting.
Unfortunately,
it
was
the
last
one
we
got
punted.
C
B
B
C
B
Yeah
and
and
I've
had
the
same
issue
internally
like
and
in
our
internal
product
version,
two
would
automatically
unflatten
in
javascript,
which
was
painful.
It
was
really
cpu
intensive,
any
keys
that
had
dots
in
them
and
I
removed
that
because
it
was
like
a
20
to
30
cpu
hit.
So
now
I
have
a
flag
which
identifies
whether
to
unflatten
or
keep
it
as
an
object,
so
yeah
very
familiar
with
different
areas.
D
C
All
right,
so
I
think
what
do
we
do?
Next?
We
don't
have
anything
else
in
the
agenda.
I
think
we
need
to
finalize
the
old
tap
with
with
a
single
api
approach
and
get
it
approved
right.
That's
what
it
once
it's
approved.
We
start
merging
the
beats
to
the
specification,
and
then
we
begin
asking
the
the
language
seeks
to
start.
The
implementations
make
it
very
clear
that
this
is
still
experimental
subject
to
change,
but
we
do
want
to
see
a
couple.
C
At
least
I
guess
a
couple
implementations,
different
languages
matching
this
new
api
right,
so
I
guess
at
least
we
want
to
change
the
existing
java
and
python.
I
think
we
have
java
python
one
more
which
one
yeah
anyway
javascript,
so
we
want
to
change
those
to
now
much
the
from
the
new
proposal
of
the
api.
I.
F
I
have
a
quick,
quick
question
about
that,
so
this
this
otep
is
proposing
the
events
api,
but
since
it's
gonna
be
a
unified
single
api,
do
we
also
need
to
include
the
part
bar
logs
the
api
for
logs.
C
I
think
so
I
think
it's
it's
the
right
scope
for
the
otp,
but
I
don't
know
if
I
think
what
you're
asking
is
does
javascript
need
to
implement
all
of
the
otep
it
doesn't.
If
we
mark
the
capability
as
optional
and
that's
a
good
question,
do
we
want
any
portion
of
this
api
to
be
optional
to
be
subject
to
the
to
the
particular
logging?
That's
regular
language
seek
to
decide
on
their
own
whether
they
want
to
include
that
ability
or
no,
I
don't
know,
what's
the
answer
to
this.
F
C
C
We
have
the
prefix
sdk
in
front
of
all
class
names.
We
delete
that
we
get
rid
of
the
word
emitter,
I
think
so
we
end
up
with
logger
provider
and
logger,
which
is
now
symmetrical
consistent
with
tracer,
tracer
and
meter
stuff
on
the
logger.
We
will
have,
let's
say
log.
If
you
use
builder
pattern,
you
have
log
record
builder
and
event
builder,
you
get
that
from
the
logger
and
on
the
builder,
then
you
you
build
an
event
or
build
a
log
record.
C
If
you
don't
use
the
builder
pattern,
you
have,
let's
say
log
record
method
and
log
event
method
right,
and
so
we
we
can
probably
as
a
terminology
we
can
say
to
log
an
event
right,
that's
a
valid
approach
to
say
to
log
an
event
or
we
can
say
event
logging
and
that's
the
thing
right.
If
you
look
at
the
windows
events,
they
they
say,
windows,
event,
logging
or
you
can
say
to
logger
record
or
log
log
recording
right.
Something
like
that.
E
E
And
I
can
update
well,
I
think
I
I
had
some
two
prototypes
that
were
kind
of
part
of
this
argument
and
I
I
can
go
back
and
double
check
that
the
language
in
those
reflects
what
you
just
said
to
your
yeah.
C
E
Separately,
just
want
to
call
out,
I
don't
think,
there's
any
action
here,
but
this
the
single
api
approach
is
dependent
on
scope
attributes
because
it
relies
on
setting
those
for
the
domain.
So.