►
From YouTube: 2022-07-19 meeting
Description
Instrumentation: Messaging
A
A
Correct
correct,
yeah
yeah.
I
have
something
to
discuss.
Maybe
I
can
pick
your
brain
so
in
javascript
it's
it's!
It
is
in
the
browser
world.
It's
all
single
threaded
right,
yep,.
A
Yeah,
unless
you
use
the
rem
process
yeah
now,
let's
say
you
initiate
an
api
call,
an
ajax
call,
and
then
there
will
be.
You
know
so
many
events,
you
know
which
are
set
up.
A
A
You
don't
typically
know
that
those
events
that
get
called
back
and
those
callbacks
are
related
to
that
yep
and
I
mean
correct
and
therefore
you
know
those
events
and
the
logs
created
by
you
know
in
those
event
handlers
they
may
be
associated
with
the
place
context,
but
they
don't
have
to
in
fact
it's
more
appropriate
to
not
associate
the
trace
context
of
that
ongoing
api
call
with
the
events
and
logs.
A
B
Yeah,
which
is
why,
in
a
bunch
of
my
earlier
comments,
I
was
talking
about
having
linking
the
span
as
optional,
because,
depending
on
the
application,
it
either
will
be
associated
with
it.
B
You
know,
you'll
have
a
series
of
things
that
are
grouped
associated
with
a
span,
but
you
won't,
and
it's
entirely
in
the
realm
of
the
application
to
determine
whether
it
is
or
it
isn't,
which
is
one
of
my
problems
with
the
the
global
context,
with
the
the
existing
implementation,
like
instrumentations,
just
throw
everything
into
and
set
the
active
context
to
identify
the
span
id.
But
that's
not
always
going
to
be
the
case,
especially
in
the
case
of
async
calls
like
ajax
requests.
A
Okay,
so
in
in
my
the
api
specification
for
the
events
and
logs,
I
added
a
flag
whether
to
record
the
trace
context
from
the
events
by
default
or
not
and
and
and
the
default
I
set.
This
is
false
because
it's
more
likely
that
you
know
that
the
events
and
the
logs
created
are
unrelated
to
the
api
calling
progress
and
therefore
the
users
have
to
be
really
sure
and
they're.
You
know
they
have
to
explicitly
get
another
logger.
A
B
A
B
I
I
think
with
the
if
I
understand
the
the
discussion
with
the
event
emitter.
So
in
fact
you
ask
the
logs
api
for
an
event
emitter,
and
then
you
start
putting
events
on
that.
So
my
thinking
would
be
either
you
have
the
the
span
id
associated
with
that
context,
which
is
I
guess,
where
you're
setting
your
flag
or
you
don't.
B
The
downside
is
yeah.
If
you've
got
a
series
of
different
things,
then
you're
gonna
have
to
create
us,
get
a
series
of
event
images.
It's
either
that
or
we
have
an
option
on
the
you
know
emit
event
where
you
can
give
it
the
the
span
id
or
we
have
some
other
way
of
setting
the
span
id.
But
I
think
it's
all
internals
with
the
logs
api,
isn't
it.
A
Yeah,
I
think
that
was
the
comment
from
josh
too,
that
you
know
shouldn't
this,
be
the
concern
of
the
sdk,
why
you
know
expose
it
at
the
api
layer,
but
the
problem
is:
how
will
sdk
make
decisions
yeah
exactly.
B
A
Intent
yeah
now
I
I
want
to
understand
a
little
bit
about
the
zone
concept
in
in
javascript
in
world.
I
believe
that
allows
you
to
follow
the
trail
of
a
certain
thread
right.
You
know,
you
know.
B
Stuff!
Sorry
right!
Okay,
I'm
probably
not
the
best
person
to
ask
you!
I
I
can
guess,
and
we
can
we
can
surmise
by
having
a
discussion
but
yeah,
I'm
not
authoritative
on
that
at
all,
like
I've
brought
over
the
code,
but
I
haven't
dug
into
the
details
of
the
code
yet
which
is
frustrating
I
had
planned
on
having
the
sandbox
up
and
running
weeks
ago,.
A
Okay,
maybe
I'll
join
the
jsc
tomorrow
to
talk
more
about
this.
B
Yeah
because
daniel
who's,
the
the
well,
is
he
here
tomorrow.
I
think
it's
the
27th
he's
not
here.
Yeah
he's
been
the
maintainer
for
at
least
as
long
as
I've
been
attending
the
meetings
for
the
last
almost
two
years.
B
There
are
a
few
more
maintainers
which
also
probably
have
context
on
that
as
well,
because
I've
been
sitting
in
the
background
for
a
while,
so
yeah
we
can
get
those
questions
answered
there
tomorrow.
Okay,.
A
Okay,
yeah.
I
just
wanted
some
feedback
on
on
this
flag
that
I
added
in
the
api,
at
least
in
the
android
world.
I
know
for
sure
that
you
know
when
there
are
multiple
threads.
You
know
you
you,
you
set
up
an
event
handler
and
the
callback
is
called
in
the
same
thread.
A
B
B
But
probably
the
way
I
handle
this
in
our
internal
sdks
is
effectively
like
I
sort
of
already
mentioned.
I
effectively
get
the
object
and
I
pass
that
object
around
to
the
individual
event
handlers
so
that
they
they
track
their
instance
that
they're
playing
with
rather
than
like,
I
don't.
I
don't
use
global
scopes
at
all
in
any
of
the
application,
insights
or
internal
version
specifically
to
avoid
that
problem.
So.
B
A
A
Switching
topics
there
are
a
couple
other
tracks.
I
think
that
are
going
slow.
I
guess
one
is
that
ephemeral
attributes
and
your
second
is
the
custom
attributes.
B
Yeah
I
got
comments
last
week
that
which
I
haven't
responded
to
yet
amir
keeps
wanting
to
explicitly
state
in
line
that
it
applies
only
to
logs
when
I
prefer
to
have
a
log
table,
so
I'm
still
considering
those
it's
part
of.
Also
I've
got
to
find
time
to
get
back
to
that
particular
pr
as
well.
A
Okay,
I'm
I'm
wondering
if
that
should
be
no
tip
instead
of
you
know
pr,
because
actually
we
need
the
necessary
attributes
not
just
in
logs,
but
also
in
spans.
A
B
I
originally
I
had
it
there
as
being
my
wording
was
optional
based
on
this
and
amir
really
shut
that
down
pretty
quick.
I
spoke
to
tigran
not
last
week
before,
maybe
and
yeah.
He
decided
to
keep
it
simple
and
then
bite
it
off
in
smaller
chunks.
So
this
pr
is
really
about
trying
to
define
what
the
state
is.
Now
there
is
a
separate
discussion
going
on
which
I
think
is
324,
which
I
I've
linked
in
my
pr
at
the
top,
which
is
now
crossed
out
about
how
to
go
about
extending
it.
B
I
have
talked
to
a
lot
of
people
who
have
said
yes,
they're
fully
supportive
of
extending
it,
but
it
keeps
getting
shut
down.
So
I
don't
think
that's
going
to
be
an
easy
push
to
change
the
spec,
even
though
the
protobuf
supports
it,
because
bands
explicitly
don't
list
it,
and
apparently
there
was
big
discussions
on
it
previously.
There
it
keeps
getting
now
it's
landed
stable.
You
can't
change
it.
It's
like.
A
Okay,
okay,
but
for
the
logs
itself
the
spec
already
allows
furnace
with
attributes
right
now.
Is
it
only
a
matter
of
the
sdks
implementing
it.
B
Yeah
so
so,
when
the
sdks
come
to
implement
their
log
implementations
they're
going
to
run
into
this
issue,
especially
in
javascript,
where
attributes
are
currently
defined
as
not
supporting
nested
attributes
but
they're.
Just
attributes
so
they're
going
to
have
to
implement
either
another
type,
which
is
log
attributes.
A
That
is
why
yeah
exactly,
I
think
the
code
will
get
cluttered
for
for
especially
no
reason,
because
eventually
we'll
need
it
for
spans
as
well.
So
I
think
instead
of
the
current
direction,
I
prefer
that
we
get
this
spec
change
for
spans
to
support
nested
attributes.
Then
the
the
sdk
changes
become
simpler.
A
And
for
that
I
think
it's
better
to
create
a
no
tip,
providing
more
examples,
why
yeah,
yeah
and
compared
with
prs.
I
think
you
know
you
can
actually
provide
more
detailed
explanation.
A
A
Yeah,
I
think
there
are
use
cases
like,
for
example,
for
spams.
I
can
think
of
two
use
cases
where
nested
attributes
is
very
helpful.
You
know
one
is,
I
think,
yuri
from
his
name
is
correct.
I
think
he
pointed
out
that
http
headers,
if
somebody
wants
to
associate
in
a
spam
either
the
request.
Headers
are
the
response.
Headers,
you
know
they
are.
They
are
better
represented
as
a
as
one.
A
Yeah
and
second-
and
the
second
is
our
use
case-
where,
for
the
performance
timing
parameters
today
for
a
lack
of
national
attribute
support,
we
are
keeping
them
as
separate
events
and
events
yeah
right,
which
is
really
a
hack,
an
ugly
hat
because
of
a
lack
of
better
data
structure,
yeah
some
things
that
are,
I
think
it
is
better.
A
They
are
better
represented
using
again
key
value
pairs.
They
themselves
are
the
performance
timing,
attributes.
You
know
they
are
not
separate
events.
A
So
so
that
would
be
a
second
use
case,
so
there
are
use
cases
where
mr
adversary
is
helpful
in
spans.
Now
I
believe
the
concern
really
is
there
could
be
two
concerns.
You
know,
one
is:
are
there
any
downsides
or
will
it
be
abused?
You
know
that's
a
more
generic.
You
know
downside,
but
a
specific
one.
A
Another
one
could
be
that
we
need
to
define
a
mapping
of
these
nested
attributes
to
you
know
to
flat
attributes
when
exported
to
other
assistance.
Now
that
again,
I
am
I'm
curious
like.
Why?
Should
we
be
limited
by
legacy
systems?
Are
they
are
those
being
actively
support,
developed
and
supported?
You
know
shouldn't
they
shouldn't
those
systems
themselves
be
evolved
to
match
the
growing
features
of
open,
telemetry.
B
Yeah,
it's
more
a
case
of
I.
I
think
the
reason
nested
attributes
were
excluded
from
spans
is
because
of
the
the
server
server-side
focus
and
the
back-end
support
for
prometheus
and
jaeger.
I
think
it
is
because
they
don't
support
storing
the
data
in
a
nested
way.
It
has
to
be
flat.
B
But
yeah
it's
like
the
protocol
transport
was
defined
effectively
on
the
lowest
common
denominator
based
on
these
okay
long-standing
systems,
but
that
shouldn't
drive
how
the
application
works.
It's
a
case
of
that
the
point
of
exporting
or
the
point
of
ingestion
they
can
flatten
it
out
using
some
sort
of
what
do.
I
call
that
in
the
spec
I
I
defined
it
as
a
some
form
of
strategy.
That
was
the
word
I
used
and
even
in
the
the
specs,
where
it
talks
about
attributes
where
they
suggest
about
nested
attributes
and
they
saying
well.
B
If
it's
not
one
of
these
primitive
types,
then
it
should
be
adjacent,
which
is
fine,
if
that's
what
the
vacuum
wants
to
do,
but
that
shouldn't
limit
the
protocol
so
yeah
it's
it's
all
a
bit,
frustrating
that.
A
Yeah,
I
know
I
think
I
I
think
we
should
create
a
note.
B
B
Mine
was
to
change
the
spec
repo
yeah,
okay,
oh
there.
It
is.
B
Yeah
so
yeah,
so
before
I
created
the,
why
didn't.
B
B
Okay,
I'm
gonna
click
on
that
refractive.
It
is
a
spec
issue.
The
eight
is
what
is
a
pull
request,
oh,
which
actually
got
merged?
Okay,
that
was
tigran's
to
effectively
add
array,
support
and
then
so
three.
B
So
I
tried
to
incorporate
some
of
this
into
my
original
pr
and
that's
where
I
got
shut
down.
So
I've
had
to
back
off
a
little
bit
from
that.
B
B
Well,
if
you
want
to
start
drafting
it
and
then
we
we
can
talk
about
it
in
the
in
these
meetings,
so
I'm
really
heavily
concentrated
on
the
sandbox
and
it's
already
chewing
up
more
time
than
what
I
had
actually
had
allocated
to
open
telemetry.
It's
like
I've
got
other
stuff
that
I've
really
let.
A
Me
yeah,
if
you
could
send
me
the
list
of
issues
and
peers
from
the
past,
that
I
should
go
through
I'll
I'll,
go
through
and
understand,
and
then
we
can.
You
know
I'll
write
something
up
based
on
that
yeah.
B
B
So
what
do
we
call
this
thing,
we'll
call
this
I'll
put
it
in
the
notes.
Oh
yeah.
Sorry,
sorry,
discussion
on
nested
attributes.
B
Oh
yeah,
yes,
I've
just
sort
of
added
into
that
yeah,
it's
just
useful
for
having
it
defined
so
yeah,
so
the
the
second
two
of
the
I
just
linked
off
my
my
two
but
yeah:
it's
really
the
376,
which
is
now
the
last
one
of
that
is
where
most
of
the
discussion
has
been
happening.
A
B
Yeah
so
tigger
had
that
so
in
the
spec
meeting
that
was
immediate
before
this
meeting
he
bought
that
up
and
he
is
actually
going
to
close
that
and
with
for
the
reasons
I've
defined.
B
So
as
part
of
the
discussions
that
happened
in
there,
he
saw
two
paths
forward
and
that
was
effectively
using
just
the
binary
protobuf
and
then
someone
identified
the
experimental
compression
streams
so
he's
just
going
to
close
it
and
daniel
piped
in
and
said
from
his
perspective
with
all
the
people
he's
talking
to
the
protobuf
binary
exporter
is
the
more
common
one,
but
I
think
that's
probably
partially.
A
Even
even
in
the
browser
world
nev,
I
think
that
might
be
true
in
the
back
end.
B
Yeah
yeah:
that's
why
I
thought
too,
but
he
said
even
in
the
browser,
but
I
think
it's
probably
more
because
the
json
isn't
defined.
It's
not
standard.
The
compression
streams
might
help,
but
it's
only
supported
in
oprah
and
chromium.
B
A
Yeah
that
will
eventually
get
supported
in
all
browsers.
Let's
say
five
years
from
now.
You
know
we
can
hope
to
have
more
coverage,
more
support
yeah,
so
that
I
think,
is
certainly
a
promising
thing.
B
Yeah,
I'm
willing
to
do
some
some
measurements
like
looking
at
the
decompression,
the
decompression
is
asynchronous.
B
I
couldn't
find
a
specific
link
whether
the
compression
side
is
asynchronous
or
synchronous,
because
that
really
will
affect
that
that
on
unload
request,
because
if
we,
if
we
need
to
say
if
we're
getting
a
page
unload
and
we
need
to
do
a
send
beacon
to
get
a
schedule
to
go
off
the
box
now,
it
can't
be
an
asynchronous
request
because
it'll
get
dropped
or
we
just
fall
back
to
non-compressed
for
those
ones,
which
still
then
leaves
us
with
the
64k
limit.
B
A
Quickly,
yeah,
but
I
think
the
the
fundamental
point
was
that
going
to
the
temporal
attributes
quote
from
ted,
we
originally
wanted
the
resources
themselves
to
be
modifiable.
B
Yeah,
the
compression
doesn't
really
change
that,
like
the
rationale
for
just
having
the
field
once
is
still
relevant,
because
if
you've
got
less
data
to
compress
it's
still
going
to
be
faster,
so
I
just
don't
have
any
numbers
on
how
fast
this
api
is
today.
B
A
But
short,
sharp
keys
might
might
still
be
a
good
idea
right
because
it's
widely
used-
and
you
followed
why.
B
B
Personally,
I
would
prefer
just
use
the
binary
values
rather
than
the
short
keys,
because
the
binary
values
like
the
numeric
value
of
the
field
is
already
a
short
key.
It's
just
a
number
and
in
most
cases
it's
a
single
digit
number
anyway.
So
it's
going
to
be
shorter
than
a
string,
so
I
I
think,
that's
probably
the
better
option.
B
Yeah.
Unless
we
get
to
defining
you
know
hundreds
of
fields
and
I've
lost
my
train.
I
thought
yeah.
So
it's
a
double
look
up
so
effectively.
You've
got
already
got
some
back
ends
that
are
supporting
the
long
json
names.
If
we
start
supporting
short
json
names,
they've
got
to
have
both
and
as
daniel
brought
up
in
the
spec
meeting.
B
B
But
the
number
of
times
that
those
long
keys
were
actually
used
was
minimal
and
in
some
cases,
like
only
one
instance,
so
having
my
big
lookup
table
of
long
key
to
number,
because
I
I
was
mapping
everything
to
a
a
constant
enum.
So
it
was
just
a
number
actually
blew
out
the
code
quite
significantly,
because
the
only
time
you
get
savings
for
lookups
is
when
they're
used
more
than
once,
because
you're
trying
to
use
them
once
for
a
long
key
you've.
B
Just
added
all
this
extra,
you
know
equals
value
comma
to
the
to
your
code,
and
then
I
found
some
old
dead
config
which,
depending
on
which
portion
of
the
code
you
dragged
in,
I
end
up
having
these
huge
lookup
tables,
where
a
particular
plugin
was
only
using
three
of
them,
but
it
now
had
like
2k
worth
of
lookup
table
that
got
dragged
in.
So
it's
it's
problematic.
It's
probably
the
simplest
way,
so
I've
actually
completely
reversed
my
approach,
and
now
I
don't
have
lookup
tables
at
all.
I
have
dynamic
conversions,
which.
A
B
Okay,
so,
which
then
directly
impacts
the
you
know
the
the
plt,
because
it's
an
extra
payload
size
and
then,
if
you
break
it
up
into
smaller
chunks,
anything
that
references
that
table
or
includes
that
table
into
its
own
bundle
you.
It
actually
pays
the
penalty
more
than
once.
A
Yeah,
but
that
is
an
open
area
right
I
mean
that
download
size
is
still
a
work
in
progress.
We
don't
know,
that's
the
sandbox.
B
That's
the
the
techniques
I
want
to
do
on
the
sandbox,
but
the
simple
approach
is
because
the
lookup
table
effectively
becomes
a
namespace
field.
You
know,
minifiers
can't
compress
the
the
values
and
tree
shaking
can't
occur
because
anything
referenced
by
that
namespace
by
the
lookup
table.
Everything
has
to
be
included
whether
it's
used
or
not.
B
So
the
approach
I
took
was,
I
effectively
don't
have
lookup
tables.
I
have
constant
strings
that
I
have
a
preprocessor
now
that
goes
over
the
code
and
says:
if
you
find
this
constant
string,
you
can
replace
it.
If
you
find
this
fixed
string,
you
can
replace
it
with
this
constant
lookup,
which
then
makes
it
subject
to
minification
and
tree
checking.
B
So
actually
I
saved
quite
a
bit
of
space
in
the
process
of
that.
A
Right
so
so
given,
given
you
know
those
possibilities,
I
have
a
feeling
that
it
might
be
worth
spending
those
two
kilobytes
for
the
purpose
of
a
runtime
benefit.
A
network
benefit.
A
Think
of
it
this
way,
I
think
today,
a
lot
of
these
things
are
options.
They
are
part
of
the
sdk,
but
what
in
each
individual
vendor
chooses
to
package
is
entirely
you
know
left
to
them
right,
so
this
could
be
just
one
more.
A
A
platform
feature
an
sdk
in
a
feature
that
you
know
the
individual
vendors
could
choose
to
include
yeah
and
in
fact,
and
and
not
just
that,
I'm
also
thinking
that
you
know
there
is
a
possibility
for
a
more
smarter
download
mechanism
where
you
know
there
are.
There
are
several
parameters
like
you
know,
grpc
versus
http
is
one
of
them.
A
Where
you
know,
and
you
know,
we
could
first
download
a
smaller
agent,
smaller
javascript
file,
which
could
come
down,
evaluate
the
situation
and
then
further
download
a
more
appropriate
bundle,
more
appropriate
javascript
file,
yeah,
that
would,
you
know
more
suitable,
so
it's
not
just
vendor
specific,
so
each
vendor,
you
know
themselves,
could
have.
B
B
A
A
A
I
think
yeah,
so
I
think
I
think
it
might
be
worth
keeping
that
support
of
short
keys
via
the
the
prototype
of
field
numbering
because
I
think
it
is
also
in
line
with
how
the
put
up
encoding
itself
works.
B
Yeah
yeah
and
if
you
use
the
the
field
numbering
effectively
that
that's
underlying
value
for
the
for
the
binary
format,
so
yeah
that's
never
going
to
get
broken.
So
the
the
issue
is
going
to
be
effectively
all
the
back
ends
need
to
support
that.
So
I
think,
there's
still
an
open
question
on
the
json
stability,
in
terms
of
how
our
represented
either
represented
by
their
numeric
value
or
their
full
value,
or
both.
B
Yeah
yeah
so
that
one's
still
an
open
issue
from
the
spec
meeting
this
morning,
which
is
holding
up
the
adjacent
thing.
A
B
Okay
but
yeah,
but
based
up
based
on
the
the
spec
meaning
I
the
the
short
keys,
is
dead.
Will
the
json
format
support
the
numeric
value
or
not?
I
I
don't
know
I
haven't
looked
into
the
into
the
detail
of
that.
It
would
be
nice
if
it
did,
because
then
you
effectively
get
automatic
short
keys
just
by
having
the
numeric
value
rather
than
the
name.
B
Yeah
but
I
think
they're
using
gogo
proto
to
do
the
conversion
and
it's
quite
old,
so
it
probably
doesn't
currently
support
numeric
values.
B
A
The
the
numeric
fields
as
the
keys,
what
kind
of
a
compatibility
support
it
would
require
like,
for
example,
would
it
require
a
new
content
type
to
be
established?
No.
A
B
Just
be
as
part
of
the
encoding
decoding
of
json
as
long
as
it
can
use
the
the
numeric
value
of
the
field
or
the
name,
that's
it
and
depending
on
the
type
of
objects.
B
Compressed
sorry
being
encoded,
whether
that
would
work
or
not
so
if
you're
in
an
array
then
effectively,
the
numeric
value
has
implications
on
the
actual
index
that
you're
playing
with,
but
I
think
for
arrays,
it's
actually
an
array
of
objects,
so
you
can
have
the
numeric
value
as
the
key.
Quite
happily
in
javascript.
B
So
like
when
you
get
down
into
any
value
where
you've
got
like
the
interval
field
instead
of
being
iv,
that
can
just
be
whatever
the
numeric
value
is,
and
at
least
from
a
javascript
perspective
that
can
do
that.
But
it's
going
to
come
down
to
the
encoder
into
the
base,
an
encoder
decoder
on
collector.
It's
probably
the
decoding
aspect
of
it.
So
as
long
as
the
decoding
would
support
it,
there's
no
reason
you
can't
send
it,
and
that
depends
on
what
they've
got.
A
But
would
it
require
a
new
content
type,
no.
B
No,
no,
no!
It's
just
as
long
as
because
it's
just
it's
just
the
key
of
the
object
defining
what
it
is,
so,
whether
you
know
at
the
moment,
they're
strings
for
the
json
encoding,
but
if
the
decoder
also
supports
its
protobuff
numeric
value,
because
internally
the
decoder
is
going
to
say
we'll
get
this
string
and
convert
it
back
to
this.
B
You
know
it's
got
the
lookup
table
anyway.
It
would
work.
A
B
B
B
But
yeah,
I
don't
go
to
the
meeting,
so
I
I'm
not.
I
only
pick
up
the
the
issues
with
collector
from
the
maintainers
meeting
in
the
spectrum
that
I
go
to
because
most
of
the
people
in
there
come
to
those.
So
I
guess
tigran
is
one
of
the
main
collector
leads.
So
in
the
logs
mean
tomorrow
we
can
always
ask
him
in
terms
of.
Does
the
existing
json
decoder
or
the
generated
code
support
the
numeric
value
for
that?
Or
is
it
only
ever
the
name?
A
A
A
B
Yeah,
so
I
wasn't
expecting
anyone
to
appear
so
I
just
was
putting
these
in
as
a
just
an
fyi,
but
nothing
good
having
a
discussion.
Yep.
A
A
No,
I
think
we
can
make
tomorrow.