►
From YouTube: 2022-05-11 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
A
Yeah
there
is
a
document
and
let
me
post
the
link.
If
you
haven't
seen
it,
we
don't
have
the
link.
A
A
That's
that's
fine!
That's
fine!
So
I
guess
before
we
do
that
otp
locks
proto
is
now
stable,
which
is
great.
I
think
it's
an
important
milestone.
C
Yeah
I
haven't
yet
gotten
a
chance
to
review
all
the
comments
you
put
digren,
but
I
think
I
saw
that
you
suggested
using
the
term
logger
I'll
make
that
change.
A
Yes,
that's
one
of
the
things.
I
think
it
would
be
useful
just
to
keep
it
more
consistent
or
uniform
with
what
we
do
with
trace
thing
and
metric
api.
We
have
tracer
meter
logger,
I
think,
fits
well.
It
also
doesn't
sound
wrong.
I
mean
you
can
because
you
also
wanted
to
name
the
method
log
event
right,
so
you
can
say
logger,
dot,
log
event,
something
like
that
and
also
it
keeps
the
door
open
in
the
future
throughout
other
logging
related
apis.
C
Okay,
I
I
wanted
to
know
why
the
sdk
was
called
log
emitter,
not
a
logger.
A
I
didn't
want
to
hijack
the
name.
I
didn't
want
to
use
it
because
it
does
something
different.
So
I
think
so.
I
posted
a
diagram
there.
If
you
scroll
down,
can
you
go
down
in
your
document
a
bit?
There
is
there's
a
diagram
that
I
posted
as
a
suggestion.
More
more
a
bit
more.
A
A
I
think
that
needs
to
stay
in
a
sense
right,
because
that
that's
what
the
offenders
and
other
external
logging
libraries
are
going
to
use,
but
maybe
we
rename
it.
I
don't
know,
but
this
remains
the
kind
of
the
low
level
api
for
creating
log
records,
essentially
right,
whether
it's
called
emitter
or
something
else.
I
don't
know
it's
right
now:
it's
called
log
emitter
and
log
emitter
provider.
A
Maybe
we
rename
it
to
log
log
record
emitter
just
to
make
it
even
more
clear
that
this
is
kind
of
the
only
purpose
of
it
is
to
just
emit
the
log
records
right
and
then
the
implementation
of
the
log,
api
or
events
api
uses
that
it
doesn't.
I
mean
it
doesn't
r
yeah
it's
hard.
C
A
So
we
have
this
distinction
of
api
and
sdk
writing
in
tracing.
So
I
try
to
kind
of
make
those
separate
boxes
there.
There's
a
log
api
box
and
log
sdk
box
right
and
the
the
bottom
box
is,
it
doesn't
have
an
equivalent
in
tracing
or
metering
world,
but
I
think
the
distinction
here
is
may
be
important
because
even
if
you
don't
have
a
if
you
don't
use.
A
C
A
A
A
It
doesn't
even
need
to
be
exposed
if
we're
only
talking
about
logs,
slash
events
api,
but
because
there
is
another
use
for
that
which
is
to
implement
appenders
for
other
logging
libraries.
We
we
still
want
it
to
be
kind
of
visible
to
the
end
users,
but
only
to
to
those
end
users
who
are
implementing.
C
A
C
Actually,
there
is
one
other
thing
that
you
know
I
I
I'm
a
little
confused
in
open
telemetry
in
general
is
that
in
in
typically
when
we,
you
know,
provide
apis
the
end
users
are
supposed
to
only
use
the
apis
right
and
in
the
you
know
they
can
plug
in
the
sdk.
You
know,
whichever
implementation
you
know
of
that
api.
You
know
separately
from
outside,
but
here
I
see
that
like.
C
If
you
see
the
usage
examples,
at
least
in
the
like
you
know,
the
configuration
is
not
part
of
the
api
right.
The
processors
are
not
part
of
the
api,
they
are
sdk
they're
they're
only.
A
You're
right,
it's
it's
it's
a
bit
confusing!
The
distinction
is
that
processors
and
providers
you
do
it
once
at
the
application
startup,
whereas
the
apis,
you,
you
sprinkle
your
code
with
the
api,
calls
here
and
there
right
through
inside
your
instrumentation,
so
that
that
is
what
what
makes
it
different
in
a
sense
right.
So
you
can
have
all
these
api
calls
all
throughout
your
code
base.
But
unless
you
do
this
setup
in
in
at
the
startup
time
which
which
establishes
the
provider
the
initializes
the
sdk,
essentially
all
the
api
calls
are
no
op.
A
C
And
because
of
that,
the
sdk
classes
are
used
by
end
users,
and
you
know
this.
C
A
C
C
A
A
Yes,
that's
what
I'm
saying
this
now
looks
very
similar
to
what
the
tracing
names
are
right.
We
have
sdk
tracer
provider
right,
that's
that's
how
it
it's
called.
So
you
get.
C
A
So
this
no
this,
I
think
this
is
going
to
be
new
classes,
the
sdk
logger
provider.
It's
going
to
be
a
new
thing,
but
it
will
it
if
so
the
logger
provider,
it
returns.
Sorry
the
logger
that
is
returned
here
when
you
get
a
logger
right
line.
Where
is
it?
There's
no
line
numbers,
so
you
get
a
yes
that
that
so
the
logger
you
get
it
gives
you
an
api
to
do
set
body
to
to
the
record,
to
to
build
the
record
all
that
stuff
right.
So
this
needs
to
have
an
implementation.
C
If
that
makes
sense
so
so
I
was
looking
at
this
open
telemetry
java
repo-
and
here
I
see
at
the
top
level
there
are,
there
is
an
api,
folder
and
sdk
folder
right
and
the.
C
So
if
you
see
the
log
you
know
these
are
the
apis
under
logs,
and
you
know
the
implementation,
the
sdk
implementation
would
be.
You
know
here
under
sdk,
so
if
we
had
just
the
logger
provider
in
in
place
of
sdk
log
emitter
or
instead
of
in
place
of
sdk
log
emitter,
if
we
had
sdk
logger,
then
wouldn't
it
be
equivalent.
E
A
Into
one
logger,
which
I
want
to
try
to
avoid,
if
possible-
or
maybe
that's
not
a
goal-
I
don't
know
the
difference-
is
going
to
be
that
what
api
do
you
give
to
authors
of
libraries,
logging
library
offers
to
implement
appenders?
Do
they
get
the
same
logger
as
everybody
else
like
the
the
end
user?
It
it
gives
them
more
api
than
they
really
need
right.
It's
it's
richer
api.
Can
they
can
call
log
event
on
that,
but
they
don't
need
to
they.
They
never
need
to
so
you're,
essentially
giving
them
something
that
is
useless.
A
A
Imagine
that
you're
an
author
of
a
logging
library
you
want
to
implement
an
app
for
log4j,
for
example,
all
the
new
stuff
that
you're
now
proposing
is
not
needed
by
you
right.
In
that
case
it's
unnecessary.
It's
it
just
creates
noise
in
in
how
you
can
use
the
api,
I'm
trying
to
avoid
that
if
possible.
Maybe
it's
unnecessary.
I
don't
know.
Maybe
we
just
provide
one
api
for
everybody,
so.
C
C
But
my
understanding
was
that
the
sdk
would
include
methods-
or
you
know,
functionality
for
both
logging
and
the
event
use
cases,
whereas
the
api
would
be
at
this
point
only
for
the
events,
so
once
the
provider
returns,
you
a
logger
instance
now
that
logger
instance,
although
it
is
mapped
to
the
log
emitter,
you
know,
the
logger
interface
only
has
methods
for
event
use
cases
and
therefore
end
users
will
be
restricted
to
you
know
the
event
use
cases,
whereas
the
log
appenders
will
be
using
the
sdk
classes
directly
and
therefore
you
know
they
have
more
access
to.
A
A
A
To
be
honest,
what
exactly
is
the
right
approach
here,
but
I
want
that
logger
api,
which
has
the
log
log
event
method,
is
one
thing
and
there
is
another
thing
which
is
for
the
for
the
appender
implementation,
which
has
a
different
set
of
methods
that
you
can
call
right,
because
these
things
don't
really
they
look
very
different.
The
function
signatures
are
going
to
be
different.
A
I
I
think
probably
some
prototyping
is
necessary
here.
It's
it's
a
bit
hard
to
tell
unless
you
start
writing
the
code.
So
maybe
maybe
you
know
I
I.
C
I
did
that
and
but
that's
based
on
my
understanding,
so
it
seems
to
be
slightly
there's
a
disconnect
like
I,
I
created
all
these
classes
and
like,
for
example,
the.
A
Can
you
maybe
push
this
to
a
branch
somewhere
and
I.
C
Yeah,
it's
it's
incomplete.
My
plan
was
to
have
the
log
emitter.
C
A
Make
some
more
changes,
I'm
confused.
So
that's
that's.
I
think
where
we
can
have
a
different
site.
We
can
have
a
logger
interface
and
we
can.
We
can
have
log
record
emitter
interface.
Logger
interface
is
the
api
for
end
users
for,
for
example,
for
profiling
for
ebpf.
Whoever
is
emitting
events
right.
That's
one
thing.
The
second
is
log
record
emitter.
A
A
I
I
don't
know
if
maybe
the
underlying
implementation
is
the
same,
but
the
interfaces
will
look
different
and
you
probably
will
obtain
them
in
a
different
way.
That's
what
I
was
thinking.
Maybe
that's
not
right.
Maybe
it
needs
to
be
the
same
thing.
Maybe
I
I'm
not
sure,
but
I
was
thinking
that
they
need
to
be
different.
Somehow.
C
Okay,
the,
I
think
the
other
comment
you
have
is
that
do
we
need
do
we
need
this
here,
or
is
this
sufficient.
A
I'm
saying
I'm
saying
in
the
specification
we
do
not
necessarily
have
to
say
builder
right.
The
word
builder
doesn't
have
to
be
there.
I
don't
think
we
use
that
in
the
tracing
specification,
for
example,
although
the
implementation
in
java
does
use
the
builder
pattern,
if
I'm
not
wrong,
so
we
kind
of
we
try
to
avoid
in
the
specification
try
to
avoid
referring
to
language
specific
constructs,
if
possible.
C
Yeah,
I
think,
then,
how
do
we,
I
think,
the
purpose
for
having
this
was
to
construct
log
records
beyond
what's
possible
with
these
methods.
C
So
severity
is
one
example
right
where
it
came
up
in
the
spec
meeting
yesterday
that
what
if
we
we
want
to
have
severity
for
events,
you
know
should
that
be
put
in
attributes,
then
there
will
be
another
semantic
convention
or
or
if
it
is
part
of
the
method
signature,
then
the
implementation
we
can
ensure
that
it
actually
is
mapped
to
the
severity
field.
In
the
lock
record.
A
A
A
C
In
general,
it
might
be
okay
only
with
severity.
You
know
there
is
a
possible
conflict,
because
severity
is
a
field
and
severity
may
be
present
in
events,
in
some
cases.
D
Riley
brought
that
up
in
the
specs
yesterday
he's
talking
about
in
the
future.
You
might
want
to
attach
a
severity
to
the
events
and
be
able
to
filter
or
sample
logs
or
slash
events
based
on
the
severity,
and
you
know,
I
think
what
I
think
should
be
the
case
is
that
if
we
do
decide
to
allow
severity
to
be
attached
at
events
at
some
later
point,
it
doesn't
manifest
as
an
attribute
it
manifests,
as
in
the
top-level
severity
field.
It.
C
A
Well,
I
kind
of
if
we
do
that,
what
happens
if
we
need
the
other
fields
like
we
want
to
expose
the
second
timestamp,
for
example,
right
we
have
two
and
somebody
comes
and
say:
oh,
I
want
events
that
they
actually
use
the
other
both
of
the
timestamps
we're
going
to
end
up
with
a
large
number
of
overrides
with
methods
which
actually
I
mean.
If,
if
that's
the
the
goal
that
you
are
able
to
set
all
the
fields,
then
maybe
we
just
need
actual
builder
right.
The
builder
pattern
here
would
be
much
more.
D
Useful
we
we
would,
we
probably
would
go
with
a
builder
in
java,
so
we
have
a
span
builder
in
java
which,
in
order
to
obtain
a
handle
of
it,
you
have
to
provide
like
the
minimal
arguments
like
the
span
name,
but
then
every
other
field-
that's
optional.
You
can
attach
to
the
builder
after
the
fact,
and
so
I
think
the
same
thing
exists
for
events,
so
you
create
an
event
builder
with
the
event
name.
That's
the
one
required
field
that
you
can't
get
around
and
everything
else
is
optional
after
that,
including
attributes.
D
A
So
maybe
do
that
right
have
the
minimum,
which
is
the
name
of
the
event
if
we
agree
on
that,
and
the
rest
is
something
that
it
can
optionally
build
on
top
of
it.
So,
instead
of
the
overrides
I
mean
this
is
fine.
Let's,
let's
agree
on
on
on
the
overall
conceptual
api
and
then
in
the
particular
languages
in
java,
I
think
we
can
have
the
flexibility
to
to
to
do
one
or
the
other,
that
that's
fine,
that's
not
a
problem.
We
can
iterate
on
this.
I
would
very
much
try
to
at
this
point.
A
Try
to
understand.
Do
we
have
a
logger
and
a
log
record
emitter
as
separate
things,
for
example,
or
it's
one
thing
right?
Let's
agree
on
this
high
level
stuff.
First,
what
is
the
separation
of
these
two?
What
goes
in
what
we
call
api
package
versus
sdk
package,
and
so
what
who
is
supposed
to
call
what
the
actual
method
signatures?
I
think
we
can
figure
it
out.
It's
not
a
problem.
A
E
C
I
I
want
to
discuss
this,
the
the
last
one
first,
so
with
spans
in
the
spec.
I
see
that
when
a
new
span
is
created,
it
need
not
or
it
should
not
have
the
current
span
as
the
parent
unless
it
is
explicitly
set
as
parent
r
or
in
java.
I
think
I
I
see
in
the
examples
that
you
could
mark
a
span
as
current
by
saying
in
a
spa,
make
current
or
something
and
then
any
further
span
created
in
that
execution
context.
You
know
takes
that
as
the
parent,
so
with
logs.
C
C
If,
let's
say
a
span
is
in
progress
and
and
then
you
you,
when
marked
as
you
know,
current
to
automatically,
you
know,
use
it
for
any
other
purpose,
so
any
logs
that
get
emitted
during
that
period
would
they
is
the
sdk
or
the
appender
implementation
supposed
to
include
the
span
context
in
the
log
records?
A
A
C
So
the
example
I
have
in
mind
you
know
one
is
in
android,
you
can
set
up
event
listeners
and
when
you
get
the
call
back,
it
will
be
called
in
the
same
thread
that
actually
set
up
that
event.
Listener.
D
Okay,
I
can
give
a
little
context
about
how
this
works
and
with
the
java
appenders
today,
the
java
appenders
today
for
log
back
and
for
log4j
when
they
are
translating
their
respective
logs
to
open
telemetry
log
records
they,
I
guess
manually,
but
they
take
the
span
contacts
and
associate
it
with
the
log
record
and
and
so
that
every
every
log
that
comes
through
log,
back
or
log
for
j
has
the
span
contacts
associated
with
it
and
there's
no
way
to
turn
that
off,
and
maybe
that's
that's
prob.
D
C
D
But
it
sort
of
is
relevant,
so
if,
if
a
log
is
if
a
log
is
logged,
when
a
span
is
active,
that
means
that
that
log
took
place
while
the
span
was
active
on
the
thread
where
the
span
happened,
and
so
it's
still
contextual
data
that
could
help.
You
know
an
operator
determine
kind
of
the
state
of
the
application
when
that
span
was
ongoing.
D
C
C
So
that
fact,
or
are
you
in
in
a
browser
world?
You
are
waiting
for
some
data
to
come
back,
but
you
navigate
to
a
you
know
different
page
or
a
different
section
in
the
the
page,
so
that
information,
while
it's
you
know
it
it's
good
to
know
that
you
know
hey.
While
the
you
know
the
user
was
waiting,
you
know
he
he
did
these
other
things,
but
technically
I
think
they.
They
are
not
part
of
that
span
in
progress.
C
So
there
might
be
nuances
and
there
might
be
situations
where
it
may
not
be
relevant.
So
so
I
think
the
question
is
really
you
know:
is
there
an
option
for
end
users
to
or
are
even
the
appender
implementers
to?
A
Well,
it
shows
that
the
the
event
happened
while
that
particular
span
was
active.
I
don't
know
if
that's
a
useful
information,
maybe
it
is,
but
I
I
can
see
why?
Maybe
you
don't
want
to
record
it,
so
maybe
we
want
that
as
an
option.
It's
hard
to
tell.
I
think
the
question
is:
what's
the
granularity
of
control
that
you
want
to
have
there?
Is
it
every
time
you
create
an
event?
A
You
need
to
make
this
decision
whether
the
context
is
going
to
be
associated
with
it
or
no
or
is
it
when
you
obtain
a
logger
for
the
entire
scope
of
that
logger?
You
know
that
you
don't
want
a
spam
context
with
all
of
these
events,
because
the
answer
probably
will
tell
you
how
you
want
to
model
this
in
the
api.
C
Okay,
so
you
know
because
there
are
no
clear
answers
here.
You
know
I
just
put
the
statement
and
I
will
remove
this-
must.
C
If
it
could
be
misleading,
it
could
lead
to
a
you
know.
Misunderstanding.
D
So
the
misleading
part
could
be
that
that
maybe.
D
Yeah
the
span
caused
it
rather
than
them
being.
You
know
actually
just
two
things
that
happened
and
happened
to
be
like
correlated.
They
both
happen
at
the
same
time,
but
the
span
did
not
cause
the
event.
A
Okay,
so
maybe
let's
do
that,
I
can
take
a
look
at
the
branch
that
you
have
or,
if
you're
planning,
to
update
it.
Please
update
and
then
let
me
know:
okay,
I
can
have
a
look
at
what
the
draft
looks
like,
but
I
think
we're
now,
maybe
at
the
point
where
there
is
some
need
for
for
actual
prototyping
in
code,
because
unless
we
do
it,
it's
a
bit
difficult
now
to
see
all
the
picture.
What
this
looks
like.
C
Okay,
okay,
all
right,
so
the
other
open
question
I
had
is
with
respect
to
this
attribute
name.
A
Yeah,
so
this
one
right
so
for
this
one,
if
we
go
with
the
concept
of
having
a
separate
domain
and
an
event
name
domain
being
essentially
the
name
space
for
event,
names
right,
that's
that's
how
it
helps
an
interesting
way
to
do.
That
would
be
to
make
domain
an
attribute
of
the
scope.
A
The
comment
is
collapsed.
You
need
to
show
more,
oh,
I
see
go
down
a
bit
scroll
down.
Yes,
this
one.
This
comment,
it's
click,
yes,
so
you
obtain
a
logger
with
an
attribute
and
you
set
the
event
domain
to
whatever
you
want
it
to
be,
and
then
you
just
submit
events
right.
You
emit
events
and
and
all
of
those
are
associated
with
the
correct
domain.
A
D
I
like
this
as
well-
I
was
thinking
about
this
yesterday
when
this
was
being
discussed
at
the
spec
sig,
whether
this
could
be
solved
with
scope,
attributes
and
but
one
thing
that
I
was
thinking
about
is
you
know
this.
Some
folks
have
discussed
that
span.
Events
should
be
able
to
map
into
log
events,
and
so
in
the
case
of
span
events
which
don't
have
this
concept
of
a
domain
today.
What?
A
C
So
so
whatever
so,
the
tracer
scope
should
also
have
the
same
attribute.
Then.
B
A
C
The
thinking-
that's
that's
what
that
is
suggesting,
but
I
think
it
has
its
complexities
too.
A
D
Okay,
I
mean
there's,
there's
enough
overlap
in
between
like
log
events
and
span
events
that
you
could
see,
you
could
see
that
where
the
desired
would
come
from,
I
mean.
Obviously,
we
have
to
support
span
events
forever
now.
A
Okay,
I
understand
that
that
I
mean
the
mapping
seems
obvious
here,
but
when
you're
exporting
using,
I
think
jager
has
the
notion
of
events
right.
So
you
don't
really
want
to
do
that.
You
want
to
keep
those
events
as
spam
events,
so
that
the
jager
exporter
knows
what
to
do
with
those
right
otherwise,
they're
going
to
be,
I
mean
either
lost
because
jager
has
no
notion
of
logging
or
you're
kind
of
artificially
splitting
your
traffic
in
a
way
that
the
events
which
were
previously
properly
associated
with
spans
now
become
sort
of
detached.
A
They,
they
they're
a
separate
data
stream,
which
you
have
to
reconstruct
back
and
I'm
having
a
hard
time
understanding.
Why
really?
You
would
want
to
do
that,
because
this
seems
to
be
the
notion
of
events
that
are
contained
within
a
span
seems
to
be
well
established.
Now,
maybe
I'm
wrong.
I
don't
know
why
we
would
want
to
move
away
from
that.
D
Yeah,
I
don't
have
strong
opinions
on
that,
but
you
know
to
your
point.
You
would
have
to
be
aware
of
your
export
strategy
when
you're
configuring,
the
sdk,
if
your
trace
exporters
expect
span
events
to
be
present,
and
you
flip
this
flag
that
instead
it
takes
span
events
and
treats
them
as
logs.
A
A
We
don't
have
to
deviate.
Let's
say.
D
And
maybe
maybe
just
in
the
spirit
of
that
goal,
it
is
good
to
think
about
and
just
keep
that
use
case
in
mind.
So
you
know
just
if
we
wanted
to
add
such
a
feature
in
the
future,
where
span
events
could
go
to
logs
the
log
sdk
instead,
what
would
that
look
like.
C
Okay,
so
so,
coming
to
this
attribute
event,
domain.
A
Set
of
possible
values
right,
what
do
you?
What
are
the
values
that
are
possible
to
record
here?
Do
we
predefine
in
the
specification
what
you
can
put
there
or
it's
a
it's
kind
of
anything
you
want,
I
mean
or
or
it's
a
predefined
list,
plus
anything
you
want,
so
that
that
part
is
not
clear
to
me.
What
do
we
do
there?
If
we
prescribe,
then
we
probably
quite
we
severely
limit
the
the
use
cases
for
for
the
users
that
we
do
not
understand.
A
In
a
sense,
we're
saying
that
the
domain
is
the
namespace
for
the
event
names,
but
domain
itself
has
a
similar
problem,
not
to
the
same
degree
because
probably
they're
not
you
don't
have
millions
of
domains
possible
and
likely.
Maybe
you
can
agree
on
what
the
domain
names
should
be,
but
it's
still
I'm
not
sure
how
we
resolve
this
one.
D
A
A
D
But
as
you're
talking
about
that,
so
you
know
this,
the
suggestion
that
you
had
about
having
the
the
event
domain
be
a
scope
attribute,
I'm
trying
to
think
well,
so
we
already
have
a
scope
name.
The
scope
name
is
sufficiently
unique
that
it
shouldn't
conflict
with
other
scope,
names
and
we'll
have
this
additional
event
donate
domain
as
a
scope
attribute-
and
I
guess.
A
They
are
different
dimensions
right.
The
scope
name
gives
you.
Typically,
it's
a
location
in
the
code
base
right.
The
domain
name
is
the
different
dimension.
It's
it's.
The
kind
of
the
events
that
are
emitted
they
may
be.
The
same
kind
may
be
emitted
from
very
different
places
in
the
code.
That's
right.
D
A
A
Much
more
open
from
that
perspective
like
they
are
really
really
unconstrained.
It
can
be
anything
that
the
end
user
chooses
to
be
the
the
scope
name,
whereas
the
domains
are
probably
not
so
unconstrained.
There's
probably
some
some,
I
guess
at
least
some
recommendations
about
this
list.
Like
the
you
have
that
browser
mobile,
I
think
right
as
an
example,
there.
A
D
Maybe
we
could
have
something
like
you
know,
we
could
reserve
all
event
names
that
start
with
hotel
dot,
yeah
yeah.
C
A
We
do
we
do
for
for
things
like
http
dot
method.
The
convention
says
what
the
values
should
be
right.
It
can
be
only
get
post
head
or
whatever
is
the
possible
values
for
http
protocol.
So
we
do
it's.
It's
not
like.
There
is
no
precedent.
We
only
define
names.
No,
that's
not
true.
We
do
define
items
where
it's
appropriate.
A
The
only
complication
here
is
that
this
is
not
really
a
kind
of
predefined
list
that
only
we
know
what
what
what
the
enumeration
should
look
like
it's
kind
of
both
an
enumeration,
because
we
we
have
some
some
use
cases,
but
also
we
do
know
that
there
is
going
to
be
use
cases
which
we
we
have
no
idea
about.
So
we
cannot
just
limit
to
to
be
an
enumeration.
D
A
C
That's
all
for
now
I'll
I'll,
update
the
prototype,
changing
the
names
and
then
incorporating
other
feedback
that
you
have
and
then.
A
A
D
Congrats
on
the
stabilization
of
logs
and
otlp,
that's
fantastic.