►
From YouTube: 2022-07-13 meeting
Description
cncf-opentelemetry meeting-2's Personal Meeting Room
A
A
A
A
Hi
so
I
have
we
had
we
had
a
meeting
yesterday
we
had
a
couple
things
that
I
that
I
shared
yesterday,
but
since
there
are
folks
here
that
were
not
there
that
I
can
maybe
talk
about
that
a
little
bit
too
and
I
added
on
the
agenda.
A
I
added
just
a
little
bit
quick
update
on
kind
of
the
things
that
are
in
progress
right
now.
If
you
have.
A
So
first
first
I'm
going
to
be
out
of
the
office
next
week,
just
fyi,
you
know.
Obviously,
obviously,
if
you
have,
if
you
have
topics
to
discuss,
you
know,
obviously
have
the
meeting
or
feel
free
to
cancel
if
you,
but
it's
I'm
not
going
to
be
here
next
week.
A
A
quick
update,
I
think,
is
from
what
I
know
that,
what's
going
on
related
to
this
group,
there
is,
let
me
share
my
screen.
I'm
just
gonna
look
at
that.
A
So
we
had
we
had
the
events
api
otep,
that
santosh
has
been
driving
that
otep
was
just
merged
this
week,
which
is
great.
I
think
the
next
steps
are
gonna,
be
actually
defining
the
specification
for
the
api,
and
I
think
santosh
is
not
here,
but
I
think
he's
he's
probably
going
to
be
continue.
Continuing
that
work.
A
A
The
other
thing
that's
that's
in
progress
is
there
is
an
there
is
a
pr
the
tigran
opened
for
changing
the
format
of
the
json
json
protocol,
otrp
protocol
or
the
format
of
json
from
from
the
to
short
keys
to
use
short
keys,
and
so
that's
having
a
kind
of
wider
discussion
right
now
again,
if
you
have
any
opinions
on
this,
please
please
take
a
look
at
that
pr
and
comment.
I
I
think
I'd
like
to
discuss
that
a
little
bit
a
little
bit
further.
A
But
let
me
just
finish
this
quick
update,
the
other
one
that
I'm
the
other
topic
that
I'm
aware
of
is
the
ephemeral
resources
otap,
which
ted
opened-
and
this
is
essentially
proposing
this.
This
impacts
us
because,
because
we
would
like
to
store
session
attributes
as
part
of
resources
instead
of
each
each
each
signal.
A
And
then
we've
been
working
on
semantic
conventions,
the
last
few
weeks,
so
regarding
that
I
have
put
together
kind
of
a
draft
of
structure
for
semantic
conventions
for
events
it's
in
this
pr.
A
This
is
just
in
my
my
fork
right
now
so
because
I
don't
know
like
if
that's
how
you
want
it,
but
so,
but
take
a
look
again
and
if
you're,
if
you're
interested
in
working
on
somatic
conventions,
take
a
look,
it's
it's.
Essentially
it
does
two
things
it.
It
proposes,
structure
for
for
semantic
conventions
for
events,
and
it
also
there
is
also
a
draft
of
semantic
conventions
for
two
events
for
browser.
One
is
the
navigation
and
the
resource
resource
event.
A
So
yeah
take
take
a
look
if
you
once
once
we
have
an
agreement
in
this
group,
then
I'm
gonna,
I'm
gonna,
open
a
pr
to
the
upstream
repo.
A
So
it
would
be
in
the
in
the
logs
specification
semantic
conventions
proposing
adding
events
section,
which
has
which
will
have
here
semantic
conventions
defined
for
all
events,
which
is
this
events.
These
events
attributes
we
have
talked
about
event,
name
domain
data
and
then
any
subfolder
in
here
would
be
represent
a
domain,
so
there
would
be
in
under
browser.
A
So
for
navigation
as
an
example,
what
I'm
proposing
is
that
we
defined
that
this
event
type
must
have
these
values
or
event,
name
event
domain
and
here's
the
additional
set
of
attributes.
A
Brace,
you
have
not
been
in
these
discussions
like
so
I
think
the
same
thing
would
be
would
be
for
would
apply
for
mobile.
We
think
so
there
would
be.
There
would
be
like
here
like
a
mobile
section
with
representing
like
domain
for
mobile
events,
and
then,
like
you
know,
we
could
you
could
work
on
semantic
conventions
just
for
mobile
separately.
A
So
yeah,
if
you're
interested
in
this,
please
please
take
a
look
and
comment
and
be
much
appreciated.
A
A
So
I
wanted
to-
I
don't
know
if
this
is
this
is
the
right
place
to
talk
about
this,
but
nav
nev,
and
I
briefly
chatted
yesterday
about
the
short
codes
that
or
the
short
keys
pr
essentially-
and
I
you
know-
I
know
that
t2
has
been
part
of
this
conversation
as
well,
but
the
proposal
here
by
tigran
is
to
to
change
the
definition
so
that
the
json
would
actually
look
like
this
with
the
short,
the
short
keys
instead
of
the
ones
that
are
mapped
directly
from
the
proto
definition.
A
A
You
know,
I
know
we've
discussed
so
I
I
did
kind
of
just
thinking
about
this.
I
I
did
list
some
options.
Just
for
you
know
there
we
talked
about.
A
We
talked
about
gzip,
physically
into
binary
format,
changing
this
short
keys
and
also
having
maybe
like
having
some
custom
encoding
with
with
a
collector
receiver.
A
I
think
now,
if
I
understand
correctly,
what
you
said
in
the
past
is
that
the
ideas
would
be
just
that
there
is
none
of
this
and
we
just
construct
an
object
as
we
go
and
then
just
stringify
it
and
it's
it's
already.
Optimized.
C
If
we're
going
to
go
short
keys,
I
I
think
that
should
just
be
the
numeric
value
of
the
proto,
but
the
whole
format
of
attributes
is
just
wrong
for
a
browser
anyway,
and
if
we've
got
to
construct
it
in
that
format,
then
from
a
cpu
perspective,
it's
probably
about
the
same
to
do
it
as
a
complete
binary
format.
I'm
not
too
concerned
about
human
readable
yeah.
We
can
write
tools
to
to
decompress.
A
C
A
So
do
you
think
so?
I
know
that
t2
has
done
some
some
numbers
on
this.
Some
performance
numbers
did
you
find
it
not
acceptable.
C
Is
it's
a
com
well,
depending
on
the
size
of
the
payload?
It's
the
code
to
drag
in
the
compression,
so
you
have
to
do
like
paco
and
whatever,
and
then
you
know
just
the
cpu
is
bad
like
for
supporting
some
internal
teams.
I
have
extremely
extremely
strict
requirements
of
like
less
than
one
millisecond
to
pack
stuff,
which
is
why
json.stringify
is
my
only
option.
C
C
But
yeah,
as
with
the
event
stuff,
it's
like,
we
should
have
options,
there
are
applications
where
jesus
will
work
perfect
and
there
are
applications
where
it
won't.
So
it's
not
about
mandating
that
this
is
the
only
way
you
should
do
it,
which
the
case
of
a
this
would
be
the
preferred
way
to
do
it,
but
you've
also
got
these
other
options.
If
you
really
need
it.
C
Just
straight
json
encoding,
but
not
in
the
format
that
is
now
because
then
the
payloads
do
be
because
you're
going
to
convert
from
a
an
attribute.
You
know
a
nice
flat
object
into
this
structured
object,
and
that's
let's
say:
if
I'm
going
to
do
that,
it's
just
just
as
in
the
intensity
to
create
binary
formats.
In
fact,
it's
probably
slightly
cheaper
to
create
binary
formats
and
would
be
to
create
that.
B
Would
it
be
an
option
to
let
the
application
developers
decide?
Well,
that's
the
exporter,
so
you
choose
which
exporter
you
want.
A
C
Who
knows
yeah
it's
like
most
of
the
the
stuff
that
I'm
that
I'm
talking
about,
they
send
us
custom
data,
which
is
this
nested
object,
the
stuff
that
I've
been
pushing
for
and
the
straight
nested
attributes
as
they
are
defined.
If
we
have
to
send
them
like
that,
then
it's
just
it's
a
problem.