►
From YouTube: 2023-03-07 meeting
Description
Instrumentation: Messaging
A
B
A
Right
sorry,
I,
I
didn't
follow.
I
can
hear
you,
okay,.
A
A
There's
still
some
you
know
cough,
but
yeah,
I'm,
okay,
mostly
okay,
yeah.
A
I
had
a
couple
questions.
Let
me
share
my
screen.
A
So
I
raised
a
couple
PR's.
The
second
one
on
the
browser
events
is,
is
one
that
you
know
needs
further
fine
tuning.
Please
take
a
look
at
this
PR
it.
It
certainly
is
going
to
raise
questions
from
the
community,
mostly
because
I
think
this
is
now
talking
about
attributes
inside
a
top
level
attribute
inside
the
event.data
right
and
so
far.
You
know
we
did
not
have
them
in
the
semantic
convention,
so
this
might
be
new.
A
But
let's
see
what
people
have
to
say,
we
we
are
keeping
it
just
for
a
reference
for
a
future
reference,
but
that
said,
you
know
the
specific
questions
I
have
are
I.
Have
some
of
these
will
be
implemented
as
span?
Let's
take
http
now
each
of
these
are
they
will
be
top
level
attributes
in
the
span.
A
They'll
not
be
like,
although
I
have
used
the
short
form,
I
have
removed
the
prefix
I
I
need
to
I.
I
didn't
realize
at
the
time
that
that
prefix,
where
I
removed
only
for
the
attributes
that
are
you
know
in
the
event.data,
but
for
span
attributes.
We
need
to
keep
them
the
original
original
form.
A
So
any
comments,
thoughts
on
how
to
structure
this,
like
you
know
like
this
whole
document,
I,
can
just
say
that
these
are
the.
This
is
the
data
model
of
the
Telemetry
emitted
by
browser
instrumentation,
and
some
of
them
could
be
even
some
of
them
could
come
as
spans,
but
in
either
case
you
know
this
is
the
itata
model.
B
In
in
terms
of
like
the
HTTP,
if
it's
just
a
span,
I
would
completely
leave
it
out
of
this
document.
It's
just
going
to
confuse
the
crap
out
of
everyone.
This
should
just
be
talking
about
events
themselves,
yeah.
We
can
make
a
reference
and
say
some
of
these
will
have
span
links
or
you
know,
or
linked
with
the
associated
span,
so
in
the
the
specs
this
morning,
tigrant
injected
or
a
presentation
on
effectively
getting
the
stability
of
the
logs
API,
and
they
did
mention
some
of
this.
B
In
terms
of
the
example
they
gave
was
or
the
demo
they
gave
had
a
log
record
which
had
you
know,
the
span
associated
with
it,
which
I
think
is
as
much
as
we'd
be
inheriting
the
same
thing
so
yeah
I
can
completely
dropping
anything
that
is
just
a
span
out
of
this
I
think
is
the
the
better
way
to
go.
B
B
Tigrin
and
the
the
TC
said
they
were
going
to
review
this
and
see
what
what
happens
from
that.
But
that
also
is
slightly
impacting
the
HTTP
stability
stuff.
So
I
had
a
quick
look
at
how
ECS
represents
client-side
events.
They
have
events,
but
they
to
me
they
all
look
like
server-side
events,
so
they're
not
representing
what
we're
representing
here,
but
I've
only
started
looking
at.
So
if
anyone
else
has
references,
I'd
be
Keen
to
do.
C
B
No
sorry
I've
only
just
started
looking
at
it
in
here
they
make
lots
of
references
to
events,
but
as
far
as
I
can
tell,
the
events
are
like
the
communities
like
for
back-end
stuff,
so
I
need
to
digest
it.
I
went
off
and
looked
at
the
in
here.
There
is
a
link
to
the
ACs
event
and
they
talk
about
event
fields
but
again,
the
event
fields
of
the
event,
type
that
they've
defined
or
none
of
what
we
would
have.
B
B
Well,
that's
why
Tiguan
has
that
the
issue
blocked
the
the
TC
is
going
to
talk
about
it.
A
Well,
the
elastic
common
schema
I
I,
wonder
how
common
it
is
outside
of
the
community
built
by
elastic.
A
I
I
don't
know
if
we
should
ticket
so
seriously.
At
this
point,
like
I
think
we
should
continue
doing
what
we
are,
because
we
are
already
like
super
late.
B
Yeah
I
I
think
we
should
keep
moving
on
I
I,
just
Brazen
up,
saying
yeah,
it's
probably
going
to
impact
some
of
our
discussions
and
may
slow
things
down
because
they
might
go.
Oh
hang
on.
Let's
just
look
at
this
other
stuff.
At
the
same
time,
so
I
think
we
can
keep
going
because
one
of
the
calls
I
get
for
the
event.data,
which
includes
Jack
had
a.
B
When
did
that
come
up
with
a
log
signal.
Let
me
go
find
there
was
in
the
log
Sig
last
week,
yeah,
actually
maybe
in
the
specsig
he
raised
maintained
this
I,
don't
remember
which
one
now
he's
got
another
issue
open
or
actually
a
discussion
open
about
discussing
when
events
should
be
used.
Yeah
yeah
I
saw.
A
That
yeah
yeah-
and
you
know
from
from
that
it
was
it-
was
an
issue.
I
looked
at
it
yesterday
and
from
that
it
was
clear
that
you
know
there
are
not
many
strong
use
cases
right
outside
of
you.
A
He
actually
has
listed
several
possibilities
here,
several
use
cases,
but
the
fact
that
they
aren't
in
demand
yet
implies
that
you
know
they
they're
not
going
to
make
a
dent
in.
B
In
the
decision
making
yeah
so
so
we
talked
about
this
in
the
log
Sig
last
week
and
I'm
supposed
to
make
a
comment
on
this.
I
just
haven't
had
the
time
to
get
to
make
a
comment.
I
agree
with
most
of
it,
there
was
a
couple
of
minor
things
that
we
talked
about
in
the
logs.
That
I
think
are
a
little
bit
different.
A
Yeah,
although
I'm
now
wondering
like
what
our
next
steps
are,
are
like
I
think
in
terms
of
prototyping,
you
know,
I
I
was
going
to
have
somebody
from
a
team
to
introduce
the
log
attributes
and,
and
then
you
know,
build
one
of
these
instrumentations
using
the
log
API,
because
you
know
I'll.
Let
Martin
continue
working
on
the
events.
Api,
let
the
events
API
evolve,
but
we
can
build
these
instrumentations
using
the
the
log
API
yep
for
now,
just
for
the
prototyping.
B
D
A
Know
overall
risks
we
see
I
I,
don't
know
where
each
of
you
are
with
respect
to
your
like
journey
into
this,
like
how
much
you
want
to
wait
for
things
to
be.
B
I
I
think
for
it
to
become
acceptable
to
them.
We
need
to
have
the
prototypes,
so
I
I
think
with
the
logging
API
being
checked
in
and
the
SDK
being
worked
on
and
us
moving
forward
with
creating
prototypes
for
this,
like
if
someone
from
your
company
can
do
that,
that
would
would
help
a
lot.
B
I
think
I
I
pasted
in
the
presentation
that
which
effectively
is
like
a
PowerPoint
type
thing
that
tigrin
gave
this
morning
and
it
defines
in
there
the
the
logging
API
and
what
they
plan
to
make
stable.
So
I
think
as
a
second
or
third
slide
was
the.
B
B
So
this
this
is
the
the
presentation
that,
though,
that
they'll
be
talking
about
the
log
Sig
to
say:
let's
mark
the
logs
API,
SDK
staple
or
the
whole
logging
things
table.
A
Yeah
but
the
the
the
controversy
around
the
ram
events
is
that
yeah,
you
know
the
Prototype
could
show
us.
You
know
one
way,
but
it
cannot
prove
that
there
are
no
other
ways
or
it's.
It's
objective
right.
B
A
Okay,
is
there
a
way
we
can
at
some
point
if
needed,
you
know
say
that
this
is
the
way
you
know
the
the
JavaScript,
not
entire
JavaScript,
but
at
least
the
ramside
television
will
go
with
and.
B
B
It's
then
just
using
the
logging
API
under
the
covers,
and
we
have
our
path
forward
and
so
yeah.
That
is
one
possibility
and
we
separate
ourselves
a
little
bit
from
the
whole
General
event.
Definition:
okay,.
A
B
Yeah
anything
that
that
would
that
you're
saying
is
this
is
just
a
span,
I
think
take
it.
Take
it
out
of
this,
but
you
can
leave
references
in
there
saying
events
can
be
linked
with
any
spans
as
supported
by
the
logging
API.
So
for
the
HTTP
request
timing,
there
will
probably
be
a
HTTP
span
that
that's
active,
so
this
will
be
linked
to
that
for
exceptions
depending
on
what's
happening,
there
may
be
a
a
span.
You
know
stuff
like
that.
Yeah.
A
But
in
terms
of
I
think
that
will
be
that
that
has
a
possibility
of
coming
in
in
a
span
event,
I'll
I'll
mention
her
comment
thing.
You
know
this
will
be
linked
with
the
corresponding
span.
B
Yeah,
depending
on
the
type
of
exception
yeah,
it
was
raised
this
morning
too,
with
the
easiest
thing,
the
exception
definition
could
change
again
as
well.
So
Trask
mentioned
that
so
it's
explicitly
excluded
from
his
http
definition.
B
B
A
And
with
respect
to
prototyping
I'll
sync
up
with
Martin
too
but
is,
is
there
any
plan
or
like?
Are
you
like
I'll
I'll?
Maybe
you
know
include
one
other
engineer
from
our
team
on
to
those
conversations
but
I,
you
know
one
quick
question
I
had
is:
is
there
anything
that
we
want
to
do
fundamentally
different?
Now
that
you
know
we
are
redoing
the
instrumentations
compared
to
you
know
what
we
have
like?
B
There's
probably
going
to
speak
to
my
update
on
the
sandbox
so
last
week,
I
merged
the
merge,
repos
or
Json
contrib
all
the
way
up
to
be
current,
but
when
I
try
to
merge
that
into
main
to
bring
those
together,
there
was
a
breaking
change
that
was
made
in
the
JS
repo
around
the
usage
of
aversioned
resources
that
effectively
broke.
My
scripts
I've
been
working
to
try
and
get
that
fixed
I
had
I
now
have
it
mostly
compiling
locally
effectively.
B
Typescript
doesn't
like
having
the
named
version
for
a
different,
so
I
think
because
I'm
renaming
the
packages
to
have
a
Sandbox
Dash
on
the
front
and
I'm
using
the
latest
version
of
typescript,
it
Buffs
when
it
tries
to
say
I,
have
a
resource
called
sorry.
A
package
called
resource
underscore
1.9.0,
which
doesn't
clash
with
the
main
name.
So
I've
I've
been
working
around
that
to
try
and
get
it
going.
B
B
Once
we
give
that
Branch
mostly
working,
then
it
would
be
really
really
nice
to
do
this
stuff
off
in
the
sandbox,
because
we
can
spin
a
lot
faster.
But
at
this
point
right
now
today,
last
week
it's
still
a
case.
We
have
to
do
this,
as
in
the
experimental
folders
in
Json
contract.
A
B
I
I
see
it
as
multiple,
so
in
terms
of
branching,
there
will
be
one
branch
which
will
I
tend
to
focus
just
on
minification
to
try
and
make
it
smaller.
B
We
have
a
you
know
another
Branch
to
do
like
this.
Experimentation
of
you
know,
creating
apis
and
and
making
them
work
across
a
Json
concrete,
because
everything
gets
comes
together.
It
was
more
relevant
when
API
was
separate
because
it
was
going
to
emerge,
API,
JS
and
and
contrib,
but
Now
API
is
back
in
Js.
You
can
sort
of
do
some
more
stuff
in
the
JS
contrib
than
you
could
before,
but
yeah.
B
While
my
focus
was
on
minification
and
and
trying
to
enter
that
that
question,
because
it's
just
merged
apis,
I'm
I
want
to
open
it
up
and
say:
if
you
want
to
do
something
experimental,
we
can
create
your
branch.
You
can
own
that
Branch!
You
can
do
with
what
you
like.
So
you
can
work
with
multiple
people
instead
of
in
your
own
fault
or
Forks
of
the
two.
So
it's
going
to
be
more
relevant
for
anything
that
that
cuts
across
both
what
is
currently
in
contributing
Js.
B
If
it
is
just
in
Js,
you
can
use
the
experimental
folders
that
there,
if
it's
just
in
contrib,
you
can
use
the
experimental
folder
so
they.
But
if
you
want
to
make
changes
to
both
the
sandbox
makes
sense.
B
Yep
that's
owned
by
open
Telemetry,
rather
than
you
know,
having
everyone
having
their
own
fork
and
having
to
share
their
own
forecast.
We
can
just
say
you
know
it's
it's
owned
by
open
Telemetry.
It
is
a
an
experimental
sandbox
to
do
with
what
you
want.
If
you
want
to
create
a
if
you're
on
a
gun
create
an
experiment,
we
can
create
your
branch
and
you
can
go
and
do
what
you
like
in
that
branch,
because
we're
not
going
to
be
publishing
anything
at
this
point
from
from
here.
A
But
at
what
point
do
you
think
we'll
be
able
to
have
a
conclusion
and
say
you
know
one
of
the
approaches,
I
think
I
think
yeah
the
plan
for
that
is
not
clear
to
me.
B
And
the
plan
for
that's
based
on
time
so
which
makes
it
hard
to
answer
at
what
point
so
effectively
the
minification
is
the
first
step,
it's
a
case
of
saying.
Well,
how
far
can
we
get
in
the
bottle
size?
So
the
sandbox
generates
effective
package
bundles
for
for
every
component,
as
it
goes,
it
was
part
of
just
bringing
it
over
so
I.
We
can
already
see
that
in
the
individual
pieces
in
terms
of
how
big
they
are
as
part
of
minification,
we
can
then
say
well.
B
A
Yeah,
in
fact,
I
I,
you
know
naively
thinking.
You
know
it
feels
to
me
that
you
know
it's
not
a
big
deal
going
with
just
browser-based
code
separately.
There
will
be
some
duplication
and
there
will
be
some.
You
know
deviation
over
time,
which
is
manageable,
right,
I
think
which
is
easier
to
manage
than
you
know.
Dealing
with
you
know
this
branching.
A
Why
not
just
you
know,
go
with
it,
I.
C
Don't
think
you
know
I,
don't
think
we
have
enough
evidence
to
tell
people
to
allow
us
to
do
that.
That's
that's
what
the
sandbox
is
full.
B
Yeah,
so
so,
when
I,
when
I
first
raised
that
a
while
ago,
Daniel
and
the
maintainers
of
the
JSC
were
not
convinced,
they
want
to
try
and
reuse
as
much
as
possible,
because
at
the
end
of
the
day
they
are
the
JavaScript
owners,
and
it
really
is
a
case
depending
where
this
ends
up
living,
whether
it
lives
in
the
JS
repo
which,
considering
it's
language
based
would
probably
be
the
thing
they
want
to
try
and
minimize
the
amount
of
code
they've
got
to
maintain.
So
that's
where
they're
coming
from.
B
But
if
we
can
say,
okay,
we'll
share
the
API,
which
I
think
is
the
minimum
we'll
have
to
do.
But
then
we
have
a
web
SDK
off
that
the
the
problem
is
the
instrumentations.
So
this
is
where
the
experimentation
and
why
I
think
we'll
end
up
with
multiple
branches,
but
the
first
one
is
going
to
be
the
minification
to
say:
okay,
minification
alone
is
not
going
to
work.
So
therefore,
we
create
another
branch
and
say:
let's
just
see
what
we
can
do
to
create
a
web.
B
My
biggest
concern
is
the
global
nature
and
the
and
the
the
you
know
the
fact
that
you
have
to
register
everything
globally
and
the
not
implementations,
I
think
they're,
just
unnecessary
for
a
web
browser,
at
least
from
an
application
perspective
from
an
instrumentation
perspective,
they're
necessary
from
a
web
browser
perspective.
They're
not.
A
B
A
Think
it
might
help
if
we
have
one
conversation
with
the
Daniel
on
this
topic
once
again,
I
don't
know
when
it
happened
in
the
last
the
past.
B
Because
it
happened
a
few
years
ago
in
terms
of
that,
that
was
the
proposal
to
create
the
sandbox
to
specify
to
help
identify
whether
we
can
or
we
can't
in
the
maintain
a
Sig.
Three
weeks
ago,
Ted
raised
the
the
Specter
of
creating
web
sdks
so
he's
starting
to
publicize
it
and
I
sort
of
mentioned
that
that's
one
of
the
things
we're
trying
to
prove
in
the
the
web
sandbox.
So.
A
A
In
the
last
you
know,
you
know
this:
two
years,
the
complexity
of
instrumentation
code
has
gone
up,
that
in
art
list
from
a
gut
feeling
it
you
know
it
feels
like
you
know.
There
is
enough
complexity
by
combining
both
code
presses
already.
B
Yeah
and
that
also
you
know,
environment
structure,
where
you're
going
to
say,
node
and
browser
that
that
really
quite
a
few
issues
get
raised
because
people
get
caught
up
on
that
because
by
default
it's
node.
So
you
have
to
create
your
your
build
definition
to
say:
I
want
the
browser
variant
and
therefore
that
has
to
all
be
maintained.
So
yeah
it's
there
and
as.
C
E
Mean
personal
papayas
because
I
hate
Java
at
Texas,
it's
a
it's
JavaScript
but
yeah.
D
B
But
yeah
that
having
issues
right
so
over
the
years
about
the
size
of
it
too,
and
that
the
size
is
the
biggest
thing
for
browser.
But
then
we've
also
got
the
arbitrary
enforcements
that
are
there.
So.
B
A
Yeah
no
I,
I
I
still
I'm,
not
super
convinced
that
this
you
know
this
needs
to
be
proven,
like
we
can't
take
decision
based
on
the
knowledge
we
have
already.
I
am
I,
don't
know
if
I'm
the
minority.
C
Bring
bring
this
up
for
discussion
one
more
time,
yeah
I,
just
don't
want
it
to
be.
Like
yeah,
we've
already
told
this,
you
know
we
asked
you
to
go,
do
something
you
haven't
proven
it.
So
we're
just
going
to
stick
with
this.
C
B
Yeah
and
and
what's
the
sandbox,
is
that
there's
no
reason
we
can't
create
a
a
branch
that
purely
is
just
doing
exactly
that
just
throwing
away
everything
like
it's
part
of
the
sandbox
I'm,
only
bringing
over
components
for
the
web,
I'm
I'm,
specifically
excluding
node
ones,
because
it
doesn't
make
sense
because
I'm
trying
to
get
web
and
worker
tests
running
as
well
so
yeah.
We
can
definitely
create
a
branch
and
say
this:
is
the
web
SDK
scratch
that's
purely
going
to
be
focused
on
creating
a
web-only
SDK.
That's
completely
separate
node.
C
And
I
know
you
chat
about
this
before
you
know,
when
how
close
are
we
to
actually,
you
know
open
it
up,
opening
up
the
sandbox
for
use.
B
So
I,
just
getting
through
this
npm
unblock
so
so
I've
now
got
it
running
again
this
morning,
except
the
tests
are
failing,
because
the
the
code
issues
and
some
of
my
test
definitions
are
failing
again,
because
some
of
the
things
I've
had
to
do
so.
I'm,
hoping
that
by
the
end
of
the
week.
C
C
So
if
we
put
something
on
the
on
the
calendar
for
say
next
week
or
another
week
after
something
like
that,
to
bring
this
up
for
discussion
and
probably
making
a
decision
would
be
a
good
goal
to
have
them.
I
think.
A
Sorry,
I
I
didn't
completely
follow.
Are
you
talking
about
just
a
conversation
between
ourselves
or
even
including.
C
C
A
A
A
Nine
o'clock
there's
a
JSC
meeting
right.
We.
D
B
Now
we
can
mention
it
tomorrow
that
we're
we're
looking
to
propose
this
once
the
sandbox
is
open,
yep
and.
C
B
Well,
from
from
my
perspective,
it
was
the
JSC
because
it's
JavaScript
that
I
was
focusing
on
in
terms
of
client
based,
sdks
I,
don't
think,
there's
a
general
pushback
for
that
they
just
don't
have
the
people
creating
client-based
sdks
at
this
point
from
Ted's
perspective,
he
wants
client-based
sdks,
so
I.
C
Think
it
makes
sense
and
if
we
all
have
been
saying
that
people
that
are
swimming
in
the
client
world,
we
all
know
that
it's
not
gonna.
Those
individual
resistic
is
not
going
to
cut
it.
Yep.
B
B
B
That
I
think,
because
we
really
we
want
the
sandbox
open
and
we
want
to
start
getting
the
JS
Sig
on
board.
D
D
A
B
So
I
did
update
my
event
data
spec
this
morning,
but
that
was
really
just
a
rebase
just
to
keep
it
alive,
so
it
doesn't
go,
get
marked
stale
and
get
closed.
Yeah.
A
Yeah,
one
and
quick
topic
I
think
the
events
API
the
events,
SDK
event
that
is
going
in
circles,
let's
I
I,
hope
to
I,
mean
I'm
planning
to
bring
it
up
in
the
lock
set
tomorrow
to
at
least
decide
whether
we
want
it
or
not,
because
you
know
they're
initially
depended
on
the
logger.
We
removed
the
dependency,
and
now
there
is
a
counter
argument
saying
that
you
know
now
that
you
are
completely
made
it
independent.
B
Yeah
Tigard
did
make
have
some
words
on
that
this
morning
and
then
sort
of
used
the
word.
If
we
create
the
event
API,
it
would
be
using
the
logs
API
but
yeah.
E
A
Okay,
let's
see
where
that
goes
so
I'm
I'm!
That's
why
you
know
I'm
thinking
that
we
will
proceed
with
building
these
instrumentations
based
on
the
log
API
for
now,
yep
I'll
eventually
go
to
the
to
the
event
API,
but
they
will
still
be
based
on
the
general
notion
of
events
that
we
are
coming
up
with.
At
least
the
data
model
is
if
there
is
acceptance
the
the
API
in
the
SDK
I
think
you
know
those
it's
okay.
If
they
took
time.
B
A
B
Then,
which
effectively
would
be
a
superb
tiny
prototype
of
the
event
SDK
that
way,
we
can
flip
it
out
under
the
covers,
and
that
can
be
effectively
the
the
earlier
versions
of
what
what
the
event
SDK
would
look
like.
A
D
D
A
Okay,
that's
all
my
sound.
B
Yep,
probably
the
other
thing
that
came
up
Santosh
was
we
talked
about
collapsing
down
to
just
one
meeting
a
week.
A
A
The
meeting
yeah
so
I
so
tigran
said
Wednesdays
doesn't
work
for
him.
Tuesday
is
this
time,
neither
so
he's
suggesting
something
on
Friday
and
Friday.
I
prefer
not
to
have
meetings
yeah.
Likewise
well,
I.
E
B
E
A
E
A
Yeah
yeah,
so
so
yeah
I
will
not
have
it
on
Friday.
So
if
it
is
one
meeting,
then
yeah
anything
like
how
do
we
go
about
picking
between
these
two
slots.
B
Yeah,
so
what
was
going
to
happen
is
Martin
was
gonna
ping.
His
TC
coverage
issue
that
he
that
he
raised
to
try
and
get
some
feeling
for
when
they
wanted
and
then
was
going
to
send
out
a
doodle
with
some
possible
times.