►
From YouTube: 2022-05-04 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
A
Okay,
so
let's
start
the
log
stability,
I
think
we're
ready
now
to
declare
it
stable.
I
don't
see
any
blockers,
so
I
converted
it
from
draft
to
a
regular
pr.
A
Then
we
need
approvals
from
the
log
approvers
log
spec
approvers
here
to
merge
and
I'd
probably
keep
it
open
for
a
few
more
days,
maybe
just
in
case.
There
are
any
objections
I
don't
expect,
but
just
to
be
safe
and
maybe
then
we
can
merge
it
next
week
and
declare
it
stable.
A
B
Okay,
so
looks
api
yeah.
Let
me
share
my
skin,
so
I
started
writing
up
the
api
specification
following
what's
there
today
for
the
trace
api,
there
are
still
a
few
things
left
and
I
have
some
questions.
Let
me
share
my
screen.
B
B
In
the
industry,
I
think
it
is
logger
is
a
more
common
term.
More
commonly
used,
so
is.
Is
there
a
preference
or
a
suggestion
on
so.
A
A
A
B
It
in
my
opinion,
it
will
be
confusing
to
use
two
terms,
so
I
think
the
one
other
consideration
is.
If,
if
people
have
already
used
the
the
log
sdk
for
building
the
appenders,
then
they
they
might
have
to
change,
but
I
ideally
if
we
had
not
introduced
the
apis
now,
if
let's
say
it
was
there
from
the
beginning,
you
know
you
would
have
kept
them
together
right.
You
know,
aligned.
A
So
the
logging
library
sdk
that
we
created
it
was
that
the
target
audience
for
that
was
developers
of
logging
libraries.
It
was
not
intended
to
be
exposed
to
end
users,
users
right.
So
if
we
do
this,
if
we
do
as
you
suggest,
then,
if
we
have
a
single
api
which
is
end
user
facing
then
logging
library
developers
will
also
depend
on
this
api
yeah.
We
consider
that
the
right
approach-
I'm
I'm,
not
quite
sure
what
would
be
the
right
thing.
A
C
Yeah,
I
I
would
agree
with
you
I
I
don't
think
this
should
be
part
of
the
standard
logging
api
that
that
logo
panda
providers
should
be
implementing.
I
actually
see
this
as
something
extra
that
we
have
on
the
side.
That's
the
this
is
effectively
the
event
api,
which
happens
to
use
the
logger
as
the
transport.
So
we
say
this
is
the
event
logger,
as
opposed
to
the
logger,
or
something
like
that.
D
What
do
I
just
think?
I
think
we
really
really
really
don't
want
to
get
bogged
down
in
trying
to
build
another
slf
or
jay.
So
I
think
anywhere
that
there's
kind
of
an
ambiguity
is,
would
you
use
this,
or
would
you
use
that
we
need
to
be
real,
careful
and
kind
of?
D
B
So
I
I
I
think
there
was
a
you
know,
discussion
on
that
here.
I
think.
Maybe
you
should
go
through
it
sometime,
but
I
think
there
was.
It
was
pointed
out
that,
yes,
at
least
for
java
definitely
this
will
be.
B
It
will
be
unlikely
that
you
know
people
will
use
the
open
telemetry
apis
for
for
the
original
logging
purposes,
but
I
thought
there
are
use
cases
or
there
are
interfaces
that
the
current
logging
apis
you
know
do
not
provide
and-
and
I
think
the
most
important
one
or
maybe
the
only
one
is-
is
the
ability
to
specify
attributes
that
the
current
log
apis
you
know
they.
I
am
not
aware.
A
E
A
D
I
don't
remember
about
the
standard
logger,
but
the
you
know
both
slr
for
j
are
log
back
specifically
and
and
log4j
both
do
allow
you
to
do
it,
but
it's
in
ways
that
aren't
immediately
obvious.
B
So
lock
4g
has
this
something
called
event
logger
and
they
use.
You
can
send
a
structured
data
message,
but
even
this
message
doesn't
have
any
key
value
things:
okay,
value.
You
can
only
specify
a
message
and
under
type
I
think
the
type
could
be
mapped
to
the
event
type,
but
it's
still
a
string
message.
B
A
D
A
A
It
has
its
purpose,
but
it's
not
about
making
it
easy
to
emit
structured
logs.
Every
single
one
of
them
may
have
a
very
different
set
of
attributes.
That's
not
the
api
that
you
would
use,
in
that
case,
right,
yeah,
and
so
for
that
use
case
where
you
actually
are
emitting
something
on
which
you
need
to
set
every
time
some
set
of
attributes
and
these
attributes
may
be
different.
E
That
re,
that
reflects
the
javasig's
opinion
as
well,
so
we
we-
we
spoke
about
this
in
our
last
sig
meeting
and
you
know
the
consensus.
Is
that
an
event
api
is
great
and
that
we
really
don't
want
to
build
a
log
api,
an
application
log
api
and
that
an
event
api
does
fill
a
gap
that,
in
terms
of
what's
available
today,
okay.
E
So
there
are
kind
of
two
distinct
use
cases,
there's
application
logs
and
events
and,
as
we
were
talking
in
the
javasig,
we're
trying
to
you
know,
articulate
the
difference
between
them,
and
I
think
we,
you
know
we
did
a
decent
job
of
convincing
ourselves.
What
the
difference
is
between
application,
logs
and
events.
So
you
know
application
logs
are
characterized
by
having
a
message
and
a
severity.
E
In
addition
to
all
the
shared
properties
between
events
and
application,
logs
and
events
are
characterized
by
having
some
sort
of
name
space
in
a
type,
and
you
know
a
bag
of
attributes,
and
are
you
know
they?
They
don't
have
a
message,
and
so
those
kind
of
those
are
the
distinctions
between
the
two
and
you
know,
they're.
They
have
enough
in
common
that
we've
chosen
to
model
them
in
the
same
way
in
otlp,
but
that
doesn't
necessarily
mean
that
we
need
to
have
a
single
api
to
capture
both.
E
B
Well,
that's
a
tricky
right,
I
think
so.
So
I
think
the
distinction
is
very
minor
like,
for
example,
you
mentioned
that
the
events
should
not
be
using
body.
Let's
say.
Let's
say
we
decide
that
all
the.
B
E
B
A
requirement
yeah,
I
think
android
uses
the
java
sdk
java
apis
open,
telemetry
java.
So.
E
B
Yeah,
so
in
that
case,
when
the
android
for
the
purpose
of
android,
when
we
add
these
apis,
they
will
be
added
to
the
you
know.
This
open,
telemetry,
java,
repo
and
the
question,
is
you
know
what
would
you
call
it?
Would
you
continue
to
call
it
as
a
logger
interface,
or
do
you
want
to
call
it
by
different
name?
We.
E
Would
we
would
call
the
api
we
in
refer
to
things
with
event
oriented
language?
Is
that
that's
what
we
would
hope
to
achieve
so.
E
We
want
to
want
to
have
a
logger
which
is
associated
with
traditional
log
apis.
We,
you
know
in
to
have
as
much
symmetry
with
the
log
sdk
that's
been
proposed
right
now.
Maybe
we
have
an
event
emitter,
something
along
that
those
lines.
D
B
B
You
know
there
are
reasons
why
you
know
it
might
be
helpful,
but
then
you
know
maybe
people.
D
Won't
be
using
it,
so
I
think
one
way
that
I
would
look
at
this
then,
or
maybe
it
would
help-
is
to
look
at
this
as
an
intermediate
api
right.
So
if
I
were
going
to
go,
implement
a
log
for
jx
porter,
what
is
the
api?
I
would
like
to
use
to
implement
that,
because
that
exporter
is
going
to
be
exporting
log
events
and
there's
a
there's,
a
huge
overlap
there
right
so
at
that
level.
D
B
Yeah,
so
I
think
tigran
has
some
comments
where
here,
like
the
greenfield
deployments,
you
know
may
want
to
have
you
know
full
instrumentation
with
signals,
including
lock,
so
in
that
case,
having
everything
consistent
with
the
hotel
apis.
So
there
are
languages
where
there
is
no
single
popular
framework.
Right
in
in
that
case
is
another.
B
A
I
interject
for
a
second.
I
guess
I
want
to
reply
to
what
david
was
saying
about
the
intermediary
level
api.
What
you're
describing
is
what
we
have
in
the
login
library
sdk
right
log
emitter
provides
that
it
is
essentially
built
purpose
built
to
make
it
ergonomic
to
implement
exporters
appenders
or
whatever
they
are
called.
D
A
D
Right,
you
know
I,
I
guess
I
I
think
we
should
look
at
this
from
from
use
cases
right
like
what
are.
What
are
the
events
we
want
to
create
from?
What
like
is
this
a
you
know?
We
want
to
create
a
set
of
events
from
a
system.
What?
How
is
this?
How
is
the
api
that
we
have
failings
and
then
we
build
whatever
that
level
is
on
top
of
that,
that
makes
that
easy.
D
A
A
It
may
be
that
the
log
emitter,
if
we,
if
we
rename
it
whatever
we
give
it
the
name-
I
don't
know
logger
or
event
events
or
whatever,
let's
not
focus
on
that
specific
name,
but
if
we
call
it
an
api
that
is
end
user
facing
but
can
also
be
used
for
implementing
dependers
does
it
that
would
it
not
work?
What
what's
what's
wrong
with
that
approach.
C
I
would
think
you're,
then
forcing
appenders
to
go
and
implement
it.
So
another
way
to
look
at
this
is
the
events.
Api
only
needs
to
be
implemented
in
languages
that
support
client-side
telemetry,
which
is
where
the
where
the
events
are
are
effectively
coming
from.
So
not
every
language
will
need
or
want
this
api.
B
C
There
are
yeah
I
I,
which
is
why
I
said,
necessarily
want
or
need.
So
there
are
some
cases
where
they
may
want
to
do
it
and-
and
you
know,
hey
presto-
go
ahead,
but
it's
not
from
the
client
right
from
the
rom
sig,
which
is
where
this
is
coming
from.
We're
not
saying
this
must
be
be
implemented
in
every
single
language.
A
C
A
A
D
Right
so
so
I
think
kind
of
what
I,
what
I'm
trying
to
say
is
if
we
take
a
look
at
like
the
rum
use
case
right
where
we're
trying
to
send
events-
and
we
forget
all
of
the
open,
telemetry
machine
that
we've
got
already
and
we
forget
about
all
about
logging.
What
does
that
api
look
like
what
do
we?
How
do
we
want
to
be
able
to
create
those
events
and
send
them
if
we
take
that?
How
do
we
like?
D
But
if
we're
looking
at,
how
do
we
wrap
all
of
our
existing
logging
api
for
all
of
our
use
cases,
then
we're
going
to
start
eating
slr
for
j
and
log
for
j
and-
and
I
don't
think,
there's
any
use
for
that
so
like
if
we
can
take
a
look
at
exactly
you
know
this
log
log
or
the
sorry,
this
event
emitting
use
case
figure
out
what
we
want
it
to
look
like
and
then
figure
out
how
to
either
extend
what
we've
got
or
build
layer
on
top
of
it.
I
think
that's
really.
A
B
Yeah,
but
I
think
that
is
something
we
are
saying
in
this
call,
but
in
the
last
meeting
and
in
the
discussion
on
in
that
google
doc,
I
got
a
feeling
that
you
know
there
might
be
some
languages
where
having
an
api,
you
know
would
not
be
a
bad
idea,
so
in
that
case
the
api
interface
should
fit
the
logs
application
logs
use
case
as
well.
B
D
Yeah,
but
I
think
so
I
think
we're
looking
at
the
minimum
that
everything
has
to
support
right.
So
if
we
say
that
our
logging
interface
includes
a
debug,
then
even
java
has
to
have
it,
but
if
we
don't
say
that
it
has
a
logger.debug
and
we
decide,
we
really
want
it
in
python.
There's
nothing
to
say.
We
can't
add
that
to
the
sdk
there.
B
Yeah,
so
I
think
the
bigger
question
is,
you
know:
do
we
want
a
logs
api
or
are
only
an
events
api?
I
think
that
will
address
the
interface
definition.
E
D
E
A
I
think
it's
difficult
to
make
that
judgment
unless
we
see
the
actual
events
api.
What
is
it
that
it
looks
like
how
is
it
different
from
a
logging
api,
the
application
logging
api?
Why
is
it
not
good
enough?
It
may
be
unfamiliar
it
may
be.
It
may
look
very
different,
but
it
may
turn
out
to
be
quite
suitable
in
the
end
for
application
logging.
Who
knows
unless
we
actually
see
that
it's
it's
hard
to
tell
I
don't
know,
can
we
make
an
iteration
to
actually
have
this
call
it
events
api?
A
C
I
I
think,
simplistically
what
santos
got
on
the
screen
here,
like
59
362,
that
is
the
api.
You
know
the
major
difference
we're
talking
about
here
is
like
the
logging.
One
wants
a
severity
attacked
onto
this
information
so
that
that's
where
we're
having
this
discussion,
the
fact
that
events
don't
have
us
a
very
they're
just
an
event.
C
Fast
forward,
yeah
we're
just
saying
immune
event,
either
just
by
name
or
with
attributes.
E
And
I
would
argue
you
know
that's
what
I
agree
with
as
well,
but
I
would
argue
that
the
last
two
methods,
61
and
62,
where
you
specify
timestamp,
is
inconsistent
with
our
other
apis
but
otherwise
agree.
E
Want
to
understand
that
the
time
stamp
for
you
know
when
you
record
a
measurement
from
the
metrics
api
or
when
you
initialize
the
span
from
the
trace
api,
the
the
time
stamps
are
derived
from
the
clock
that
you
associate
with
the
system.
So
you
don't
set
it
in
the
api.
It's
just.
B
I
I
picked
it
up
because
the
the
trace
api
has
these
like
when
you.
C
There
are
some
client
use
cases
like
in
a
browser
when
you
have
a
page
view
event
like
the
javascript
sdk
asynchronously
initializes.
You
actually
want
to
record
the
original
time
that
that
is
occurred
that
you're
pulling
out
of
the
browser
metrics
rather
than
the
count
clock
time,
because
there's.
B
Nothing
I
took
it
from
here
like
on
a
span.
When
you
add
an
event,
you
don't
automatically,
I
mean
there
are
options.
Basically
I
I
took
this
from.
E
B
Maybe
I
think
it's
possible
that
there
are
the
times
actually
on
the
receiver
and
the
telemetry
back
end.
You
know
there
are
situations
where
things
get
buffered
and
therefore,
by
the
time
the
event
gets
to
you.
You
know
we
have
multiple
time
stamps
right
the
time
when
the
event
was
generated,
the
time
when
the
event
was
received,
the
time
when
the
event
gets
actually
processed.
So
we
have
multiple
times
time.
So
I
think,
having
an
explicit
api
to
set
the
time
enables
such
use
cases.
E
A
Timestamps
one
is
so
if,
if
you
receive
the
event,
if
you,
if,
if
it's,
if
it
happened
somewhere
outside
open
telemetry-
and
you
learned
about
it,
then
the
timestamp,
when
you
learned
about
the
fact
of
existence,
may
be
different
from
when
it
actually
happened.
That
is
why
you
may
have
two
two
different
timestamps
recorded
there.
One
is
the
original
timestamp
and
the
second.
E
Yeah,
so
you
know
in
that
case
I
I
think
that
so
one
of
those
time
stamps
should
always
be
computed
automatically.
So
it's
the
time
stamp
one!
You!
You
invoke
the
api
and
the
other
the
that
time.
Unix
nano
166,
that's
that
one!
You
know
you
could
set
via
an
additional
property.
Your
argument.
A
A
So
this
this
api,
the
the
one
that
you're
showing
let's
say,
for
example,
we
agree
on
these
four
methods
or
whatever.
What
would
the
implementation
of
this
look
like?
Would
it
would
it
call
the
log
emitter
sdk
from
from
the
sdk
that
we
have
now,
because
it
would
be
very
simple
to
do
that?
Actually,
right,
you
build
a
log
record
here
and
and-
and
you
don't
need
to
do
anything
special
other
than
that,
so
the
implementation
would
be
very
simple
if
you,
if
there
is
already
a
logging
library,
sdk
implementation.
E
A
E
Yeah
so
just
like
at
a
conceptual
level,
the
log
sdk
is
what
you
use
as
the
author
of
a
logging
library
to
to
bridge
into
open,
telemetry
and,
and
in
our
case
the
event.
Api
is
just
another
thing
that
needs
to
be
bridged
into
open
to
the
country.
A
Yeah,
I
think
so
well,
it
happens
that
both
ends
are
open
telemetry
in
this
case
of
the
bridge,
but
yeah
you're.
Essentially
there
is
a
low
level
log
emitter
api,
on
top
of
which
you
can
build
your
your
other
abstractions.
One
of
the
abstractions
is
the
open,
telemetry
events.
Api
other
abstractions
are
the
log
for
js,
appender
or
whatever
right.
A
C
Yeah
and
I
guess
if
we
just
call
this
the
event
api
for
one
of
a
better
name
and
then
it's
you
know
effectively
injected
with
the
the
logo
meter
and
then
provides
these
methods.
Yeah.
A
B
So
so,
to
recap:
we're
suggesting
that
there
could
possibly
be
two
different
apis
events,
api
and
logs
api
and
even
cpi
would
come
first
locks.
Api
will
differ
until
we
really
see
use
cases
and
then
both
of
them
will
use
the
log
record.
Emitter
sdk,
I
think
so,
and
the
appenders
will
continue
to
use
the
sdk
directly.
E
C
B
Okay,
I'm
just
curious.
So
nev
do
you
know
if
the
browser
side
javascript
logs
are
is?
Is
there
a
used
required
product
requirement
to
get
those
logs
into
the
back
end
for
delivery.
C
Not
currently,
there
is
a
diag
logger
that
I
implemented
for
the
js
sdk,
with
the
intent
that
I
modeled
it
very
much
on
log4j
in
terms
of
how
it
looked
it
got
twisted
a
little
bit,
but
that's
fundamentally
what
it
is,
so
the
intent
would
be
rather
than
the
con
the
current
console
logging.
Once
we
get
the
logging
api
into
javascript
for
node
anyway,
it
would
hook
up
that.
E
C
C
Yeah
unrelated
to
console
logs
correct
you
don't
really
want
to
grab
the
we
could,
but
the
console's
not
always
there,
depending
on
the
browser,
so
it
gets
messy
because
the
browser,
if
the
f12
is
up
the
console
exists.
If
the
f12
is
not,
it
doesn't
in
some
cases.
A
C
C
I
I
think,
all
chromium-based
ones
now
I
think
the
console's
always
there
it
just
does
nothing
but
yeah
in.
I
don't
remember
the
version,
it's
probably
a
version
of
ie.
I
have
a
very
long
history
of
browsers
that
had
that
pain
point
you
always
had
to
check
to
see.
If
console
was
there
before
you
used
it.
B
Okay,
okay,
actually,
the
reason
I
was
asking
is:
do
all
language
log
apis
have
concept
of
appenders
like
in
when
there
is
no
such
thing.
What
is
the
mechanism
recommended
to
translate
those
logs
into
your
tail.
C
But
I
think
all
the
languages
I've
played
with
everyone
has
their
own
apis.
There
is
like
log
for
j
added
the
appender
stuff
for
java,
like
way
back
in,
like
version
one,
I
think
it
was
when
I
was
playing
with
java
last
net
didn't
have
its
own
until
recently,
like
recent
years
c,
plus,
plus
there
is
nothing
you
drag
in
your
own.
B
Existing
apps
that
are
already
in
production,
the
appenders,
let
you
easily
pull
the
logs
into
otp
right
so
without
making
changes
to
the
application.
If
we
were
to
get
those
locks
into
otlp
the
you
know,
the
way
is
to
let
them
go
into
standard
output,
our
files
and
then
take
it
from
there.
I
guess
is
that
the.
A
Very
language,
language,
specific
and
and
in
many
languages
it's
very
specific
to
the
particular
logging
library
in
c
plus
plus,
for
example,
I
mean
there's
boost
log.
You
could
use
that
I
and
that
there
is
a
way
I
think,
to
override
where
it
goes
to,
but
I
don't
think
it
looks
anything
like
the
look
for
j's
offenders.
A
My
understanding
is
some
language
is
adopted,
similar
concepts
like
the
ones
that
exist
in
java,
some
other
languages
don't
and
it's
there
is
a
huge
variety.
As
far
as
I
know,
I
mean
how
these
things
work
in
different
languages
and
in
different
logging,
libraries,
it's
very
standardized
kind
of
in
java
world,
not
so
much
in
other
languages.
From
what
I
understand,
I
can
go,
for
example,
even
right,
but
there's
a
bunch
of
logic,
libraries
that
they
don't
really
look
like
similar
things
quite
different.
B
Okay,
okay,
so
I
we
can
want
to
my
other
question.
So
let's
ignore
the
b
so
the
this
question
I
I
want
to
understand
so
now
now
that
I
think
we
are
beginning
to
you
know,
make
it
concrete.
What
an
event
looks
like
how
events
differ
from
the
logs
in
the
in
terms
of
how
they
use
the
underlying
data
model.
B
B
So
should
this
space
explicitly
called
out
in
the
spec,
because
I
see
ebpf,
you
know
folks
have
used-
have
put
their.
B
Key
value
pairs
in
the
body
so
just
to
avoid
confusion
in
the
long
run,
should
the
spec
explicitly
call
out
this
thing
that
has
been
implemented
in
the
api.
A
Yeah,
I
think
I
think
the
spec
can
make
the
generic
recommendations
like
what
you
said.
Don't
put
key
value
pairs
in
the
body
put
them
in
the
attributes.
The
generic
recommendations
like
that
can
be
in
the
stack.
The
specific
shape
of
the
log
record
should
be
part
of
the
semantic
conventions
for
that
business
domain.
So
for
rom,
you
would
have
semantic
conventions
about
what
the
ram
events
look
like.
What
are
the
attribute
names?
How
do
you
record
them?
What
are
the
values?
A
Do
you
put
anything
in
the
body
or
you
don't
like?
How
does
how?
How
are
the
ram
event
represented
as
all
open
planetary
wall
records?
Same
would
be
done
for
the
ebbf
same
for
profiling,
so
for
every
business
vertical
for
every
domain,
you
would
have
a
set
of
semantic
conventions.
That
say
this
is
how
the
log
records
should
be
shaped.
A
A
I
guess
the
question
here
is:
do
you
hard
code,
those
any
of
those
semantic
conventions
in
the
events
api
that
you
want
to
have?
If
your
events,
api
is
targeted
specifically
just
for
the
ram
use
case,
you
would
want
the
the
the
conventions
to
be
also
part
of
the
implementation
right.
I
think,
but
if
you
want
the
events
api
to
be
generic,
then
you
can't
in
that
case
yeah.
I
think
the
only.
B
Yeah,
I
think
the
only
and
in
fact
that's
something
we
we
should
also
discuss
and
agree
upon.
Is
you
know
the
the
name
of
this
attribute?
That
represents
the
event
name.
What
should
that
be?
You
know,
can
it
be
this
hotel.even.name.
E
Well
in
on
a
related
note,
I
maintain
that
you
don't
just
want
an
event
name.
You
want
some
sort
of
namespacing
function
so
that
you
can
reduce
collisions
between
different
types
of
event,
systems
that
use
the
same
names.
C
E
E
C
A
B
Yeah
yeah,
no,
actually,
if
we
had
not
put
this
hotel
prefix,
I
I
would
agree
with
jack
that
you
know
people
might
have
even
dot
name
is,
is
very
generic.
You
know
it's
quite
likely.
I
mean
there
are
possibilities
for
somebody
to
have
this
as
one
of
the
attributes
and
and
by
prefixing
with
hotel.
B
A
So
in
the
past
we
used
the
hotel
prefix
when
we
needed
to
represent
an
autumn
telemetry
specific
concept
somewhere
else
outside
open
telemetry.
So,
for
example,
when
we
export
to
zipkin
or
jager-
and
we
need
to
put
some
data
which
is
very
open,
telemetry
specific-
it
doesn't
have
an
equivalent
concept
in
zipkin
or
jager.
A
A
E
A
B
Yeah,
I
think,
in
that
case,
jack's
concern
is
valid
right
where
you
know
and
and
jack.
You
know
it's
not
always,
since
it's
not
always
rum,
it's
possible
that
you
know
today's
event
systems
you
know,
might
already
be
emitting
events
with
with
some
of
the
names
it's
possible
that
there
could
be
collision
because
events
is
even
dot
name
is,
is,
is
there's
nothing
specific
about
it.
Yeah.
E
And
I
anticipate
events
being
emitted
for
a
wide
variety
of
systems
in
the
future,
not
just
from
systems,
and
so
you
know,
but
I
think
I
think
ned's
point
was
that
the
the
name
itself,
the
value
of
the
name,
contains
information
that
allows
you
to
disambiguate
yeah.
C
Yeah,
I
I
I'm
convinced
by
both
arguments.
So
today
we
could
have
log
appenders
that
are
logging
things
that
may
be
saying
event.name,
and
we
don't
want
to
clash
with
that.
So
I'm
yeah,
if
if
we
actually
call
the
the
the
attribute
name,
hotel.event
name
that
that
solves
that
problem,
but
I
you
know
we
still
need
the
actual
name
of
the
event
to
be
namespaced
as
well.
C
A
C
A
C
Be
probably
like
web.click
or
web.pageview
client.click
client.navigate,
you
know,
there's
a
whole
bunch
of
things
like.
C
By
a
specific,
no,
no
just
the
value
of
the
name,
so
so
we
we
say
hotel,
event.name,
fred,
and
then
we
have
its
data
and
we
we
define
the
what
that
data
looks
like.
So
if
so,
when
the
back
end
sees
fred,
it
says:
okay,
I'm
expecting
these
fields
here
and
then
it
goes
and
pulls
them
out
and
populates
them.
And
when
I
say
fields,
I'm
talking
about
the
actual
value
of
the
data
will
be
a
blob.
C
It
won't
be
a
string
and
if
there
are
multiple
attributes,
there'll
be
very
few
of
them,
because
most
events
will
have
will
be
a
hierarchy
of
some
kind.
A
Okay,
can
you
guys
put
that
into
some
sort
of
a
document
where
we
can
read
and
discuss,
because
this
is
yeah?
This
is
good,
but
yeah
more
substantial
discussion
is
needed.
I
believe.
E
And
I
think
one
thing
that
nev
mentioned
that
you
know:
I'm
not
sure
it
was
fully
like
grasped,
and
maybe
I
just
need
to
restate
for
clarification
purposes,
but
he
was
saying
something
along
the
lines
of
existing
event
systems
that
want
to
map
to
use
our
event.
Api
to
you
know,
you
know,
map
those
events
over
into
open
telemetry.
What
do
they
put
for
those
event?
Names
if
we're
saying
that
the
event
name
itself
contains
the
information
needed
to
disambiguate
so
like
how?
B
B
Events
like
who
sends
what
are
the
event
systems?
You
know
that
that
emit
events
so.
C
It
was
it
spans,
or
I
remember.
E
C
Mentioned
it
and
when
we
talked
about
that,
there's
a
set
of
known
or
defined
prefixes
for
different
vendors.
And
that's
really
what
I'm
talking
about
here
as
well.
B
B
So
so
this,
despite
that,
I
think
it's
possible
that
you
know
you
you
pin
down.
You
know
which
of
the
fields
from
the
existing
systems
maps
to
the
event
name,
but
it
doesn't.
You
know,
exclude
the
possibility
of
an
another
attribute
in
their
bag
of
attributes
to
have
even
dot
name
as
one
of
the
key
value
pairs.
E
Yeah,
like
an
alternative,
take,
is
to
say
that
the
scope
of
events,
so
the
the
namespace,
whatever
you
want
to
call
it,
it's
an
important
enough
concept
that
we
make
it
that
we
make
it
a
separate
top-level
field
and
a
required
argument.
E
E
So,
like
you
know
in
in
that
case,
going
back
to
the
the
the
the
use
case
about
clicking
in
a
browser,
so
the
event
type
would
be
click
and
the
event
name.
Space
would
be.
You
know,
client.browser
or
whatever.
B
But
today
that
would
go
as
a
prefix
to
every
attribute
client.browser.
E
Right
and
but
it
would
go
to
a
prefix
to
every
attribute,
which
means
it's
that
it's
easy
to
omit.
So
if
you're
not
familiar
with
those
standards,
you
could
easily
omit
those
that
prefix
and
so
that's
that's
kind
of
an
argument
against
that.
E
B
A
So
guys
I
have
to
drop
off
sorry.
So
will
you
please
post
the
the
refined
api,
the
events
api,
the
shorter
version
of
it
and
then,
let's,
let's
open
the
discussion
for
the
semantic
conventions,
what
they
look
like
for
the
events
sounds
good
yeah.
Okay,
thank
you
guys,
bye.