►
From YouTube: 2022-12-06 meeting
Description
Instrumentation: Messaging
B
B
B
C
C
A
It's
just
that
it's
it's
currently
not
straightforward.
To
add
that
to
the
semantic
conventions,
yeah
and
I
was
talking
the
last
lock
Sig
and
both
tigran
and
Jack.
You
know
they.
They
said,
you
know
they
will.
You
know
you
know,
take
that
other
issue
forward,
which
is
supporting
the
maps
for
attribute
values
for
all
signals.
Yeah.
A
Yeah
yeah,
although
Jack
said
you
know,
there
is
some
resistance
from
the
Java
community,
the
other
Java
maintenance.
So
so
he
he's
going
to
you
know,
bring
them
into
the
discussion,
but
there
seems
to
be
General
agreement,
so
I'm
I'm,
wondering
you
know
I
think
we
can
like
from
our
perspective.
We
can
consider
it
done
yeah
so
like
we
don't
need
to
be
blocked
on
getting
that
added
to
the
spec,
but
does
it
like
if
we
were
to
add
that
support
in
the
in
the
in
the
JavaScript
repo?
B
So
there's
still
the
general
concern
that,
like
an
attribute,
is
not
an
attribute,
so
it
would
have
to
define
a
log
attribute
to
support
that,
because
the
attribute
definition,
sorry
that
might
be
accurate
value
I,
don't
remember-
is
currently
locked
down
for
the
type
of
typescript.
So
we
would
need
to
open
that
up.
So
the
easiest
way
to
do
that
unless
the
other
issue
gets
pushed
in,
is
just
to
define
a
log
attribute
which
says
anything.
B
Because
the
SDK
is
typescript,
it
tends
to
be
locked
down,
so
you
can
say
any,
which
is
what
we
need
to
do
so,
which
is
why
I'm
saying
we
could
Define
a
type
of
log
attribute
that
says
it
extends
attribute,
but
it
can
also
take
a
type
of
editing
or
we
go
and
Define
that
it
takes
a
map
of
any
but
yeah
just
straight
pure
JavaScript.
It
would
just
work
today
anyway,
but
most
people
using
typescript
and
the
SDK
is
created
using
typescript.
So
it
would
actually
fail
right
now.
B
B
B
Yeah-
and
you
know
like
it's
okay,
so
if
we
have
so
either
we
just
go
okay,
we
will
start
evolving
towards
Cloud
events.
Well,
we
just
say
we're
going
to
take
it
and
I
I
think
the
data
schema
was
optional,
so
we
could
just
say
for
a
log
event.
This
will
be
the
the
default
value
of
data
schema,
which
hopefully
is
the
same
value
as
the
card
events,
but
yeah
I.
Don't
it
was
been
several
weeks
and
I've
been
on
leave
yeah.
C
B
A
C
B
Yeah
and
which
is
why
the
the
yaml
files
exist
in
American
Telemetry,
like
the
same
sort
of
reason
so
like
if
we
just
said
four
events,
you
know
we'll
do
it
this
way,
that'll
be
that'll,
work,
I,
think
and
I.
Think
the
other
comment
you
had
to
hear
something
about
or
that
the
name
and
domain
I
think
that
could
just
be
a
case
of
well
or
a
open,
Telemetry
event.
They
just
get
included
and
it
just
happens
to
be.
B
B
So
I
guess
my
simple
answers
to
your
questions
too.
I
think.
Yes,
we
can
start
with
a
container.
Is
there
anything
else?
We
need
the
event
spec
if
we
start
defining
in
the
line
with
Cloud
events,
I
think
that
would
work,
especially
if
that's
where
the
log
Sig
is
heading
because
I
think
there's
a
lot
of
good
support
there
and
I
think
most
of
the
stuff
that
we
don't
need
is
optional,
so
we
can
just
say
well
for
us
we
don't
Define
it
in
terms
of
I.
A
B
So
yeah,
so
we
can
just
potentially
use
that,
or
we
just
say
we're
going
to
say
it's
a
Json
by
default
for
us,
which
would
then
mean
that
we
would
need
domain
and
name
to
say
well.
If
it's
a
one
of
our
defined
the
main
name
combinations,
then
it's
Jason,
it's
the
default
player
schema.
Maybe
the
way
to
do
it
and
I,
don't
know
the
question
the
last
one,
yeah
yeah
no.
B
But
yeah
so
effectively,
we
would
need
some
way
to
hook
into
the
logs
transport,
which
the
log
API
would
have
been
now
hooked
into
that.
So
it
would
mean
if
they
completely
dropped
the
log
API
that
each
language
would
have
to
Define
its
own
way
to
effectively
create
the
events
API
the
talk
to
logs
it
would
be
preferable
if
I
kept
the
you
know
the
log
API
for
a
Pender,
otherwise
we're
gonna
have
to
define
something.
B
B
A
B
A
C
B
A
D
A
D
A
A
D
B
B
Okay,
which
is
why
I
was
only
originally
looking
at
the
spec
of
cloud
events
like
it
is
just
a
Jason
spec.
We
can
do
that
and
conforming
that
into
the
log
event.
As
the
transport
like
the
the
spec,
does
talk
about
protocol
and
they
say
it
could
be
Jason,
but
for
us
in
open
Telemetry,
the
protocol
would
be
an
open,
Telemetry
log
event.
So.
A
Yeah,
no
I
think
my
my
inclination
is
still
to
keep.
You
know
what
we
have
so
far.
Even
if
it's
not
part
of
the
spec
yeah
I
mean
the
the
API
will
not
be
part
of
the
spec,
but
the
the
definition
of
event
will
will
continue
to
be
yep.
So
as
long
as
we,
we
have
a
JavaScript,
specific
API
to
create
events
in
that
specific
format.
I
think
we
are
good.
C
D
C
A
Yeah
yeah
I
think
yeah
I
think
there
is
a
lot
of
confusion
with
the
way
open.
Telemetry
is
designed
the
data
model.
Everybody
looks
at
the
protobuf
and
says:
hey
you
know,
did
they
go
by
you
know
like
in
our
company?
You
know
internal
discussions,
a
lot
of
people
look
at
the
support.
You
know
this
in
this
field,
but
the
specification
you
know
prohibits
you
know
things
yeah
and
and
they're
not
aware,
so
so
I
think
customers
are
going
to
do
that
too.
C
B
C
B
I
see
but
yeah
I
guess
in
terms
of
terms
of
the
sandbox.
Now
that
I've
put
up
on
my
emails,
I've
got
some
stuff
on
finishing
off
today,
I
plan
to
spend
like
the
next
two
weeks
before
my
holidays
again
effectively
getting
the
sandbox
going
in
terms
of
getting
main
up
and
running.
That's
that's
my
planned
Focus.
B
B
D
B
What's
that
look
like
open
now
for
breakfast,
that's
the
usual
creation!
That's
my
language!
I
want
to
go
back
to
this
one
yeah.
So
there's
an
auto
merge,
pull
request,
that's
sitting
there
waiting,
and
that
was
from
19
days
ago.
That's
the
one
I
did
and
that's
just
effectively
merging
the
the
JS
and
the
Contra
Brew
pose
at
that
point
in
time.
B
Yeah,
it's
gonna
happen
this
time
of
year,
so
so,
once
this
one
goes
in,
so
my
the
auto
merge
script
only
allows
one
PR
at
a
time
so
quickly.
We
have
to
commit
this
one
before
commit
or
close
this
one,
and
then
I
can
run
the
script
again
and
it'll
update
It
Whatever.
The
current
basically
is
of
both
of
those
so
and
that
just
sinks
into
the
repo
sync
Branch.
B
What
I
call
it
repo
staging
but
yeah
the
the
next
script
I
need
to
work
on
is
taking
you
out
of
that
branch
and
putting
it
into
main
and
as
part
of
that,
it
has
to
do
a
lot
of
work
like
renamed
all
the
packages
to
have
sandbox
in
their
name.
So
instead
of
just
open,
telemetry.js
it'll
be
open,
telemetry
sandbox.js
and
then
update
all
the
references.
B
It's
going
to
use,
rush
and
roll
up
the
generating
bundles
I
want
to
generate
bundles
for
everything
that
I
bring
over
so
that
the
main
will
have
like
this
is
what
the
core
is.
This
is
how
big
the
bundles
are
by
default,
so
that,
when
we
go
from
playing
branches,
we
can
do
a
comparison
with
those
and
potentially
add
tests
to
say
bundle.
Size
has
got
too
big,
which
is
what
we
do
internally
for
our
stuff
and
app
insights.
B
But
yeah
just
having
the
bundles,
so
we
can
do
a
manual
compare
file
sizes,
it's
a
good
start,
especially
for
like
the
Tracer
web
example.
I
wanna
I
did
that
manually
last
year
and
that
highlighted
the
fact
that
it
was
just
way
too
big.
So
if
I
can
have
that
auto
generated
for
everything
that
would
be
excellent.
C
B
C
B
C
B
B
B
No,
so
all
the
pr
that
open
now
is
doing
is
bringing
the
history
and
the
files
from
the
JS
and
the
contributes
and
is
staging
them
in
a
factory
separate,
subfolders,
okay,
so
I
guess,
which
color
code
link.
Thank
you
go
to
the
readbook
staging
branch
yeah.
So
there's
an
auto
merge.
So
this
is
the
main
right.
So
if
you
look
in
there
effectively,
it
creates
an
auto,
merge,
folder
and
then
there
has
a
Json,
a
country
so
effectively
the
contents
of
those
GS
and
contribute
folders
in
Auto.
B
B
A
A
You
can
actually
I
briefly
discussed
with
ram
last
week,
but
I
think
on
the
first
one.
If
we
like,
basically
once
we
list
down
the
you
know
the
you
know,
what
attributes
go
to
what
events
are
the
attributes
that
each
event
consists?
You
know
how
do
what
are?
What
is
the
next
step
like
in
terms
of
implementation?
B
Bikes
on
the
history
and
open
Telemetry
I
would
like
to
avoid
the
workarounds,
because
once
the
workaround
is
there,
that'll
become
what
it
is,
and
people
go
well.
You've
already
got
that,
so
it
would
be
nicer
to
try
and
push
the
ephemeral
resources
first,
but,
as
you
say
in
terms
of
like,
if
we've
already
defined,
what
the
fields
are
for
in
number,
one
which
is
I
think
is
where
we're
at
we're
really
saying.
Okay,
we've
defined
that
some
we
can
start
doing
implementations
we're
going
to
need
somewhere
to
put
those
criminal
resources.
A
Okay,
let
me
bring
him
today:
I
I
was
hoping
in
the
more
than
10
I.
Think
I
I
was
hoping
that
we
could
get
the
other
folks
who
are
actually
working
on
the
on
this
problem
like
Josh
and
tigarden
yeah.
You
know
in
as
per
the
ticket
conversation
yeah
since,
since
they
are
going
to
add
another
collection
of
attributes
in
resource,
you
know
I
thought
I'll
piggyback
on
their
discussion.
Yeah.
B
Yeah
I
I
guess
in
terms
of
proof
of
concept,
or
you
know
you
know
basic
definitions.
If
we
want
to
make
progress,
we're
probably
going
to
have
to
do
the
workarounds,
but
we
can
Define
we.
We
could
have
our
documented
definition
saying
it
is
assumed
that
these
are
going
to
be
in
the
resource
and
then
maybe
your
name
implementations
to
get
something
working.
We
we
do
it
that
way.
So
that
way,
it's
we're
using
the
workaround,
but
we're
not
documenting
the
work
around
if
it
makes
sense.
A
A
I,
don't
even
know
what
the
workarounds
would
be
like,
for
example,
you
know
these
last
two,
the
mainly
the
browser
page
URL
like
let's
say
for
the
single
page
application
we
we
want
to
emit
events
and
and
given
that
that,
in
a
page,
URL
is
going
to
be
constant
for
all
those
events.
You
know
we
wanted
to
put
it
in
the
resource.
Yeah.
B
B
C
B
A
Okay,
so
then
maybe
yeah
I
think
we
are
to
you
know
running
out
of
patience,
because
we
we
have
timelines
too
so
I
think
in
maybe
you
know,
I'll
bring
it
up
one
more
time
in
the
next
spec
Sig
and
if
it
doesn't
move
then
at
least
from
our
side.
I
think
we
are
we're.
Okay
to
you,
know
take
this
forward.
You
know
in
the
individual
signal
attributes,
yeah.
B
And
I
say
like
we
could
try
prefix
it
with
something
to
make
it
obvious
just
so
we
can
get
some
proof
of
content
and
get
something
going
and
I
guess
if
we
have
the
prefix
and
we
end
up
releasing
that
it
means
in
the
future.
Someone
can
say
well
if
this
is
here,
we're
going
to
use
it
otherwise
we'll
use
that
one
so
not
ideal.
But
okay
by
the
time
we
get
to
GA
I
would
hope
we
have
it
sold,
but
yeah
yeah
chances
are
probably
explained.
A
Yeah
I
also
want
to
discuss
about
the
naming
of
these
events.
That
gray,
we
call
it
document
load
and
that's
a
that's
a
span
and
you
know,
and
we
in
deposit
you
know
we
also
discussed
having
separately
an
event,
so
I
think
only
one
is
listed
here.
Do
you
want
me
to
list
are?
Are
they
both
supposed
to
contain
the
same
set
of
fields
so,
except
that
yeah.
B
This
comes
back
to
the
actual
instrumentation,
so
my
preference
would
be
to
say
the
event
is
page
view.
The
instrumentation
can
go
and
create
expand
call
document
load
in
terms
of
its
implementation.
I
would
like
to
have
that
as
effectively
a
span
event,
which
is
this
event,
so
we
have
a
mapping
which
is
you
know,
part
of
the
whole
definition
like
I
when
we
Define
events
here,
I
wouldn't
I
would
want
to
be
a
let's
say.
B
Well,
when
we
have
a
log
event,
you
can
map
that
to
a
span
event
like
this
I've
always
wanted
that,
so
that
we
can
then
just
say,
go
create
spans
and
do
this.
The
other
option
is
the
instrumentation
correct
could
create
a
document
load
span,
which
is
then
linked
to
the
log
event
and,
of
course
the
existing
one
is
that
it's
already
finished
rotation.
The
crates
document
load.
That
is
not
going
away.
A
Yeah
I
think
the
in
the
for
the
existing
instrument.
I
think
we
can
add
the
missing
attributes
yeah,
you
know
from
this
list
and
then
separately
create
another
event
which
would
get
shipped
right
away
without
waiting
for
the
the
timing,
information
to
be
available
and
and
that
event
you
know
like,
we
also
have
the
same
sort
of
fields.
You
know
whatever
is
available.
B
For
the
the
crossover
for
compatibility,
I
think
we're
going
to
have
to
so.
Ideally,
eventually,
you
would
just
have
the
document
load
event,
which
has
sorry
the
document
load
span
which
has
the
event
associated
with
it.
So
you
would
only
pick
up.
The
data
would
only
be
transmitted
as
the
event,
whether
that's
a
span
event
or
a
log
event.
B
B
A
And
then
it
will,
it
will
create
in
an
event
with
with
all
these
fields,
with
all
these
attributes
and
then,
when
the
when
the
timing
information
is
available,
or
rather
whenever
you
know
the
page
is
loaded,
you
send
out
this
event
as
a
log
record
yep,
and
then,
when
the
timing
info
is
available,
then
you
send
a
span
with
with
two
events
right
with
a
one.
With
with
this
information
and
one
with
the
timing
in
timing
parameters.
B
A
B
B
Yeah
is
that
what
the
instrumentation
does
I
don't
know,
considering,
probably
yourself
and
I,
think
T2
were
already
using
the
document
load
yeah
for
us
from
Microsoft.
It
is
just
row
eight,
but
it's
all
we're
interested
in
because
today
all
we
do
is
send
events.
We
don't
have
the
spam
concept
for
a
browser.
D
I
I
did
another
one
derail
the
conversation
but
I
I
just
wanted
to
say
to
a
couple
things
like
when
we
talk
about
page
View
events,
it's
like
we
talked
about
impression,
the
impression
event
yeah
and
then
the
one
that
has
the
timing,
the
navigation
timing.
So
the
event
that
you're
talking
about
specific
ways
to
navigation
timing,
one
for
page
view
is
that
correct.
D
D
Now,
because
that
navigation
timing
event
can
be
sent,
you
know
independently,
like
it
can,
and
it
can
also
happen.
The
thing
is
like
the
the
span,
the
document
load
span
Waits
until
the
load
event
window,
unload
event,
fires
right
but
like
let's
say,
let's
say
that
you
know
you
the
page
is
abandoned
or
or
like
for
some
reason
like
the
window
load
even
takes
a
really
long
time.
You
still
will
get
some
navigation
timing
information
and
you
can
still
send
that
event.
D
Yeah,
so
I
would
I
would
prefer
to
have
it
in
a
separate
package
and
like
have
it
have
a
little
bit
different
logic
when
it's
being
sent
from
the
spam
I
mean
it
can
still
get
the
context,
the
trace
context
from
the
span
and
can
be
linked
that
way,
but
I
wouldn't
put
it.
You
know
as
a
as
an
as
a
span
event
on
that
span.
Yeah.
B
I
guess
that's
indirectly
what
I
was
saying
with
the
existing
document.
Load
instrumentation
would
stay
the
same
and
we
create
another
one
rather
than
like.
We
could
alter
the
existing
one
to
include
the
additional
Fields
as
well,
so
that
the
existing
document
load
also
includes
the
the
additional
fields
that
we're
defining
here.
B
A
A
A
D
A
I
thought
it's
the
other
way
that
you
know
the
Analytics
use.
Cases
is
one
and
the
monitoring
use
case
is
another.
So
if,
if
we
were
talking
about
troubleshooting
use
cases,
then
the
tracing
is
more
important,
but
if
you
are
talking
about
analytics
use
case
like
yeah
how
many
people
are
visiting
which
page
then
the
page
impression
is
important.
B
Yeah
it
it
sort
of
depends
like
if,
if
you've
got
like
you're
fetching
xhr
request,
they
would
I
think
definitely
have
spans
associated
with
them.
I.
You
know,
I
can't
think
why
you
would
not.
You
could
do
it
today
because,
like
we
do
it
today
without
spends,
but
we
sort
of
simulate
the
span
based
on
the
impression
ID,
but
in
an
open,
Telemetry
world
I
think
we
would
always
want
them
to
be
spans.
B
So
if
you're
doing
that,
then
effectively
we're
saying
the
base
for
a
browser
would
be
spans
and
logs,
because
we
need
logs
for
events,
but
for
metrics
is
the
is
the
one
where
based
on
the
size
of
the
metrics
package.
I,
don't
think
you'd
want
to
include
that
in
terms
of
the
Browser
Bundle
by
default,
yeah.
A
A
B
B
A
Although
I
think
the
the
meaning
changes,
so
the
page
fetch
is
the
one
that
currently
talks
about
the
actual
API
call
and
so
that
information
will
now
move
into
you
know.
So,
basically
the
page
fetch
becomes
the
parent
the
span,
and
then
that
is
linked
with
the
page
view
event
and
the
page
navigation
event
right.
So
so
let
me
write
you
know
separately,
so
so
there's
a
page
fetch
is
the
span.
A
B
A
B
A
A
D
D
D
D
Two
apis
there's
a
resource
timing
and
there's
another
navigation
timing
and,
like
the
resource
timing,
will
give
you
all
of
the
resources,
including
the
HTML,
that
was
that
was
loaded
and
the
navigation
timing.
It
just
gives
you
like
the
the
points
in
time
when,
like
the
document,
they
were
like
significant,
even
during
the
page,
like
loading,
the.
A
Page
so
so
my
reading
was
different.
Last
time,
I
looked
at
it.
My
understanding
was
that
the
parent
page
navigation
parent
span
Waits
until
both
the
HTML
span
completes
and
the
let's
say
it
has
like
10
resources,
all
of
them.
You
know
they
they
complete
loading
and
then
the
parents
panel.
So
the
parent
encompasses
the
the
HTML
span
and
the
individual
resources
plan,
but
the
HTML
span
you
know,
doesn't
need
to
wait
it
only.
A
A
D
A
D
A
D
Okay,
so
so
page
fetch
is
is
is
basically
the
same
as
resource
fedge
like
the
it's
just
like
that,
in
my
at
least
like
the
way
I'm.
Think
of
it,
like
the
page,
fetch
is
like
specific
resource,
that's
a
document,
HTML
document
resource
and
then
then
the
parent,
the
page
navigation
parent
span
that
you
have,
which
we
call
document
load.
It's
it's
just
made
up
made
up
span
that
ends
when
the
window
load
event,
fires.
A
B
Okay,
so
I
just
put
a
link
into
the
document
load
code.
That's
in
the
the
merge
repo,
because
that
was
a
single
place
for
both
and
yeah
effectively.
It
creates
the
root
span.
It
then
immediately
creates
the
fetch
span
and
ends
it
and
then
creates
the.
Where
is
it
the
resource
span
and
then
looks
like
it
ends
it
as
well,
not
on
that
ends
of
root
span,
so
yeah
they're,
like
the
fetch
span,
is,
is
really
just
the
event.
B
A
I
think
I
remember
now
what
this
d80s
I
think
this
is,
you
know
just
the
you
know,
event
for
representing
the
array
of
events
that
is
today.
You
know
into
one
event
object.
So
today,
all
the
timing
parameters.
You
know
there
are
separate
events,
so
in
each
of
these
you
know
in
the
page
fetch
span
and
the
resource
fetch
spans.
You
know
we,
we
have
the
timing
parameters
as
an
array
of
events,
yeah
yeah
exactly.
Instead,
you
know
that
you
know
that
will
be
represented
in
a
different
form
and
that.
A
A
B
Where
it
might
be
safer
to
have
a
different
instrumentation,
whether
it's
at
the
same
instrumentation
package
and
you
have
like
a
V1
V2,
that's
just
like
how
we
get
it
there,
but
I
I
think
it
might
be
safer
to
have
keep
the
existing
instrumentation
using
spans.
And
then
we
have
a
new
generation
which
can
have
all
these
configs.
If
you
like,
of
specifying
it
as
a
span
event
or
a
log
event.
B
D
B
But
yeah
all
this
is
based
on
document
load.
I
did
see
like
a
timeout
in
here
as
well,
so
it's
waiting
so
I
I
think
we
can
probably
do
better
than
that
in
terms
of
because,
like
if
you've
got
a
client-side
navigation,
a
client-side
redirect
so
effectively
you've
got
a
script
tag
sitting
in
the
head
that
forces
the
redirection
before
the
document's
actually
completely
loaded
I
think
you'd
lose
events.
C
A
A
A
A
A
You
know
these
are
repeated
like,
for
example,
the
net
dot.
You
know
these
two,
the
net
namespaced
attributes.
You
know
I
I.
Originally
you
know
I
I
I
thought
that
you
know
each
attribute
is
specified
only
once,
but
that's
not
true.
Like
you
know
here,
you
know
we
are
not
introducing
the
net
dot
transport.
As
an
attribute,
we
are
just
saying
that
the
radius
span
span
for
the
redis
call
includes
the
net
dot
transport
yeah.
A
Correct
so
so
that
is
what
we
need
to
do
that
like
list,
one
page
called
maybe
browser
events,
and
then
you
know
list
all
the
events
you
know
in
this
form
yeah
right
and
this
doesn't
have
to
be
in
the
spec
repo.
There
is
a
chance
that
the
spec
folks
might,
you
know,
object
yeah,
and
you
know
this
is
the
same.
Yaml
files,
you
know,
could
reside
in
the
JS
report
and
the
build
tools.
You
know
we
could
still
use
the
build
tools
to
generate
this
MD
yeah.