►
From YouTube: 2022-06-01 meeting
Description
cncf-opentelemetry meeting-2's Personal Meeting Room
A
A
A
So
I
guess
maybe
I
can
start
with
a
question
I
had
jack.
You
posted
there
that
you
had
a
discussion
about
having
separate
events
and
blogs
apis
versus
having
one
api
in
the
javascript,
and
you
were
in
favor
of
having
separate
apis.
C
Yeah,
so
I
saw
your
comment
just
just
now,
and
so
that
meeting
was
a
week
ago
and
I
didn't
take
as
good
of
notes
as
I
should
have.
I
should
probably
go
back
and
watch
the
recording
and-
and
you
know
remind
myself
of
what
they
were
thinking
just
off
the
top
of
my
head.
I
think
the
I
think
the
basis
of
the
argument
was
around
the
naming
conventions
of
things.
As
soon
as
we
have
a
logger
it.
C
It
seems
not
very
necessarily
intuitive
that
you
would
produce
events
from
something
called
a
logger.
So
I
think
that
was
part
of
the
argument
and
then
the
you
know-
and
this
I
think,
is
less
important,
but
the
distinction
of
what
you
know.
C
Events
require
the
domain
field,
and
if
we
separate
events
and
logs,
then
you
can
have
different
apis
that
reflect
the
requirement
of
that
domain
field
when
you're
obtaining
an
event
emitter.
C
Whereas
if
you
were
to
combine
those
into
a
single
api,
you
have
to
rely
on
the
convention
in
documentation
that
you
know
you
should
include
scope,
attributes
called
event
domain
or
something
like
that.
And
if,
if
someone
were
not
aware
of
those
conventions
or
that
documentation,
it's
it's
more
error
prone,
and
I
guess
what
happens
in
that
situation.
Is
you
know
this
default
event
domain
that
we've
been
discussing?
The
events
would
be
put
in
that
default
domain,
so
you
know
I'll
go
back
and
watch
the
recording
and
I'll.
C
A
To
understand
this,
a
bit
better
you're
saying
the
the
specific
api
would
is,
is
not
possible
when,
when
you
combine
them
into
one
but
the
example
that
you
posted
the
first
prototype
that
you
have
it
has
this
event
builder,
where
you,
I
think
you
provide
the
domain
to
the
event
builder.
If
I
remember
correctly,
and
then
you
you
or
the
event
name,
not
maybe
not
the
domain,
but
anyway,
you
have
this
event
builder,
which
is
specifically
for
creating
events
right.
It's
just
that
you
access
the
you.
A
You
obtain
the
event
builder
from
the
from
the
logger
from
the
radio
logger,
which
is
no
different
from
the
one
where,
where
you
would
use
for
lock
records,
but
then,
once
you
obtain
that
event
builder,
it
becomes
very
specific
right.
You
can
have
a
very
focused
api
there,
which
only
allows
you
to
produce
valid
events,
not
by
convention,
but
by
actually
enforcing
that
in
the
api
signatures
and
the
the
available
methods.
So
I'm
not
sure
I
completely
understand
even
given
what
you
have
in
your
prototype.
I'm
not
sure.
C
Hopefully,
provide
some
clarity,
so
here
is
the
example
that
you're
referencing
and
as
as
you
mentioned,
you
know
this
is
a
combined
api
and
we
can
have
very
specific
apis
that
force
you
to
produce
like
well-formed
events,
so
you
know
you're
forced
to
provide
the
event's
name
when
you're
when
you're
obtaining
an
event
builder,
the
thing
that
is
not
forced
and
that
I'm
referring
to
is
the
inclusion
of
the
domain.
C
So
you
know
when
you're
obtaining
a
log,
a
logger
or
a
log
emitter.
Whatever
we
end
up
calling
the
thing,
you
know
it's
up
to
you
to
know
that
events
have
a
domain
associated
with
them
and
that
you
should
include
a
scope
attribute
that
you
know
reflects
the
domain
of
those
events.
A
C
Not
having
a
domain,
we
still
hood
right
well.
So
so,
in
this
scenario,
the
the
domain
is,
it's
it's
easier
to
ignore
and
it's
therefore
easier
to
produce
events
that
fall
into
this
default
domain.
C
Where
it's
unspecified
and
you
know
in
the
default
domain,
we
talked
about
how
you
know,
events
and
that
have
no
sort
of
like
guarantees
about
uniqueness
or
about
their
schema
in
there.
So,
in
contrast,
the
where
you
have
a
a
dedicated
api-
and
we
can
just
go
look
at
that-
a
dedicated
api
for
events.
C
When
you're
obtaining
the
event
emitter,
you
are
forced
to
provide
that
domain
and
you
can
still
provide
null
or
empty
there
and
if
you
provide
no
or
empty
there,
then
the
events
would
would
still
fall
into
this
default
domain.
But
it's
it's
it's
it's
harder
to
ignore.
That's
that's
the
basis
of
the
argument.
A
A
To
be
honest,
my
my
theory
is
that
here
is
that
we're
trying
to
optimize
for
the
specific
narrow
use
case
of
events
and
at
the
cost
of
making
the
of
losing
the
consistency
in
the
api
as
a
general,
a
crossover
telemetry,
and
I'm
I'm
quite
reluctant
about
doing
that.
To
be
honest,
I
don't
know-
maybe
maybe
maybe
it's
unwarranted-
I
don't
know,
but
I
don't
feel
comfortable
with
deviating
from
the
consistency
of
inflammatory
for
for
a
small
game
like
this,
it
seems
like
it's.
The
game
is
small.
There
is
a
game
right.
A
C
That
that
resonates
with
me
as
well
like
I
would
be
like
I'm
not
sure
where
I
stand
on
this.
I
I've
obviously
kind
of
prototyped
two
different
approaches,
and
I
see
the
merits
of
both
the
the
the
the
one
thing
that
I
guess
is
a
bit
hard.
The
pill,
that's
a
bit
hard
to
swallow
for
me
about
having
a
combined
api,
is
emitting
events
from
something
called
a
logger.
D
I
was
reminded
of
something
I
was
going
through
santosh's
pr
before
this,
and
I
was
reminded
of
kind
of
a
little
bit
of
a
historical
bit
that
when
we
decided
to
build
a
logging
sdk,
it
was
not
designed
to
be
a
customer
facing
api,
and
so
we
don't
actually
have
anything
in
the
api
section
for
the
logging
library.
D
Events
obviously
should
be
there
so
that
that
might
be
another
dimension.
That
kind
of
changes
that
right
that,
if
you're
doing
event
emitting
that.
That's
something
that
we
are
looking
at,
that
as
being
a
customer-facing
piece
of
that.
So
is
there
a
way
that
we
can
have
internal
consistency
in
the
sdk,
but
then
we're
only
presenting
the
event
section
of
that
in
the
api.
A
I
think
that
I
think,
if
I'm
not
wrong,
we
discussed
that
particular
topic
and
I
think
the
conclusion
was
that
it
doesn't
seem
wrong
that
we
want
to
expose
the
current
log
emitter,
which
we
call
the
logging
sdk
as
an
actual
api,
that
the
users
may
be
called.
They
may
use
it
for
for
a
variety
of
reasons.
A
D
A
I
think
I
think
I
would
personally
be
a
lot
more
reluctant
to
expose
this
as
an
api
if
it
was
a
significant,
major,
complicated
surface
area,
but
it
seems
like
it's
a
single
method
with
the
single
plain
old
data
type
like
the
log
record,
which
is
and-
and
you
already
have
the
equivalent
in
the
in
the
the
in
the
event
builder,
I
think
we
will
allow
doing
that
essentially
that
that
same
api
is
available
same
functionality
is
available
in
slightly
different
through
a
slightly
different
chain
of
access
functions.
A
So
I
I
don't
think
it
particularly
increases
the
it.
Neither
incl
increases
the
complexity
of
the
implementation,
nor
I
think
it
increases
the
the
api
surface.
To
be
honest,
seems
like
it's
just
using
the
exact
same
builder
through
a
different
access
point.
So
I
think
it's
it's
it's
fine.
To
be
honest,
I
think.
B
So
I
have
one
question
about
this.
I
correct
me
from
my
thinking
here
is
incorrect,
but
having
a
separate
log,
api
and
events
api,
it
seems
like
those
two
different
apis
are
used
in
different
contexts
like
one
one
would
be
like
used
for
log
vendors
or
like
the
the
thing
that
you
know
like.
If
you
use
a
login
library
like
you
want
to
have
it
go
to
open
telemetry
and
the
other.
B
The
events
api
is
used
in
instrumentations,
like
if
you
have
like
a
you
know
like
a
browser
instrumentation
so
like
that
instrumentation
will
get
that
api.
It
will
be
able
to
create
events
so
like
if
you
have
a
single
api
now
that
instrumentation
will
have
access
to
creating
logs
and
events,
even
though,
like
in
documentation,
we
can
say
that
the
logging
is
not
should
not
be
used
in
that
context,
but
it
will
be
available
anyway.
B
So
so
there
is
more
more
chance
of
misuse.
A
So
I
think
we
we
know
two
use
cases,
it's
not
that
these
are
the
only
two
use
cases.
I
think
there
are
other
use
cases
possible
and
frankly,
I
don't
see
anything
wrong
with
exposing
a
flexible
api
for
which
you
envision,
that
there
are
some
possible
unknown
use
cases
with
it,
but
they
they
definitely
are
possible
right.
So
if
you,
if
you
provide
a
mechanism
for
creating
log
records
and
sending
them
to
the
exporters,
is
that
can
that
be
abused
like?
Is
there
a
danger
in
doing
that?
I
just
don't
see
the
dangers.
A
I
would
agree
with
you
if
it
was
a
dangerous
functionality
to
expose
like
it
can
be
misused
in
a
way
that
I
don't
know
I
I
just
don't
see
those.
Maybe
maybe
there
are,
if,
if
you
guys
see
that,
I
think
it
would
be
a
reasonable
thing
to
hide
it.
In
that
case,
I
had
to
try
to
restrict
it
in
some
way,
but
I
don't
see
it
personally
at
the
moment.
D
I
I
do
think
that
from
the
user
api
side,
though,
that
there
is
a
a
great
value
in
it
being
discoverable
that
it
it's
a
very
easy
to
see
an
easy
to
understand
api,
for
you
know
any
of
the
use
cases
you
know.
Ideally,
we've
got
people
that
are
actually
instrumenting
their
code
with
it
and
you
know
want
to
send
event.
D
D
I
I
think
I
think
it
can
be
the
same,
but
things
like
jack's
calling
out
having
to
set
an
attribute
where
you
get
weird
behavior,
something
like
that
does
make
it.
You
know
that
that
gives
me
bots
right.
D
So
if,
if
it
makes
it
clearer
to
have
a
separate
api,
then
maybe
that
that
that's
better,
you
know
internally,
I'm
kind
of
envisioning
it
as
three
apis
right
like
a
shared
api,
an
event
api
and
then
a
logging
api
that
we
won't
build.
But
I
don't
know
that
that's
anything
other
than
my
own
internal
visualization.
E
I
think
for
me,
I
think
I
slightly
prefer
the
separate
apis
because
of
the
the
usability
point
I
feel
like.
If
you
are
a
user
who
wants
to
emit
events
from
your
code
base,
it's
it's
kind
of,
like
you,
probably
already
have
a
logger
somewhere
that
you're
using
and
then
you
have
to
get
this
other
thing.
That's
also
gotten
logging
in
the
name,
whatever
we
would
call
it
right
and
now
it
just
kind
of
raises
all
these
questions,
like
I
just
feel
like
we're.
E
E
Why
is
it
logging
in
events
like
what's
the
relationship
between
these
two
things,
but
if
it's
just
purely
an
event,
I'm
just
mostly
focused
on
the
naming
here.
If
this
is
purely
an
event
named
thing,
then
I
think
to
the
user.
That's
a
much
simpler
thing
to
engage
with,
even
though,
in
the
end,
it's
gonna
spit
out
log
signals
either
way.
I
feel
it
that's
the
user.
E
That
knows,
I
think,
the
least
about
our
project
and
is
going
to
understand
the
distinction
between
the
two
things,
the
least,
and
so
they
need
to
be
given
the
simplest
possible
thing,
whereas
I
think
people
who
are
log
appender
authors
are
closer
to
the
project.
It's
a
smaller
group
of
people
who
we
can
expect
a
little
bit
more
patience
from
an
understanding
of
what
this
nuance
is
and,
like
you
know
that
that's
kind
of
where
I'm
stuck
on
this.
But
that
said
I.
E
A
That's
a
that's
a
good
point.
Do
you
think
that.
A
A
I
need
to
open
the
pr
that
you
have
the
second
one,
I'm
trying
to
think
of
what
would
be
the
the
same
confusion
around
the
differences
between
tracing
and
events
api
for
someone
who
needs
to
use
the
both
at
the
same
time.
So
you
you
do
what
you
do
you
get
a
give
get
event
emitter
then
van
builder
emit.
A
A
F
F
You
know
that
they
are
the
same,
and,
and
so
we
are,
we
are
going
back
on
on
that
decision
or
the
call
that
was
made
a
few
years
ago
that
they
are
the
same.
A
I
think
we
need
to.
We
need
to
slightly
maybe
maybe
kind
of
reward
that
message
slightly
right
to
say
that
it
is
about
the
data
model
right
from
the
data
model
perspective.
It
is
so,
but
then,
using
that
data
model,
you
can
represent
things
that
people
normally
call
logs
and
people
normally
call
events
right.
So
that's
that's
fine.
I
think
we
can.
Maybe
it
weakens
the
message,
but
that's
the
reality
of
the
situation
right.
We.
A
You
cannot
just
completely
ignore
the
fact
that
okay,
this
differences
do
exist
in
people's
minds
or
whether
they
are
real
or
maybe
I
don't
know
they
are
influenced
by
some
things
that
shouldn't
be
there,
but
they
they
do
exist
right.
So
maybe
that
being
so,
I
guess
strong
in
the
wording
that
they
are
not
different.
D
And
part
of
the
result,
part
of
the
reason
I
think
we're
that
it's
not
different,
isn't
that
there
isn't
any
difference.
It's
that
there's
no
distinction
right,
that
every
time
we
kind
of
try
and
draw
a
line,
somebody
finds
a
reason
that
the
line
isn't
a
good
good
line
right.
So
you
know,
we've
got
log
events
that
are
just
like
console
log,
no
metadata
whatsoever
on
one
side.
D
That's
definitely
a
log
and
you've
got
like
ui
events
on
the
other
side,
that's
definitely
an
event,
but
there's
this
huge
gray
area
in
the
middle,
where
we
use
different
things
in
different
ways
and
so
like
having
a
distinct.
This
is
an
event.
This
is
a
log
is
really
tough,
so
I
think
that's
kind
of
where
this
this
you
know
it's
all
the
same
thing,
because
it
it
encompasses
the
whole
spectrum,
and
maybe
we
can
word
it
that
way.
G
G
F
Now
I
think,
eventually
on
the
wire
you
know
they
will
still
be
called
as
lock
records
right.
I
think
some
people
might
in
the
long
run.
You
know
in
some
corner
of
the
world.
You
know
people
might
still
have
the
confusion
between
these
two.
I
think
that
will
never
go
away
as
opposed
to.
If,
if
they
were
independent
signals,
then
you
know
we
wouldn't
have
to
think
about
any
of
this.
A
Yeah,
that's
also
a
good
argument,
so
you're
saying
somehow
I'm
making
calls
to
events
api,
which
I've
been
told,
is
different
from
logs,
because
it's
a
saturated
api
right
and
somehow
and
it
ends
up
creating
log
records
for
me
out
of
the
sdk,
it
may
be
confusing
right,
so
we're
trying
to
say
you
know
they
are
actually
different.
There
is
a
different
api
just
just
for
events,
use
that
don't
use
the
logs
api,
because
that's
that's
a
different
thing.
A
G
To
the
providers
right
like
the
how
they
get
and
process
the
stream
that's
coming
down
the
pipe
if
they
choose
to
expose
that
to
their
users
that
everything
coming
down
the
log
pipe
is
a
log.
Then,
yes,
that
confusion
is
going
to
exist,
but-
and
maybe
this
is
where
the
domain
comes
in.
If
the
domain
says
it's
an
hotel
event,
then
they
affect
your
hybrid
off
into
a
different
location.
C
I
think
every
user
is
going
to
encounter
that
confusion,
because
there's
going
to
be
a
single
sdk
that
they
can
figure
to
process
log
records
and
events
that
are,
you
know,
even
if
they're
separate
apis
they're,
you
configure
a
single
sdk
to
handle
those,
and
so
you
know
users
can't
hide
from
that
confusion.
They
have
to
configure
the
sdk
to
decide
what
happens
with
those.
A
C
One
thing
I'll
say
is:
like
you
know,
whichever
route
we
go,
I
don't
think
it'll
be
like
a
bad
route.
I
think
you
know
both
are
acceptable,
and
so
you
know,
even
if
I
had
a
preference
and
we
went
the
opposite
direction.
I'd
still
be
like
this
is
fine
yeah.
I
think
the
confusion
will
be
there.
Otherwise.
C
Yeah
they're
either
getting
confused
at
the
api
level
because
they
have
to
choose,
know
to
use
like
one
or
the
other
api
or
at
the
sdk
level.
Where
you
know
you
know,
they're
configuring,
one
sdk
to
handle
two
signals.
G
Yeah,
I
I
would
think
the
confusion
that
the
sdk
level
isn't
there
like,
if
you're
an
application,
developer,
you're
you're
thinking
about
what
you're,
sending
and
you're
sending
traces
metrics
logs
and
events,
the
fact
that
they
have
that
the
events
happen
to
be
transported
as
logs.
You
don't
really
care
about
unless
you've
got
you.
Of
course,
you've
got
the
the
console
logger
and
you
see
them
coming
out.
C
It
could
be
an
sdk
configuration
too
you
could
you
know
in
the
processing
pipeline
before
it
gets
exported.
You
might
want
to
do
different
things
with
events
versus
logs.
A
F
That
is
possible
even
with
with
a
single
api.
A
G
I
I
know
for
app
insights,
like
I'm
the
javascript
web
thing,
we
have
effective,
telemetry
processor,
which
sounds
like
what
you're
talking
about
here
and
effectively.
It's
used
for
everything
like
it
gets
every
single
event
that
goes
past
and
you
you
just
differentiate
based
on
the
name
so
yeah
I
I
don't
see
yeah
if,
as
long
as
we've
defined
the
shape
of
a
log
versus
the
shape
of
events,
so
you
can
look
at
something
in
the
log
record
and
say
this
is
an
event
yeah.
G
G
A
Okay:
let's
let's
do
this,
I'm
I'm
going
to
put
together
a
document
with
all
the
arguments
that
I
I
try
to
remember
what
we
discussed
side
by
side
essentially
to
make
a
comparison
there
and
then,
let's,
let's
see
if
we
can
kind
of
having
the
full
picture,
one
page
will
help
us
to
understand
which
way
we
go
and
then
let's
make
a
decision
one
way
or
another.
I
agree
with
jack.
Essentially
both
ways
are
probably
fine.
We
just
need
to
make
a
choice
and
move
forward
with
that.
A
Probably
we
want
to
maybe
ask
people
who
don't
regularly
attend
this
meeting,
because
it's
primarily
all
the
time.
It's
us
the
same
people
who
are
discussing
this
topic-
and
I
I
want
to
see
if
we
can
bring
some
fresh
ideas
here.
Maybe
some
fresh
eyes
can
help
us
to
get
a
better
understanding
and
then,
let's
maybe
set
kind
of
tentative
deadline
to
make
this
decision
by
the
next
segment
in
next
week
and
then
we'll
move
forward.
That.
G
Sounds
good
one
thing
to
add
to
your
argument
there
from
the
web
sdk
side
of
things
having
a
single
unified
api
would
actually
cause
a
larger
code
if
the
user
doesn't
want
it
so
having
them
separate
would
allow
the
the
user
to
or
the
application
developer,
to
pick
and
choose.
You
know
whether
they
want
the
full
logging
api
or
just
the
event
portion
and
therefore
define
their
their
package
size
for
their
payload.
G
A
Okay-
let's,
let's
maybe
yeah,
let's
do
that.
I
will
share
this
document
with
everyone
here.
If,
if
I
forgot
anything
to
add
to
the
document,
please
do
yourself
if
you
can
remember
anything
else,
please
also
do
that.
Let's
have
that
one
kind
of
two
giant
lists
side
by
side
and
then
we
make
that
comparison
and
we'll
make
that
choice.
A
I
think
this
is
good.
Do
we
have
anything
else
that
we
are
stuck
on,
that
we
need
to
decide
on
the
old
tap?
Is
this
the
only
kind
of
major
blocking
point
there.
B
One
night,
I
actually
have
one
clarification
that
I
wanted
to
ask
about:
does.
Is
it
clear
enough
in
this
old
tap,
what
makes
the
the
semantic
conventions
that
will
make
event
an
event
or
log
record
an
event
like
it
kind
of
hints
at
it
that
there
should
be
the
event
that
name
even
that
domain,
but
we
also
had
discussions
about
like
well.
Maybe
that
should
be.
B
A
I
think
so
far
the
latest,
I
think
I
remember,
was
that
we
are
going
to
have
this
pair
of
attributes.
Event
event.name
and
event.domain
and
event.domain
is
optional,
so
it
may
or
may
not
be
present,
but
event.name
should
always
be
present
if
it's
an
event
right,
that's
the
latest.
I
remember
we
agreed
on.
F
B
F
F
So
if
it's
okay,
you
know
we
could
use
that
terminology
instead
of
domain
category.
A
F
Domain
better,
but
if,
if
as
a
community,
we
are
you
know
aligning
with
pcs,
then
you
know
we
could
choose
the
word
category.
A
A
F
I
think
it's
the
same
right
even
type
is
analogous
to
the
event
name
that
we
have,
because
I
don't
think.
A
F
A
F
So
our
our
one
option
is,
you
know
we
keep
it,
as
is
that
way
like
we,
we
don't
we,
we
are
completely
different
and
not
partially
aligned.
A
Okay,
so
as
soon
as
it's
a
pair
of
attributes,
I
think
we
can
decide
to
call
them
whatever
we
want
name
or
type
versus
domain
and
category.
I
think
it
works
either
way
if
we
want
to
be
aligned
there.
Fine,
I
don't
have
a
strong
opinion
on
this,
because
I
think
we
already
deviated
from
in
in
many
places
from
what
the
elastic
common
schema
does.
Okay
and
so
it
probably
okay,
then.
F
All
right,
I
I
think
in
terms
of
decisions,
I
think
this
is
the
only
one
based
on
the
comments
on
the.
E
F
But
I
I
have
one
more
additional
topic,
not
necessarily
blocking
anything
so
in
in
one
of
the
comments
in
o'reilly
was
asking.
If
we
can
work
with
the
the
original
language,
you
know
library
providers
to
enhance,
you
know
their
existing
event,
apis
existing
logging
apis
to
support
events
and
and
then
you
know,
call
what
we
are
building
now
as
experimental
and
and
then
not
take
it
further.
F
So
if
we
were
to
go
that
route
like
what
are
the
requirements
that
we
should
discuss
with
with
these
folks,
let's
say
is:
it
is
the
appender
technology?
The
the
right
approach
is
that
what
we're
expecting
that
people,
the
libraries,
should
allow
logging
logs
and
events
and
there
should
be
a
transparent
way
to
route
the
messages
to
a
configurable
destination.
A
F
4J
but
let's
say
android
standard
library
has
another
log
library
yeah
they.
I
don't
think
they
have
a
appender
concept.
F
Is
it
is
not
yeah,
it
is
not,
but
like
I
I
want
to
respond
to
him
that
you
know
these
are
the
things
and
we
we
can
make
an
effort.
You
know
you
give
us
the
contacts
and
I
mean
it's.
A
A
F
No,
probably
not
in
the
short
term,
but
let's
say
in
the
long
term,
if,
if
people
were
to
you
know,
evaluate
different
libraries,
then
then
having
open
telemetry
support
in
the
in
that
locking
library
would
be
yeah.
A
F
Sure
complement
yeah
yeah.
No,
I'm
just
only
at
this
point
only
trying
to
understand
the
you
know:
potential
requirement
that
you
know
we
would
put
somewhere
if
the
logging
libraries
were
to
comply
to
that.
C
F
Even
the
logs
itself,
not
just
the
events,
what
what
would
a
logging
library
need
to
do
to
be?
You
know
to
comply
with
open
telemetry
to
make
it
easy
for.
C
E
F
No
I'm
talking
in
terms
of
configurability,
so
should
they
be
having
the
appender
concept,
where
you
know
you
know
it's,
it
is
easy
for
someone
to
route
the
messages
to
any
destination.
Oh
I
see
so
because
that
is
something
I
I
don't
see
outside
of
the
lock4j
kind
of
popular
frameworks.
A
I
think
that's
a
valid
question
to
ask
that
question.
That
riley
is
asking.
I
think
it's
a
valid
question.
I
don't
think
we're
in
the
position
right
now
to
it's
such
a
such
a
big
undertaking.
In
my
opinion,
we're
essentially
we're
saying
we're
going
to
influence
the
entire
industry
of
logging
libraries
in
a
way
that
everybody
is
now
starting
to
write
their
libraries
or
their
apis
to
shape
their
apis
in
a
way
that
is
open.
A
Telemetry
centric,
I
mean
yeah,
that's
that's,
maybe
a
great
goal,
but
it's
such
a
difficult
and
then
complicated
and
difficult
thing
to.
Maybe
you
can
do
that
something
like
that
in
five
ten
years.
I
just
don't
see
that
happening
quickly,
right
so
and
yeah.
I
think
what
jack
said.
If
you
want
to
be
open,
telemetry
centric,
you
have
to
somehow
expose
apis
which
allow
you
to
produce
data
that
confirms
to
open
planetary
data
model.
How
you
do
that
in
your
particular
logging
library.
A
I
I
really
doubt
that
we
will
ever
be
in
the
position
to
have
a
clear
guidance
for
all
of
the
languages
like
do
this
and
and
you're
going
to
be
very,
very
open,
telemetry
centric.
So
I'm
a
bit
skeptical
that
that
we
will
be
able
to
do
that
not
now
at
least
right.
We,
I
don't
think
we
have
that
understanding
at
the
moment,
maybe
sometime
in
the
future.
Yes,.
C
And-
and
one
thing
I
think
riley
is
suggesting-
is
that
you
know,
maybe
we
don't
need
any
ap
an
event
api
if
these
log
apis
can
be
extended
with
events-
and
you
know
I
I
think
I
think
the
point
about
that
being
on
a
probably,
not
possible,
and
if
it
is
possible
it's
on
a
long
time
horizon.
That's
that's
probably
true,
and
if
those
apis
ever
are
extended
to
include
apis
for
producing
events,
then
the
appenders
that
we
write
for
those
apis
can
just
bridge
events
over
to
open
telemetry.
E
A
C
A
B
I
have
I
have
one
one
more
small
topic
to
talk
about.
That's
ready
to
what
I
asked
about
the
event
name.
B
We
had
discussions
in
the
rumsick
about
what
exactly
what
kind
of
values
the
the
event
name
attribute
should
hold,
and
you
know
I
think
there
was
surprisingly
there
was
some
there's
a
little
bit
of
difference
of
opinions
like
there
was
one
that
it
should
have
kind
of
a
enum
based
values
that
are
used
to
classify
the
type
of
the
event,
which
is,
I
think,
this
kind
of
the
traditional
understanding
or
definition
of
event
name.
B
But
there
was
also
you
know
the
opinion
that
maybe
like
we
currently
have
span
name
and
spam
event,
name
which
are
not
defined.
That
way
and
they're
more
defined
as
like
a
description
of
what
happened.
B
That's
used,
maybe
by
backhands
like
to
analyze
or
like
group,
like
you
know,
similar
spans
or
similar
span
events,
but
they're.
Not
those
values
are
not
used
to
classify
like
what
type
of
span
it
is
or
what
type
of
span
event
it
is
whereas,
like
so,
I
think
you
know
in
this
in
this
otap
should
we
make
it
clear
that
event
name
is
actually
used
to
classify
the
event.
A
I
I
think
we
shouldn't
a
lot
of
domains.
Probably
will
choose
to
do
that
right,
so
the
domain
will
say
this
is
the
possible
enumeration
of
the
values
that
you
will
put
in
the
event
name
for
my
domain
right,
so
let's
say
it's
a
browser
domain
and
you'll
say
that
it's
a
dom
event.
Everything
that
is
a
valid
dom
event
name
can
can
be
essentially
an
event
name
in
openclamatry
as
well,
but
that's
a
that's
an
enumeration
right.
A
Essentially,
you
can't
put
three
text
values
there,
but
at
the
same
time
we
don't
control
this
enumeration.
It's
not
it's
a
browser
control
trick
right
that
possible
list
of
dom
events
is
not
under
our
control,
but
also
at
the
same
time,
for
some
other
areas.
Maybe
I
have
no
idea
what
they
want
to
put
in
the
event
name,
and
I
don't
want
to
impose
more
restrictions
than
is
necessary.
Why
do
we
care?
I
mean
we
want
to
put
your
name
there.
Your
your!
I
don't
know
some
description,
free
form,
text.
A
Okay!
Do
that,
if
you
want
to
do
that
as
soon
as
it's
in
your
domain
within
like
because
you
you
choose
a
domain
name
after
that,
you
put
anything
in
the
event
name,
it
doesn't
affect
us
in
any
way.
I
don't
think
we're
going
to
be
doing
any
special
processing
based
on
the
event
name
in
the
open,
telemetry
sdk.
A
It
can
be
maybe
a
user
defined
processing,
yes,
but
not
something
that
is
hard
coded
in
any
way.
So
we
don't
really
depend
on
the
value
set
of
the
event
name
in
any
way
right.
So
we
are
not
interpreting
in
any
way.
We're
not
saying
that
yeah
I
mean
that's,
that's!
That's
how
I
see
it
like
yes
likely
it's
going
to
be
an
enumeration,
but
we're
probably
we'll
probably
can
keep
it
undefined
unspecified
in
the
specification
itself.
A
G
G
B
Yeah,
I
think
it's
just
just
thinking
of
like
the
analysis
of
those
events
ingesting
those
events
and
doing
analysis
on
them
like
in
one
case
like
you,
would
you
would
do
different
things
based
on
the
value,
because
it's
a
different
type
and
in
other
case
like
you,
would
be
looking
at
a
group
of
events?
Well,
maybe
it's
the
same.
I.
A
Don't
know
so
that
would
be
dictated
by
the
semantic
conventions
of
the
particular
domain
right.
So
the
domain
of
browsers
would
say
that
the
event
names
are
going
to
be
dom
events
right
and
then
you
know
it's
a
dom
event.
You
can
do
your
analysis
right.
So
if
it's
another
domain,
then
they
they
can't
say
that
you
can't,
because
we're
going
to
put
anything
we
want
there,
some
random
strings
people's
names,
whatever
I
don't
know
right.
So
in
that
case
you
cannot
do
the
analysis.
G
I
I
assume
this
is
driven
from
the
validation
discussions.
We've
had
martin
yeah.
G
These
are
the
expected
fields
that
we
will
define
in
the
semantic
conventions
and
therefore
we
just
validate
those-
and
I
think
the
the
the
validation
portion
should
be
optional
in
terms
of
how
or
if
the
developer
wants
to
play
with
it,
or
the
back
end
wants
to
do
that
so
because,
at
the
end
of
the
day,
we
do
want
to
support
customer
events
as
well.
C
So
so
one
thing
I'm
thinking
about
as
this
conversation
is
taking
place,
is
what
would
what
would
be
the
fallout
if
somebody
defined
their
own
domain
and
added
event,
names
that
were
uuids,
like
you
know,
as
high
cardinality,
as
you
can
get,
is,
would
that
break
down
anything
in
the
you
know
it.
C
You
know
like
like
tiger
mentioned
in
sdk,
probably
not
since
we're
not
interpreting
these
names
in
any
way,
but
like
let's
say
there
are
like
processors
in
the
collector
that
want
to
do
certain
things
with
events
and
I'm
not
trying
to
imagine
what
those
are
today
would
having
like
unbounded
cardinality
impact
anything
down
the
pipeline.
C
A
I
guess
that
we
will
want
to
specify
whether
it's
unbounded
cardinality
or
we
do
restrictions
on
the
cardinality,
so
that
whoever
does
the
analysis
and
storage
and
all
that
stuff
can
have
some
sort
of
expectations
around
that.
My
gut
feeling
would
be
that
it's
unbounded.
Essentially,
we
can't
make
assumptions
about
this.
Being
some
very
limited
set
of
values
be
prepared
like
like
it
is
for
in
the
logging
world
right,
it's
really
no
no
bounds
of
the
cardinality
there.
So,
similarly,
here.
C
So
we
can
give
general
recommend,
so
you
know
this
event
name
if,
if
this
manifests
us
an
attribute
that
has
semantic
inventions
around
it
at
some
point
we're
going
to
have
to
describe
what
the
semantic
inventions
are
like.
C
You
know
what
what
is
the
description
of
the
the
values
for
event.name
and
I
guess
what
we
can
do
at
that
point
is
we
can
give
general
guidance
that
says
you
know
this
is
a
classification,
an
enumeration
of
the
events,
or
this
is
normally
an
enumeration
of
the
different
types
of
events
that
happen
in
a
particular
domain.
C
But
we
don't
need
to
guarantee
that
and
we
I
guess
we
can
inform
that
there
is
no
guaranteed
bound
on
on
the
cardinality.
For
that
to
you
know,
allow
consumers
of
those
to
anticipate
that
and
not
try
to
design
around
some
ceiling
of
cardinality.
G
Yeah,
I
I
think,
probably
in
the
spec,
you
know
to
use
the
the
wedding
there.
This
is
where
we
say
this
should
be
of
low
cardinality,
so
yeah
don't
use
a
uuid,
but
at
the
end
of
the
day
it
really
boils
down
to
what
their
pipeline
is
configured
all
the
way
to
their
back
end.
G
Like
if
they're
like,
to
extend
what
you're
saying
it
if,
for
some
reason,
there's
a
processor
that
creates
metrics
on
the
number
of
events
that
are
going
past,
based
on
the
name,
for
example-
and
it
creates
histograms
and
you
know-
go
goes
berserk.
If
you've
got
high
cardinality,
then
you
think
you've
got
a
whole
bunch
of
metrics
with
that
name
of
one.
So
yeah
exploit
the
memory
yeah.
C
And
to
extend
your
thought
a
bit,
so
the
words
should
so
under
normal
circumstances.
This
this
does
have
you
know
a
reasonably
low
cardinality,
but
it's
not
a
must
and
in
back
end,
should
be
prepared
for
for
high
cardinality.
Accordingly,
yep.
G
So
maybe
we
add
words
in
there.
The
back
ends
may
choose
to
effectively
script
or
something
I
don't
know
comes
back
to.
The
should
may
must
discussions.
A
Let's,
let's
maybe
let's
try
not
to
overdo
we
are.
I
don't
want
us
to
start
building
the
specification
on
the
old
tap
all
right,
let's,
let's,
let's
start
small,
the
more
we
put
in
the
otp
there,
the
more
opposition
and
critic
we're
going
to
see
from
other
people
and
the
more
difficult
it
is
going
to
be
to
merge
to
the
specification.
Let's
try
to
move
incrementally
here.
It
is
going
to
be
easier,
so
we're
we're
merging
to
experimental
section
of
the
specification.
A
Let's,
let's,
let's
try
to
at
least
once
we
decide
on
the
api.
Let's
move
that,
then
we
can
think
about
the
semantic
conventions,
then
about
cardinality.
These
are
all
very
good
questions,
but
I
I
feel,
like
we
shouldn't,
be
trying
to
put
all
of
them
and
solo
them
in
a
single
autopsy,
which
is
a
thought
that
will
take
a
year
to
to
finish
right.
So,
let's,
let's
try
to
avoid
that.
A
A
Okay,
good
anything
else,
any
topics.