►
From YouTube: 2022-06-15 meeting
Description
cncf-opentelemetry meeting-2's Personal Meeting Room
A
B
C
B
Okay,
so
this
is
jack
based
on
your
comment
yesterday,
on
whether
the
whether
we
want
these
individual
methods
in
the
logger
interface,
or
we
only
want
the
builders
which
are
you
know,
which
I
mentioned
towards
the
end.
B
One
statement
I
mentioned
in
the
in
the
api
spec
I
mentioned
having
both
the
log
event
function
as
well.
As
you
know.
Additionally,
you
know
having
one
more
a
generic
statement
saying
you
know,
ability
to
create
an
event
using
log
record
data
model.
B
I
I
think
the
the
reason
I
added
these
was
was
purely
for
convenience.
I
think
originally.
Actually
it
was
john
watson
who
suggested
this
a
method
that
just
takes
the
event
name
and
the
attributes.
You
know
this
method,
but
I
I
completely
understand
that
you
know
you
in
java.
You
might
want
to
have
just
only
one
one
method,
which
is
this
builder
pattern.
B
So
the
question
is,
you
know,
do
you
have
I
I'm
I'm
relatively
new
to
open
telemetry?
So
do
you
have
usually
other
utilities
or
helper
methods
where
you
keep
these
simplified
forms.
D
So
so
a
couple
of
things
here,
so
in
general,
when
I
read
other
sections
of
the
api
specification
there
isn't
this
level
of
detail.
There
isn't
generally
the
assertion
of
like
what
the
arguments
should
be
and
like
which
methods
and
their
overloads
should
exist.
Whether
builder
patterns
should
exist
or
not.
You
know.
If
we
take.
Let
me
include
a
a
link
in
the
meeting
notes
that
you
can
reference
if
we
take,
for
example,
the
api
specification
for
span
creation.
D
You
know
what
the
specification
says
is
that
there
is
a
an
api
for
creating
a
span
and
that
the
api
should
accept
the
following
parameters,
and
then
it
lists
one
required
parameter
and
then
a
variety
of
optional
parameters
and
what
their
defaults
are,
and
so
implementations
are
free
to
represent
this
api.
However,
they
want
whether
that's
a
builder
pattern
or
with
overloads
things
like
that,
and
so
that's
kind
of
that's
kind
of
my
point
with
this
comment
here
is
that
I
don't
think
we
should
be
so
specific
in
in
this
ot.
D
I
think
we
should
just
declare
what
api
should
generally
be
available
and
what
their
arguments
should
be
and
not.
Try
to
get
into
the
minutia
of
how
to
how
to
represent
that.
D
Well,
so
you
know
the
the
goal
in
specifying
the
apis
like
this
is
to
allow
languages
to
have
their
the
agency
to
to
do
an
autonomy
to
do
what's
idiomatic
in
their
language,
so,
like
builder
patterns,
may
not
be
idiomatic
in
one
language,
but
may
be
the
way
to
go
in
another
language,
and
so
you
know,
if
you,
if
you
review
how
apis
are
specified
just
in
general,
this
seems
to
be
the
way
to
do
it.
B
Yeah
sure
so
I
think
the
sec,
the
I
mean
first
reason
was,
you
know
I
actually
just
picked
this
from
what
john
watson
suggested.
I
think
he
has
a
method
with
this
signature
in
in
the
on
the
android
side.
B
Today
it's
only
meant
to
use
by
the
appenders
right,
but
in
case
this
becomes
an
end
user
api
as
well.
Then
there
are
methods
like
log.debug
rightlogger.debug
logger.1.
B
There
are
simplified
methods
where
you
know
you,
you
won't
be
using
the
builder
pattern.
So
builder
pattern
is
probably
something
we
chose
in
the
open
telemetry,
but
these
convenience
methods
are
not
uncommon.
Right.
D
In
our
api
implementation
right
now,
so
so
in
java
in
otel
java's
api
implementation-
there
I
mean
sometimes
we
have
overloads,
but,
generally
speaking,
we
stick
to
we've
stuck
to
builder
patterns
for
creating
these
things,
and
just
like
so
you
know,
regardless
of
what
we
have
done
in
open
telemetry
java,
it's
just
unnecessary
to
to
to
specify
this
okay
in
the
specification,
because
you
know
like
when,
when
we
come
to
implement
this
in
java,
we
can
have
that
debate
then
about
whether
we
want
to
have
these
these.
B
I
see
okay,
then
the
so
so
your
comment
indicates
that
you
know
you
you
prefer
to
keep.
You
know
these
names,
these
methods,
but
their
signatures.
You
know
there
is,
you
know
some
confusion
like
if
you
like.
How
do
you
suggest
you
know
I
I
word
this.
So
let.
D
B
The
corresponding
section
just
a
second.
D
So
I
think,
there's
two
kind
of
top-level
apis
right,
so
there's
one
for
creating
logs
and
one
for
creating
or
one
for
creating
events
and
one
for
creating
log
records,
and
we
can
use
the
the
way
that
the
span
creation
apis
is
specified
as
a
model
for
this.
So
you
know
we
just
say
there
must
be
a
an
api
for
creating
events.
There
must
be
an
api
for
creating
log
records
and
for
each
of
those
you
you
can
specify
what
the
the
arguments
should.
B
Is
where
it
becomes
controversial
right
as
in?
If
I,
if
I
keep
you
know
this
statement,
you
know.
If
you
see
this
statement,
it
says
that
you
know
we
need
a
function
which
takes.
You
know
these
two
arguments
which
you
know
now
doesn't
make
it
suitable
for
a
builder
pattern
so
much
it.
D
Does
it's
it's?
So
that's
still
fine
in
a
builder
pattern.
There's
builders
that
have
you
know
the
way
that
required
arguments
are
typically
manifest
and
builder
patterns.
Is
you
know
when
you
request
the
builder,
you
specify
the
required
arguments
and
then
all
the
optional
arguments
are
things
that
you
set
after
the
fact
on
the
builder
itself.
So
I
think
that
still
meshes
with
the
builder
pattern.
D
We
have
that
pattern
all
the
time
in
open,
telemetry
java,
where
it's
a
mixture
of
required
and
optional
arguments,
but
you
know
it
just
in
this
case
as
well,
so
the
I
don't
think
that
attributes
are
required
for
events.
The
name
is
the
only
required
field.
Attributes
will
be
there
very
often,
but
I
don't
think
they're
required.
B
Do
you
also
suggest
not
giving
a
name
to
the
function
in
this
in
this
api
spec
document,
because.
D
B
Yeah
because
I
think,
if
you're
going
to
use
the
builder
part
pattern,
you
will
you'll
probably
use
a
different
name
right
and
not
this
name.
B
Okay,
I
I
think
then
the
other
point
is
that,
should
this
function
in
the
logger
be
resulting
in
sending
that
logger
out
in
the
pipeline
or
or
is
it
supposed
to.
B
Like
like
it
says,
you
know,
you
create
an
event
right,
you
know,
which
means
that
it's
closed
for
further
modifications.
So
how
do
we
handle
that.
D
I
think
you
have
two.
I
think
you
have
two
options
right.
So,
if
you're,
if
you
implement
this
as
accepting
an
event
as
an
argument
where
that
event
contains
all
the
fields
that
are
needed
for
that
event,
then
you
know
when
you
call
log
event
and
you
pass
that
event
as
an
argument,
then
I
think
it's
admitted
to
the
pipeline.
D
A
I
wanted
to
just
point
out
one
slight
detail
there
when
you
say
when
we
say
create
an
event
like,
is
it
creating
the
instance
of
the
event,
or
is
it
actually
emitting
that
event?
Yeah?
I
think
that
that's
yeah,
it
was
like
I
mean,
and
that
was
my
comment
coming
down.
There
was
like
if,
if,
if
he
would
be
emitting
an
instance
of
an
event,
then
you
have
to
have
some
way
of
creating
it
through
the.
B
B
Actually,
I
I
want
to
go
back
to
my
original
another
concern.
You
know
I
in
the
client-side
telemetry
I
I
have
been
looking
at
both
the
java
and
you
know
javascript,
and
I
I'm
used
to
more
looking
at
java
code.
So
in
all
the
documentation,
I
you
know.
The
first
thing
I
go
look
is:
is
that
java?
So
I
I
got
familiar
with
open
telemetry
apis
using
the
java
apis,
but
then,
when
I
switch
to
javascript,
I
get
lost
right
because
I've
had
that.
B
Yeah
things
are
done
very
differently,
that's
why
you
know
I
felt
it's
and
it's
not
like
it
can't
be
done
using
the
java
patterns
in
javascript.
You
can
so
that's
why
I
felt
that
it's
good
to
be
very,
you
know
specific,
so
that
everybody
can
at
least
you
know,
attempt
to
keep
things
consistent
and
then
you
know,
if
it's
not
possible,
then
then
you
deviate.
D
I
I
don't
have
the
answer
to
that,
but
you
know
I've
shared
the
same
experience.
The
java
implementation
of
open
telemetry
is
very
different
than
the
javascript
and
is
very
different
than
the
go.
You
know
each
each
implementation
and
we
talked
about
this
in
the
in
the
java
sig
last
week.
D
Actually
so
this
came
up
where
you
know
one
of
the
java
sig
maintainers
or
the
java
maintainers
was
working
with
the
the
go
api
and
felt
that,
like
you
know
it
was,
it
was
dramatically
different
than
the
java
api
and
you
know
what
we
were
mentioning.
What
we
were
talking
about
is
that
the
specification
describes
a
set
of
shared
behaviors,
but
you
know
it.
It
hasn't.
D
It
hasn't
manifested
in
an
api
that
feels
familiar
between
the
languages
and
I
I
don't
think
we
can
really
undo
that
at
this
point
that
you
know
for
better
or
worse.
That
seems
to
be
the
way
things
have
gone,
that
the
languages
share,
a
set
of
behavior
share
a
set
of
common
behaviors,
but
don't
have
the
same
ergonomics.
D
B
Okay,
okay,
all
right,
then,
then
I'll
I'll
do
I'll
do
what
you're
suggested
I'll
is
remove.
B
I'll
remove
these
things,
I
think
these
are
not
required
and
I'll
reword,
this
to
you
know,
use
this
name
as
as
an
option
you
know
and
then
I'll
remove
the
attributes.
I
think
that's
what
you
suggested.
C
Yeah,
I
I
I
found
some
examples
and
I
dropped
a
link
in
the
in
the
meeting
notes
in
there.
It
talks
about,
like
maybe
called
this
et
cetera,
there's
a
couple
of
examples.
There:
okay.
D
So
should
we
go
back
to
martin's
comments
about
creating
an
event
or
creating
an
instance
of
an
event?
Could
you
repeat
that
concern
martin.
A
Yeah,
I
know
so
this
this
just
I
was
actually
looking
at.
I
was
implementing
the.
I
was
working
on
actually
the
prototype
of
this
api
and
if,
if
there
was,
you
know
like
if
you
don't
use
a
if
you
don't
use
a
builder
pattern,
obviously
in
javascript,
then
then
the
either
you
have
you
either.
You
have
log
log
event
method
which
just
takes
like
the
the
name
and
attributes
or
if
you
wanted
to
have.
A
If
you
wanted
to
have
like
create
an
instance
of
the
event
and
then
like
so
you
can
hold
it
in
the
code
for
a
while,
and
then
you
know
manipulate
it
until
you're
ready
to
emit
it.
Then,
if
that's
what
you
wanted,
then
you
would
need
to
have
some
kind
of
way
of
creating
that
instance
through
the
api.
A
So
that's
that's
kind
of
the
you
know
like
when,
like
going
back
to
the
span
span
api
spec,
which
says
there
should
be
some
way
of
creating
a
span
through
the
api,
that's
what
the
that's,
how
it
is
in
javascript
like
there
is
a
there's,
a
method
called
start
span
which
gives
you
an
instance
of
a
span.
A
So
I
guess
I
guess
all
I'm
saying
I
don't
care
either
way,
I'm
not
sure
that
we
need
to
create
an
instance
of
event
but
like
when
we
say
like
in
the
spec
here
there
should
be
a
way
to
create
a
span.
Do
we
say
like
create
an
instance
of
a
span
or
do?
Are
we
saying
emit
an
event
like
yeah.
D
So
well,
so
that
the
span
api
kind
of
lends
itself
to
a
builder-like
pattern
right.
So
you
there,
the
tracer
has
a
mechanism
to
create
a
span
and
then,
ultimately
you
need
to
start
that
span
right
and
between
creating
that
span
and
and
starting
it.
You
associate
a
bunch
of
information
with
the
span
attributes
its
name,
its
kind
and
other
things,
and
then
and
then
you
start
it.
So
that
really
looks
a
lot
like
a
builder
pattern
and
it
it
is
implemented.
Something
like
that
in
java.
D
So
yeah,
so
you
you,
you
create
a
you,
create
a
span.
You
associate
some
information
with
it
and
then
you
call
start
span
at
which
point
the
the
span
has
started,
and
you
can
do
it
additional
things
with
that
span
like
attach
more
attributes
to
it
and
end
it.
A
D
But
that
start
is
kind
of
akin
to
like
build
and
like
in
the
in
the
context
like
of
a
logs
might
be
called
something
like
emit,
so
you,
you
know
how
I
would
was
imagining
this
api
looked
in
java.
D
You
know
I
was
assuming
a
builder
pattern,
and
so
I
I
I
assume
that
it
would
look
like
you
know.
You
obtain
an
event
builder
by
saying
you
know
build
event
and
you
pre,
you
give
it
the
event
a
name,
and
then
you
know
at
that
point.
You
have
an
instance
of
an
event
builder,
which
you
can
associate
with
additional
pieces
of
data.
D
You
can
add
attributes
you
can
set
a
severity,
you
can
do
all
the
things
and
then,
ultimately,
you
can
call
emit
on
that
event
builder,
which
would
take
all
that
that
data
that
you've
associated
with
it
and
create
like
a
log
record
and
send
that
through
the
processing
pipeline.
A
D
D
Yeah
there
is
some
interface,
but
is
it
just
kind
of
a
a
data
carrier
for
a
bunch
of
like
immutable
fields
effectively?
D
A
A
D
Yeah,
so
you
know,
that's
definitely
a
concern
of
of
like
how
you
implement
it
right.
I
don't
think
that
that's
the
type
of
thing
that
needs
to
be
specified.
Personally,
I
think,
like
you
know,
that's
something
you
consider
on
a
language
by
language
basis
during
implementation
time.
A
D
Yeah,
I
think
I
think
that
makes
a
lot
of
sense
to
me
to
make
it
very
clear
that
you,
you
know
when
you
call
this
api
to
admit
an
event
like
you
know
that
event
is,
is,
is
being
sent
to
the
the
log
record
processing
pipeline
yeah.
I
agree
with
that.
D
That
the
kind
of
the
conclusion
is
like
you
know,
if,
if
we're
specifying
which
api
should
exist,
should
we
say
that
there
should
be
an
api
to
create
an
event
or
an
api
to
emit
an
event?
And
I
think
what
I
was
agreeing
with
martin
on
is
that
it
might
be
clearer
to
say
that
there
must
be
an
api
to
an
emit
an
event,
so
that
there's
no
confusion
on
what
is
happening
when
you
invoke
that
api.
B
And
then
you
would
have
a
separate
way
to
actually
create
that
event
that
you
would
then
pass
here.
B
Okay,
okay,
yeah.
I
think
I
I
like
that,
because
that
you
know
gives
some
definitiveness
tonight
right.
I
think
there's
no
confusion
with
with
that.
I
think,
if
is
the
latter
part
right
where
the
api
spec
would
say
it
would
emit
an
event
into
the.
D
D
A
E
Yeah,
hey
guys,
I
work
on
the.net
open
telemetry,
mostly
it's
my
first
time
joining
the
long
sig.
So
I'm.
D
E
Involved
in
looking
at
like
our
log
emitter
implementation
and
just
our
log
solution
in
general,
one
of
the
things
we
really
want
to
do
in
dot
net
is
add
the
ability
to
pool
some
of
these
artifacts
like
our
log
record,
and
then
these
events
will
play
into
that.
So
I'm
just
going
to
throw
out
there
that
if
it's
too
specific
saying
you
must
pass
in
an
event
that
kind
of
hurts
us
as
far
as
pooling
them,
because
we
want
to
control
the
pool.
E
E
B
Yeah,
I
think
it
aligns
with
what
we
just
discussed
right.
I
think,
if
the,
if
the
logger,
you
know
only
requires
a
method
to
emit
events,
then.
A
A
E
How
we
would
probably
do
it,
in.net
is
in
our
api
library,
we
would
have
the
interface
and
it
would
be
called
emit
and
it
would
have
like
all
the
fields
and
then.net.
You
can
kind
of
decorate
defaults
for
things
that
are
optional,
so
we'd
have
kind
of
a
swiss
army
knife,
one
method
defined
on
the
interface.
E
But
then
we
probably
augment
that
with
extensions
to
kind
of
hide
some
of
that
nastiness
for
the
user,
so
they
have
some.
You
know
they
could
just
call
like
you
know,
event,
processor
or
provider
or
whatever
dot
emit
and
they'd
have
some
overloads.
Where
they'd
see
the
one
where
they
can
specify
everything,
or
they
can
just
do
like
event,
name
or
event,
name
and
attributes,
et
cetera,
et
cetera.
Is
that
kind
of
makes
sense.
D
Yeah
yeah,
I
think
that
makes
sense
and
that's
that's.
I
think
what
santosh
is
trying
to
get
out
with
these.
These
overloads
that
that
he's
originally
included,
and
if,
in
my
opinion,
you
know,
languages
should
be
free
to
do
that
if
they
think
that
it's
necessary
and
helps
the
ergonomics,
but
they
shouldn't
be
required
to
so.
C
And
if
they're
able,
like
javascript,
you
can
have
overloads
as
long
as
the
signature
is
the
same
for
every
single
one,
so
you
can
affect
you
have
optional
fields
on
the
end,
but
you
can't
say
I'm
gonna
have
a
different
version
where
the
first
argument
is
some
something
completely
different,
at
least
from
typescript.
It
gets
messy.
You
can
try
and
infer
it,
but
it's
generally
not
the
way.