►
From YouTube: 2022-07-27 meeting
Description
cncf-opentelemetry meeting-2's Personal Meeting Room
C
C
A
Now,
unfortunately,
p.m
with
pervy
at
honeycomb.
So,
okay.
A
Yeah,
so
we
have,
we
have
one
of
our
one
of
our
customers
is
interested
in
potentially
contributing,
but
I'm
I'm
not
sure
if
they're
gonna
attend
this
thing,
though
okay.
C
C
B
I
think
purvi
had
a
list
of
things
to
discuss
and
one
of
them
actually
I
was
going
to
bring
up
the
same
topic
that
cedric,
I
think
you
have
was
it
you,
I
think,
yeah
you
posted
on
slack
about
the
production
ready
artifact
for
javascript
agent.
B
I
I
my
understanding
so
far
is
that
at
least
on
the
job
browser
side
is
the
bunch
of
you
know
independent
libraries
packages
available
that
each
vendor
is
supposed
to
put
together
depending
on
how
they
want
their
agent,
like
http
versus
grpc,
json
versus
protobuf,
the
different
defaults,
whether
you
want
to
use
a
batch
exporter,
things
like
those,
but
I
think
it
doesn't
hurt
to
have
a
default
so
yeah.
B
I
think
we
could
take
it
up
so
and-
and
that's
one
of
the
things
I
was
asking
would
be
you
know,
since
you
mentioned
she
is
interested
in,
you
know
helping
we
today
we
are
going
to
go
over
a
few
things,
so
I
think
in
the
agenda.
You
could
put
your
list.
E
Yeah
I'll
put
my
list
down
there.
Should
I
put
it
after
the
couple
of
points.
I
think
some
people
have
already
added
some
agenda
items.
D
You
can
put
put
it
before
my
fyi.
It's
fine,
that's
just
a
this
is
a
mistake.
C
A
Yeah,
okay,
so
this
I
know
that
santosh
has
the
the
pr4
specification
open
for
the
logs
api
and
I
started
working
on
a
draft
of
the
implementation
for
the
api
a
couple
weeks
ago,
and
I
had
it
on
my
fork
only,
but
I
opened
the
pr
in
the
actual
upstream
upstream
repo
now
so,
if,
if
you
have,
if
you
are
interested
in
the
shape
of
the
api
in
the
js
sdk,
please
take
a
look
and
and
comment.
C
B
So,
with
respect
to
your
list,
I
think
the
the
first
one
is
is
is
kind
of
has
some
commonality
to
cedric's
question,
so
I
think
anything
production
ready,
you
know
it
will
be
good
to
you
know,
rely
on
something
stable
in
open
telemetry
and
the
json
support
is
not
stable.
It's
it's
still
experimental,
whereas
protobuf
is
stable
and
most
of
the
other
languages
environments.
B
You
know
they
they
use
protobuf
and
to
my
understanding,
the
hotel
js
for
browser
doesn't
have
support,
or
I
I
I
am
not
too
familiar,
but
I
I
think
there
is
no
good
support
for
for
that.
E
I've
actually
been
looking
into
that
a
little
bit.
I
was
at
the
jsc
last
week
and
there's
recently
there
was
a
change
made
to
the
proto
exporter
that
actually,
I
think,
uses
protobuf
js
that
library,
which
is
technically
browser
compatible.
E
So
they
are
looking
for
folks
to
test
it
in
the
browser,
which
is
something
that's
on
my
list
to
do
to
see
if
protobuf
js,
if
we
can
send
things
via
otlp
proto,
the
only
I
think
like
the
barrier
with
that
is,
I'm
pretty
sure
the-
and
I
think,
like
nev,
mentioned
this
as
well,
is
just
that
the
the
package
size
is
going
to
be
quite
large.
E
B
Is
that
is
there
a
general
agreement
on
that
that
json
will
be
the
most
common
for
the
browser.
D
During
the
the
spec
meeting
were
not
the
this
week,
but
the
previous
week,
where
tigran's
short
code
spec,
he
decided
to
close
it.
The
discussion
was
most
people
who
are
concerned
about
payload
size
will
use
the
binary
format
for
forever.
D
So
and
daniel
also
made
the
comment
that,
as
far
as
he's
aware,
the
proto
binary
is
the
most
common
one,
not
the
json
part
of
that's,
probably
because
the
json
spec
has
been
experimental,
I'm
not
sure
if
it's
even
getting
close
yet
there's
still
an
open
issue
about
how
enum
values
are
stored
in
in
json.
D
The
short
codes
delayed
that
a
little
bit,
because
that
was
going
to
be
a
big
change
but
yeah.
It's
it's
problematic.
C
D
At
this
point,
because
javascript
doesn't
have
yeah:
okay,
okay,.
D
So
effectively
for
your
reference,
morgan,
the
there
is
an
experimental
json
exporter
in
javascript,
but
it's
still
experimental
because
the
json
spec
hadn't
gone
up.
B
Okay,
so
if
you
were
to
take
up
one
of
these
two,
which
one
would
it
be
like.
B
Don't
know
if
you'll
have
bandwidth
for
both
if
you
have
that
will
be
great
yeah.
E
Yeah,
I
think
I'll
probably
start
looking
into
what
protobuf,
what
the
protobuf
exporter
and
the
browser
support
is
like,
since
that
is
currently
stable
and
keep
an
eye
on
the
the
jason
speck
as
it's
moving
through
there's
a
few
other
folks
on
my
team
at
honeycomb
that
go
to
the
spec
sig.
But
I
think,
as
nev
said
it's,
it
doesn't
seem
like
it's
like
super
close
or
anything.
E
So
and
nev
did
you
mention
that
part
of
with
with
your
like
fork
of
the
js
sandbox
is,
is
for
minification,
which
should
help
with
the
bundle
size
stuff.
If
we
were
to
use
the
protobuf
exporter
in
the
browser.
D
Yeah,
that's
one
of
the
primary
goals
of
the
sandbox
is
to
effectively
take
what
we've
got,
which
is
my
fyi
there.
So
I've
now
got
merging
of
the
history.
That's
really
all
that
first
pr
is
doing
so.
It's
set
up
with
an
automated
script,
so
we
can
run
it
periodically
to
just
suck
in
the
latest
version
from
js
and
js
api.
D
So
we
can
then
have
a
branch
to
work
specifically
on
minification.
We
can
play
with
it.
We
can
publish
it,
we
can
get
it
all,
but
once
we're
happy
with
it,
we
can
then
contribute
those
changes
back
to
the
the
official
master
repos,
which
is
json.
Yes,
api
awesome.
If
that's
not
going
to
work.
The
other
goal
of
the
sandbox
is
okay.
If
it,
if
it's
not
possible,
to
be
able
to
contribute
back
and
work
in
both
node
and
browser,
then
we'll
also
use
the
sandbox
to
create
a
web
specific
sdk.
Okay,.
B
So
there
is
a
an
issue
that
martin
created
yesterday.
I
think
it
has
some
comments
from
daniel.
You
know
in
the
agenda
notes,
so
you
could
take
a
look.
Martin,
you
could,
when
I
signed
that
ticket
to
ruby,
yeah.
C
B
Yeah,
I
can't
either
martin.
Can
you.
D
Can
you
paste
it
to
the
thing
I
might
be
able
to
because
I'm
an
approver
on
the
js
stuff?
Sorry.
B
So
before
we
move
to
the
next
topic
on
the
agenda
list,
a
related
topic
would
be.
Would
we
would
it
be
like
once
we
use
protobuf?
Would
it
be
http
or
grpc.
E
For
the
question
of
grpc
or
http,
I
think
in
my
mind
I
was
leaning
towards
http,
because
I
think
that
is
the
language
of
network
communication,
with
the
browser
that
most
folks
would
be.
Most
users
would
be
comfortable
working,
whereas
I
think
grpc
is
not
as
familiar
to
people
working
in
the
browser.
That's
that's
my
feeling.
A
B
What
is,
how
is
the
consideration
like
what
is
different
with
grpc
versus
http
during
unload.
A
C
E
B
Yeah,
unfortunately,
it's
not
converging
but
to
give
some
background
yeah
we
have
had
several
discussions
on
it.
I
think
the
primary
contention
is,
you
know
where
to
you
know,
put
the
session
id
you
know,
should
it
be
sent
once
at
the
resource
level.
B
You
know
something
that
is
common
to
all
the
spams
and
you
know
logs
sent
in
the
payload
or
you
know,
sent
it
send
it
at
each
of
the
you
know,
signal
level
should
be
in,
in
which
case
you
know
it
would
be
repeated.
B
So
let's
say
you're
using
a
batch
exporter.
You
know
you
would
be
sending
like
you
know,
10
or
20.
You
know
spans
in
in
one
request.
You
know
we
would
be
repeating
the
session
id
and
some
of
us
in
this
group.
You
know
we
feel
it's.
You
know
not
good
to
repeat
it.
There
are
already
enough
reasons
why
the
the
payload
sizes
are,
you
know
large,
so
we
wanted
to
send
it
at
a
you
know
once,
but
there
is
no
good
place.
Unfortunately,
you
know
the
resource
is
immutable.
B
The
spec
doesn't
allow
the
resource
to
be
modified
once
it's
created
and
I
think
ted
he
tried
to
create
a
new
tip,
introducing
the
concept
of
ephemeral
resources
where
he
was
marking
some
of
the
attributes
after
resource
has
ephemeral
and
those
could
be
allowed
to
change,
but
I
think
there
is
a
there
hasn't
been
a
agreement
on
that.
B
So
I'm
now
wondering
if
we
were
to
take
it
up,
you
know
we
could
at
least
design
an
api.
You
know
that
is
that
we
all
agree
on
and
then
how
that
api
implements
sending
the
session
id,
whether
at
the
signal
level
initially
and
later
on,
you
know,
move
it
somewhere
else.
You
know
that.
B
Could
you
know
we
could
modify
that
you
know,
as
as
things
progress
and
and
keep
it
experimental
in
status.
Now.
E
Yeah,
that
makes
sense,
I
think
it
instead
of
it
being
stalled.
It
might
be
okay
like
if
we
pick
a
direction,
even
if
it's
experimental
to
work
towards
something.
I
think,
like
the
bigger
question
that
me
and
winston
were
talking
about,
was
like
how
do
traces
relate
to
a
single
session,
also,
which
is
something
that
we
we
we
haven't
really
delved
into
it
yet,
but
we
were
kind
of
thinking
about
it.
A
little
bit.
B
Yeah
and
basically
there
has
to
be
another
entity,
let's
say
a
session
manager,
who's
responsible
for
tracking
the
session
and
and
then
you
know
whenever
and
there
could
be.
You
know,
different
criteria
for
saying
hey
session
has
ended.
A
new
session
has
to
start.
B
I
I
think
there
was
one
concern
that
bogdan
has
raised
in
the
past,
where
it
you
know
in
in
this
definition
of
sessions.
You
know
we
are
not
clearly
defining
the
session
boundary.
You
know
there
is
no
clarity
as
to
you
know,
which
spans
would
be
part
of
you
know
which
session
the
and
I
think
at
least
at
the
sessions
implementation
at
cisco
appdynamics.
I
think
it's
it's
loosely
defined
and
it
you
know
didn't
matter.
B
This
is
more
of
a
very
high
level.
Understanding
of
you
know
how
many
active
users
are.
Currently,
you
know
using
your
application
and
a
few
you
know
it's
it's
I
mean
it
it's
okay,
for
if
the
boundary
is,
you
know
not
super
clear,
okay,
but
if
there
are
any
other
definitions
of
sessions
that
you
know,
somebody
could
define
that
is
more
deterministic.
D
Yeah
and
then
in
the
case
of
like
app
insights,
the
same
thing
like
sessions
are
proven
a
lot
by
the
application.
So
if
it's
a
postback
model,
then
it's
a
cookie,
it's
nice
and
easy.
If
it's
a
spa,
then
if
you've
got
like
a
login
logout,
then
it
gets
defined
by
the
app.
So
it's
got
to
be
flexible.
D
The
other
concept
that
we
have
so
we
effectively
store
this
stuff
in
there's
two
different
cookies.
One
is
ai
session,
which
is
the
session
id
and
the
other
one
we
have
is
ai
user,
which
effectively
is
an
anonymous
user
that
we
use
to
identify
that
person
across
sessions.
So
if
a
user
logs
in
on
day
one
and
on
day
10
they
come
back,
we
can
say
well
if
this
user
started
a
different
session
again,
it's
all
just
it's
just
a
random
good,
but
that
cookie
lasts
for
a
year.
C
A
I
would
just
I
would
just
like
add
to
that
that,
from
my
perspective,
it's
important
to
make
that
distinction
between
like
a
session.
That's
like
you're,
saying
that,
like
session,
that
just
ties
all
the
telemetry,
that's
related
to
a
one,
one
user
and
then
a
session.
That's
more
like
a
like
application
defined
session.
When
you
log
in
log
out.
A
B
And
then
the
next
one
I
don't
have
much
knowledge.
I
think
others
could
comment.
E
Yeah,
I
just
first
adding
some
context
to
this.
I
so
I've
been
playing
around
with
instrumenting
browser
stuff,
and
one
of
the
things
I
ran
into
almost
immediately
was
using
context
in
asynchronous
functions
and
like
maintaining
that
context
and
then
so,
when
I
went
back
to
the
open,
telemetry
docs,
it
said.
E
Oh
hey,
you
need
to
use
the
this
package
context,
asynch
asynchronous
to
keep
the
context
when
you
are
dealing
with
asynchronous
situations
and
when
I
plugged
it
into
my
browser
app
immediately,
it
didn't
work
because
I
think
it
relies
on
a
node
specific
thing.
So
I
think
we
will
want
support
for
that
in
the
browser
as
well.
I'm
like
so.
If
someone
please
correct
me
if
I'm
wrong
like,
I
might
have
been
doing
something
incorrect,
but
it
wasn't
working
in
my
browser
app.
E
So
one
of
the
things
that
I
definitely
wanted
to
look
at
was
opening
an
issue
and
looking
into
how
we
can
make
this
work
in
the
browser
as
well
I'll
post
I'll,
put
some
links
in
the
doc.
E
Yeah,
I've
used
the
zone,
context
manager
and
then
there
was
a
note
on
it.
That
said,
it
was
not
deprecated
but
using
like
es2015
and
it's
not
supposed
to
be
used,
and
so
that's
maybe
this
is
more
of
a
like
dox
issue
or
like
a
testing
it
out,
but
even
with
the
zone
context
manager,
sometimes
my
context
doesn't
do
the
things
I
expect
it
to
do,
but
I
can
open
an
issue
about
that.
D
Yeah,
I
think
in
my
initial
pr
which,
which
just
copied
the
files,
one
of
the
pain
points
I
had
was
like
all,
but
one
or
two
of
the
projects
compiled
and
were
tested
on
web.
So
I
went
and
added
web
tests
for
everything
and
the
other
context
was
a
bit
of
a
pain
point
to
getting
that
going.
C
D
So
that
that
will
be
once
the
history
one
goes
actually
I'll
put
a
link
in.
I
think
I
put
a
link
in
it
previously.
My
next
thing
is
to
create
a
another,
automated
script,
based
on
that
one
to
effectively
push
the
history
into
the
form
that
ultimately,
we
want,
or
ultimately
undefined
so
still
so
much
work.
E
Yeah
sure
the
last
thing
so
we're
gonna
be
looking
into
this,
and
it
would
be
handy
if
I
think
santoshi
mentioned.
Martin
is
already
kind
of
looking
into
auto
instrumenting
browser
events.
E
So
that's
something
we're
going
to
experiment
with
and
hope
to
then
converge
on
something
upstream
as
well
in
the
next
few
weeks
or
so
yeah.
So
currently,
thinking
about
what
types
of
like
browser
apis
and
events
we
can
hook
into
to
to
create
some
useful,
auto
instrumentation.
B
Yeah,
so
I
I
think
the
there
is
going
to
be
an
api
for
recording
standalone
events,
the
events
that
occur
outside
the
context
of
a
span,
so
you
know
one
would
be
able
to
record
them.
They
would
be
sent
as
log
records.
E
E
I
think
it
depends
on
like
how
you're
using
that,
I
think
so
for
us.
It's
like
we
want
to
see
everything
that
we
can
emit
and
see
if
we
can
answer
unknown
unknowns
from
together
different
types
of
data.
D
I
dropped
in
the
the
click
analytics
plug-in
for
map
insights.
You
can
see
what
sort
of
events
that
that
tracks-
it's
mostly
click
tracking
but
you'll-
see
how
it
if
you,
if
you
want
to
dig
into
the
details,
you'll
see
how,
when
you
do
a
click,
it
looks
the
dom
to
get
additional
data.
D
So
something
like
that,
if
the
user
interaction
that
that's
been
added
doesn't
already
do,
it
might
be
something
that
at
least
us
here
at
microsoft
will
eventually
assuming
we
get
the
web
going,
contribute
that
into
hotel.
So
I
don't
have
a
timeline
for
that,
but
a
lot
is
going
to
pivot
on
whether
we
can
make
it
work
in
the
web,
which
is
that
bundle
sizing
issue.
A
And
one
thing
I
also
want
to
point
out
is
that
we've
been
talking
about
defining
semantic
conventions
for
different
types
of
events,
and
we
haven't
gotten
very
far
so
far.
We
have
discussed
only
timing
events.
A
We
talked
about
the
navigation
navigation
event,
which
would
be
like
coming
from
the
navigation
timing,
api
and
resource
from
the
resource
api,
but
I
think
this
one
like
for
interactions,
clicks
or
tabs,
or
things
like
that.
I
think
we
probably
might
need
to
talk
about
or
did
discuss
what
what
the
semantic
convention
is.
Gonna
have.
C
D
I
think
we
have
the
basic
shape,
though
so
we
have
like
event.domain
event.name
event.data,
although
I
am
a
little
concerned
with
having
nested
attributes
in
event
data
because
of
how
we
have
to
exploit
them.
But
sorry,
which
I
put
a
the
nested,
attribute
clarification
pr
in
there
as
well.
That's
getting
lots
of
pushback
that
may
not
get
in
there.
So.
C
B
So
yeah,
I
think,
once
the
api
implementation
is
is
available.
I
think
you
know
you
could
you
could
basically
start
implementing
or
extending
this
package
user
interaction
package
for
other
things.
E
I
don't
think
so
I'll
report
back
in
the
next
week
or
two
weeks
about
the
bird
above
stuff.
D
Probably
one
thing
to
keep
in
mind,
which
I
realized
this
week
is:
if
you
have
any
users
that
are
still
targeting
ie,
even
though
it's
now
dead,
open
telemetry
is
probably
not
gonna
work,
they
they
do
rely
internally
on
symbols.
So
unless
you
polyfill
them,
it's
not
gonna
work.
D
I
guess
that
brings
me
to
my
two,
which
is
really
just
fyis,
which
I've
already
talked
about.
One
is
the
the
nested
attribute,
which
is
the
last
one.
That's
been
ongoing
for
a
while
getting
lots
of
pushback,
even
though
it's
just
clarifying
what
protobuf
does
today
and
I'm
been
doing
almond
suggestions,
I'm
the
latest
ones
are
a
bit.
D
I
think
going
a
bit
too
far
in
terms
of
saying
must
not,
but
I
think
I
got
the
wording
wrong
instead
of
saying
optional,
it
should
have
been
supported
on
the
table
which
I'll
probably
make
that
change
and
the
other
one
is
just
the
pr
so
daniel's
out
most
of
this
week.
I
think
he's
out
today,
so
I
don't
think
the
javascript
sig
is
going
to
be
doing
much
today.
D
If
you
can
have
a
look
one
of
the
big
questions,
there
is
the
names
that
I've
got
in
the
script,
for
the
branches.
Is
that
what
we
want
to
use?
Or
do
we
want
to
go
to
a
slightly
different
structure?
A
It's
it's
on
my
list
to
look
and
look
into
probably
today.
D
D
E
A
I
this
this
draft
pr
for
the
semantic
conventions
for
the
browse
tool,
browser
events.
I
asked
for
feedback
a
couple
of
weeks
ago.
I
would
like
to
I
mean
if
there's
no,
no,
no
feedback,
that's
fine,
but
I
I
would
like
to
maybe
open
propose
that
into
the
upstream
upstream
spec
repo,
and
I
just
want
to
make
sure
that,
like
people
think
that
it
looks
okay,
let
me
just
put
it
here.
A
Okay,
yeah,
I
mean
if
it's
it's
it's
it's.
The
reason
I'm
asking
here.
First
is
because
it's
it's
a
little
bit
different
than
the
semantic
conventions
that
are
used
right
now
in,
in
the
sense
that
it
defines
like
the
the
specific
name
of
the
event
and
domain
and
then
the
attributes
that
are
specific
to
that
event,
as
opposed
to
like
a
namespace
namespace
set
of
attributes
that
that
the
current
semantic
conventions
have.