►
From YouTube: 2023-04-05 meeting
Description
cncf-opentelemetry meeting-2's Personal Meeting Room
B
A
Thank
you,
so
nice
yeah.
B
Okay,
go
ahead,
I'll
jump
in
yeah,
so
so
I
know
that
you
guys
have
been
working
on
defining
a
lot
of
like
events
for
the
I
guess.
Browser.
B
Browsers
yeah
browser
instrumentation
and
we've
been
kind
of
negligent
on
the
mobile
side
of
putting
those
sorts
of
things
together
just
been
busy
with
a
lot
of
other
stuff.
The
Swift
agent
didn't
even
have
metrics
implemented.
B
So
that
was
one
thing,
but
we
started
looking
at
this
sort
of
thing
and
we've
added
it
to
our
elastic
spec
for
mobile
life
cycle
application
life
cycle
events
for
when,
like
the
application,
is
foregrounded
and
backgrounded
I'm
using
platform,
specific
terminology
for
those
exact
events
that
are
coming
through
so
in
in
the
in
the
meeting
notes:
I've
added
a
link
there
and
it's
just
the
top.
The
top
section
there
that
kind
of
breaks
down
the
specifics
of
that
and
I
guess.
B
Yeah
I
was
wondering
if
you
would
think
that
this
is
something
valuable
that
we
could
add
to
the
open,
Telemetry
spec
as
well.
I
can
put
together
a
PR
and
get
you
know
that
through
approval.
B
C
D
B
B
E
It's
the
event
data
it's
still
open.
It's
still
haven't
decided
yeah
to
do
that.
Okay!
Well,
we've
we've
decided,
but
trying
to
get
that
through
is
is
a
problem
because
it
relies
on
having
nested
attribute
support
right
and
none
of
the
sdks
today
support
nested
attributes,
even
in
even
their
logs
supports
it
right.
D
B
A
E
B
E
One
there
already,
but
okay.
E
That's
all
I
had
so
in
terms
of
ECS,
considering
from
ECS.
There
is
the
client
namespace
in
ECS,
but
there's
no
from
what
I
was
looking
at,
that
there
doesn't
seem
to
be
an
equivalent
client
event
that
we're
defining
am
I
correct
in
that
assumption.
B
Yeah
I
think
that
well,
yeah
I
think
that
the
naming
scheme
in
ECS
is
just
like
top
level
names.
There's,
no,
you
know.
If
you
had
an
event,
it
would
be
I
think
the
way
that
they
would
want
to
do.
It
is
add
it
as
like
the
name
of
the
attribute,
rather
than
the
field
of
the
attribute,
and
so
this
is.
This
is
already
kind
of
following
the
the
open
Telemetry
spec
using
event.name
yeah.
E
But
normally
it
would
be
like
your
event.lifecycle
or
something
like
that.
B
B
E
Because
we
do
have
the
ongoing
merging
discussions
right
right
so
in
the
spec
meetings,
they're
saying
it
won't
just
be
open
Telemetry
and
it
won't
just
be
ECS
it'll,
be
a
new
combined
spec.
B
B
Yeah
I'm
not
I'm,
not
involved
in
those
discussions
but
I'm
I'm,
aware
of
them
so
yeah
yeah.
A
I
think
the
context
is
we
introduced
a
few
resource
attributes
for
the
browser
and
we
were
wondering
if,
if
any
of
them
are
relevant
for
the
mobile
as
well
like
there
were
things
like.
Let
me.
A
I
think
this
view
is
not
good
but
yeah,
so
things
like,
let's
say,
visitor
ID
yeah.
Definitely
a
session
ID
and
the
screen
with
screen
height
are
applicable
to
mobile
as
well.
A
B
Yeah
I
mean
session
ID
definitely
would
visitor
ID
would
be
more
I
think
the
device
ID
might
might
fall
into
that
space.
Better,
a
user
ID
which
could
be
custom
set.
That
might
be
a
valuable
one.
E
Yeah
I
guess
visualize
visitor
idea,
I
think
was
supposed
to
be
the
user
device.
Id
is
definitely
another
one
that
like
browsers,
the
device
tends
to
be
hey
I'm,
a
browser
yeah.
A
A
A
Client
name
space
is
used
for
things
referring
to
a
TCP
client
and
in
our
in
the
hotel
case,
there
is
already
a
H,
the
net
namespace.
There
is
a
and
I
think
I
think
there
was
a
net
dot.
A
D
E
Database
user
yeah
I'm
not
seeing
any
general
username
space
I,
know.
Internally
we
have
a
username
space,
which
is
probably
what
Riley
is
talking
about
there,
but
yeah.
It
probably
would
make
sense
because
you
use
a
even
on
a
server.
It
is
potentially
possible
you,
you
want
to
track
an
anonymous
user,
ID.
A
Okay
and
please.
D
E
Yeah,
there's
they're
all
called
out
their
own
names
faces,
so
as
a
DB
user
as
well
so
yeah.
No,
it
doesn't
seem
to
be
a
username
space
on
its
own.
At
this
point,.
A
D
F
I
joined
today
I've
attended
some
some
meetings
in
the
past,
but
I.
My
my
concern
currently
is:
we
are
looking
into
a
into
the
into
further
developing
a
client-side
Telemetry
product
that
we
have
and
we
have
an
opportunity
to
to
implement
the
browser
events
spec
that
is
pending
currently
so
my
my
question
for
the
group
is:
what
do
you
think
in
regards
to
a
maturity
of
the
current
spec
and
also
what
is
the
best
way
for
us
to
contribute
to
the
to
the
proposal
here?
F
A
Yeah
I
think
it's
a
long
answer
so
I
think
the
current
there
are
current
set
of
instrumentations
that
do
not
include
events
right.
They
they
really
include
spans.
They
instrument,
you
know
the
the
page
load
and
then
the
Ajax,
the
xhr
and
fetch
calls.
So
there
is
some
version
of
implementation
already.
You
know
you
I
think
you
could
certainly
start
with
that.
A
Now.
I
think
the
group
is
trying
to
come
up
with
a
like
a
V2
version
of
the
instrumentations,
so
we
are
I
think
with
this
introduction
of
events
we
are
going
to
revisit.
Even
you
know
how
these
pants
are
going
to
like
the
the
instrumentation
for
Fetch
and
Ajax
Fetch
and
xhr
as
well,
will
be
Revisited
a
little
bit,
so
there
will
be
I
I
think
there
will
be
a
V2
version
of
all
the
instrumentations
in
future.
I
think
that's
what
we
are
going
towards.
A
So
during
the
process,
though
I
think
we
will
have
to
use
a
mixture
of
both
so
you'll
have
to
use
the
current
instrumentations
that
emit
you
know
spans
and
in
in
future.
You
know
we
will
have
new
instrumentations
that
emit
spans
plus
events.
A
Yeah,
so
with
respect
to
the
contribution
I
think
the
development
is
going
a
little.
You
know
in
a
mixed
way,
as
in
the
spec
has
given
us
some
support
that
we
asked
for,
but
not
100
percent.
A
A
So
there
is
some
version
of
specification
today
and
the
plan
is
to
now
go
ahead
with
that
specification
and
Implement
and
then
demonstrate
and
then
come
back
revisit
and
solidify
the
specification,
because
people
want
to
see
prototypes,
they
want
things
working
and
you
know
that
we
don't
have
so
we
have
started
so
there
is
a
log
API
in
log
SDK,
that's
close
to
being
marked
as
table,
so
that's
currently
being
implemented
in
JavaScript
I.
A
Think
somebody
from
China
is
contributing
is
working
on
on
the
log
SDK,
the
log
API
already
exists,
and
once
the
log
SDK
is
already
is
also
completed,
then
we
plan
to
take
up
all
these
instrumentation
of
these
events,
instrumentation
that
will
emit
these
events
and
the
development
for
that
is
happening
in
the
JS
sandbox.
So
let
me
go
there.
Even
I
haven't
looked
at
that.
A
I
think
Martin
has
created
these
tickets,
these
issues
and
they
are
currently
assigned
to
a
few
of
them.
I
think
they
seem
to
be
mostly
with
Martin,
so
you
could
coordinate
with
him
if
you
have
interest
in
working
on
some
of
these
contributing
to
some
of
these
I
think
Martin
could
reassign
some
of
them
to
you
and
yeah
I
think
once
this
is
this
is
implemented,
then
that
then
I
think
we
have
a
working
prototypes
and
then
we
can
get
back
to
the
specifications,
Sig
and
and
then
say
hey.
A
You
know
the
event.data
I
think
nav
has
an
open
PR
to
allow
the
event
payload
to
be
specified
in
a
an
attribute
called
event.data.
That's
not
merged,
though,
but
we
are
going
ahead
with
that.
The
idea
is
that,
even
if
you
know
that
doesn't
go
through,
we
will
say
that
our
client
instrumentations
will
emit
events
with
their
payloading
in
event
or
data.
E
And
in
terms
of
the
sandbox,
the
development's
not
being
done
in
Maine,
it's
actually
been
being
done
in
a
branch
Maine.
Is
there
purely
to
merge
the
Json
controls,
so
just
be
aware
of
that.
Now,
what
that
does
mean
is
you
can
create
a
clone
to
the
branch,
go
work
on
your
own
and
then
have
a
PR
to
push
it
into
the
effectively
the
development
Branch
for
this?
So
that's
one
of
the
things
for
the
collaboration
rather
than
everyone
having
their
own
personal
ones.
F
Yeah,
my
my
we,
we
are
evolving
an
existing
library
and
we
we
saw
this
opportunity
to
align
with
the
with
the
incoming
with
incoming
spec
changes,
but
what
I
heard
is
that
so,
of
course,
we
would
like
to
contribute
to
to
the
effort
overall,
but
what
I
hear
is
that
the
specification
is
is,
is
still
a
little
bit
far
away.
F
Yeah,
okay,
thank
you,
yeah
yeah,
that's
perfect!
I
will
I
will
see
what
we
can
do
in
terms
of
contribution
here.
I
would
definitely
like
to
contribute
to
the
specification
a
bit,
and
maybe
we
can
also
find
some
engineering
resources
in
in
our
room
to
to
help
support
the
implementation
of
this
concept.
F
A
And
to
give
some
confidence
on
the
specification
status,
I
think
we
have
come
quite
far
as
in
we
have
made
good
progress
so
so
far
since
we
started
now,
there
is
a
formal
definition
of
events
right
there.
There
was
no
formal
definition
of
events
when
we
started
so
so
we
we
can
certainly
emit
events
and
that
will
be
Hotel
compliant
I
I.
There
is
an
API,
also
I.
A
Think
the
there
is
a
discussion
about
structuring
the
API,
whether
it
should
have
a
dependency
on
log
API,
whether
it
should
be
an
independent
API
and
things
should
be
taken
care
at
the
sdka
level.
So
so
so
there
are
minor
changes,
but
the
good
thing
is,
with
the
data
model
kind
of
agreed.
A
F
Yeah
right,
we
started
out
with
first
clock
events,
so
we
we
are
kind
of
covered.
Of
course
it's
it's
not
using
the
under
the
covers
in
the
Pharaoh
options
that
we
are
hosting,
but
we
could.
We
could
phrase
it
as
an
intent
to
to
align
closer
with
open,
Telemetry
and,
like
the
next
best
thing
that
we
can
do,
is
align
with
the
data
model
as
long
as
not
all
the
paths
are
in
place,
but
yeah
I'm
happy
to
to
collaborate
here
and
evolve.
This
further.
A
Yeah
I
think
this
page
view
event:
abinet
is
close
to
completing
his
testing
it.
So
maybe
I'll
ask
him
to
give
a
demonstration
in
the
next
week's
meeting
and
and
based
on
that
I
think
we
can,
you
know,
see
how
others
could
be
implemented.
E
So
I
don't
think
we
actually
have
a
doodle
for
this.
Yet
we've
been
talking
about
this
on
slack
so
effectively.
It's
part
of
getting
some
TC
members
in
this
meeting.
This
meeting
currently
clashes
with
their
weekly
TC
meeting.
So
therefore,
no
one
can
attend.
E
E
Unfortunately,
it's
quite
late,
though,
for
your
people.
E
So
really
it's
an
FYI.
We
currently
do
have
a
Tuesday
meeting
at
9
00
a.m,
PST,
which
we
do
get
I,
don't
think
Josh
can
make
that
one
though
Kenny
sent
us,
which
is
why
we're
only
getting
the
jackets.
E
Yeah
so
yeah
so
Joshua
and
Jack
Berg
are
our
two
TC
sponsors
for
that
have
been
allocated
to
client
events.
So
for
them
to
be
able
to
attend
these
meetings,
we
need
to
find
a
time
frame
that
they
can
attend
the
meetings.
That's
simplistically,
what's
happening.
D
A
A
Yeah
I
think
this
would
be
a
you
know.
With
the
with
Josh
and
other
DC
members
bring.
There
will
be
good
to
make
progress
on
the
mobile
events
as
well.
So
if
more
folks
could
fill
up,
you
know
that
spreadsheet.
Then
then
we
can
arrive
at
what
will
work
for
all
of
us.
E
Yeah
and
to
talk
to
anyone
who,
also
in
yesterday's
meeting
Jack,
came
up
with
a
novel
approach
which
it
had
been
talked
about
before
in
terms
of
handling
ephemeral
resources.
So
we're
going
to
effectively
move
forward,
trialing
that
which
effectively
is
an
exporter
living
after
the
the
log
or
the
span.
So
it
won't
be
ideal
in
terms
of
automatic
support,
but
so
the
the
the
person
wanting
to
Omit
events
and
include
some
of
our
you
know
unchanging.
E
D
E
But
once
we
prove
that
that
is
necessary,
then
maybe
we
can
then
push
back
on
the
on
the
specs
and
actually
get
it
implemented
in
more
languages
than
just
what
we're
going
to
be
doing.
A
Okay,
anything
else.