►
From YouTube: 2022-06-21 meeting
Description
Instrumentation: Messaging
A
D
So,
as
promised
today,
I
have
a
couple
of
developers
with
me
so
I'm
awfully
sorry.
I
won't
turn
on
the
video
camera
we
are
located
currently
in
our
Dyno
Trace
Barcelona
office
and
short
intro
round.
I
have
mercel
with
me.
His
iOS
Developer
I
have
Patrick
with
me.
It's
also
iOS
development
team
lead
and
I
have
Thomas
with
me.
He
is
an
Android
developer
and
one
of
our
guys
from
the
U.S
will
also
join
or
is
already
joining
so
Nick
is
also
joining
and
he
is
mainly
working
on
our
react.
D
C
So
what
I
was
the
only
thing
that
that's
been
on
my
mind
was
to
continue
talking
about
the
timing.
Events
for,
but
that's
very
much
browser
oriented,
so
I
wonder
how
to
make
the
best
use
of
time.
Since
you
have
your
colleagues
with
mobile
background,
are
you
looking
to
to
discuss
certain
specific
topics
around
Mobile
today
or
would
do
you
just
want
to
see
where
we
are
and
how
you
can
contribute.
D
So
my
proposal
would
be
since
last
time
you
asked
what
about
timing
events
on
mobile
in
mobile
applications.
We
could
discuss
this
topic.
C
E
F
E
C
Yeah
so.
C
So
I
guess
just.
C
Quick
background
we
have
been,
we
have
been
kind
of
going
in
the
direction
of
capturing
events
from
client-side
telemetry.
C
So
so,
like
you
know,
in
the
past
there
was
spans
sponsors
where
the
owners
signal
that
was
available.
Now
that
logs
are
available,
the
the
thinking
is
that
the
logs
are
more
appropriate
for
for
capturing
different
things
that
come
from
client-side
from
browser
and
mobile,
and
the
the
one
type
of
event
we
started
discussing
last
week
was
timing
events,
at
least
in
browser.
It's
it's
a
number
of
things,
but
I
can
hold
on.
Let
me
yeah,
maybe
I
can
share
my
screen.
C
C
Yeah
so
so
we
we
were,
we
were
looking
at
for
like
different
type,
different
examples
of
different
types
of
events
that
would
happen
in
a
client
application
and
how
they
would
be
captured.
So
we
have
like
in
this
table
like
we,
have
the
event
type,
and
then
we
have
the
platform.
Is
it
browser
or
mobile?
C
C
Things,
like
you
know,.
C
Like
screen
log
orientation
change,
app
crash,
obviously
I
have
another
responding,
app
backgrounded,
app
start
Network
change.
C
And
then
interaction,
interaction,
events
like
touch
click
as
events
so
essentially
like
most
of
this
group
like
we're
more
browser
oriented,
but
so
it
would
be,
would
be
great
like
if
he
had
some
expertise
in
what
these
events
look
like
in
different
types
of
mobile
applications
and
what
the
semantic
conventions
should
be
for
them.
C
So
that's
kind
of
the
background
we
are.
We
started
working
on
on
semantic
conversions
for
timing
events
and
I,
guess
where
we
didn't
what
we
didn't
decide
quite
yet,
let
me
see
if
I
can
find
the
dock.
B
C
So
we
started
working
on
timing
events,
semantic
conventions
and
the
timing
event
is
is,
and
this
is
like
discussion
and
progress,
but
but
coming
event
is
like
something
that
has
has
a
decent
browser:
a
measurement
of
duration
relative
to
the
to
the
start
of
the
navigation,
so
maybe
like
in
mobile
application,
I,
don't
know
in
a
mobile
application.
C
There
would
be
a
similar
concept
like
you
have
you
know
how
long
it
takes
to
to
load
the
application,
how
long
it
takes
to
render
something
to
the
screen-
and
you
know,
gives
you
kind
of
indication
of
how
long
the
user
has
to
to
wait
when
they're,
when
the
application
is
starting
up.
For
example,
like
browser,
has
this
navigation
timing
concept,
so
it
has
a
bunch
of
different
events
that
tell
you
like
at
this
time.
At
this
time
the
the
web
application
displayed
something
or
painted
something.
C
At
this
time
the
application
was
responsive
and
then
then
there
are
additional
types
of
timing.
Events
like
you
know
like
when,
like
when
the
first
input
like
the
like
the
first
time
that
the
user
would
interact
with
the
with
the
UI.
C
There
is
element
timing
like
different
different
things
on
the
on
the
screen.
You
might
want
to
measure
how
long
the,
how
long
it
takes
to
to
paint
the
screen
you
might
have
like
user
timing.
That
is,
you
know,
captured
from
the
application
itself.
Like
that's
custom,
you
might
have
like
visibility
like
when,
when
the
UI
was
was,
was
backgrounded
and
then
shown
again
and
then
when
it
was
unloaded
completely
and
then
yeah.
C
So
so
we've
been
talking
about
it
from
the
perspective
of
browser
and
I.
Don't
know
like
if,
at
this
point,
I
don't
know
like
if
you
want
to
have
a
common,
some
kind
of
a
common
set
of
attributes
that
applies
to
both
mobile
and
browser
for
certain
types
of
these
events
or
if
they
just
want
to
completely
like
handle
them
separately.
C
D
So
I
think
and
I
think
my
colleagues
here
and
also
Nick
tried
remotely
will
agree.
There
are
certain
semantic
conventions
that
overlap,
especially
if
you
consider
Concepts
like
sessions
but
such
for
such
specific
events
as
the
timing
events,
that's
totally
browser
related
because
I
mean
you
have
app
events
so
that
you
can
track,
but
that's
more
mobile
related
and
even
it
depends
how
granular
you
will
go
down.
There
is
certain
callbacks
or
certain
notifications
that
you
receive
on
iOS
that
are
completely
so.
The
naming
is
completely
different
on
iOS.
Then
it's
on
Android.
D
You
will
have
for
few
changes.
You
will
get
some
notifications
and
there
it
also
depends
on
the
naming
also
depends
on
iOS
versus
Android
and
all
the
on
Android.
It
also
depends
on
the
API
level,
how
granular,
or
which
callbacks
you
actually
receive,
because
I
think
it's
it's
with
API
level,
28
that
they
introduced
new
callbacks
or
improved
at
Thomas.
Do
you
know
a
tricked.
C
It
might
be
easier
like
to
work
on
them
separately
too.
Instead
of
trying
to
spend
a
lot
of
time
on
finding
the
commonality.
D
I
mean
the
question
is:
there's
one
question
that
is
unclear
because
there
are
certain
Concepts
like
let's
say,
web
requests,
so
where
you
make
a
fetch
or
extra
jar
on
a
browser,
there
is
the
same
concept
on
mobile
devices.
I
mean
yeah.
C
D
Or
the
mechanism
to
fetch
data
will
be
different,
but
basically
the
concept
is
the
same.
G
Probably
a
better
example
would
have
been
like
the
the
interactive
stuff
that
you
started.
Looking
at
originally
Martin
your
page
actions
and
stuff,
like
that,
I
think
that's
where
we're
going
to
find
a
lot
of
crossover
as
well
as
the
your
xhr
fetch,
the
ajax
type
requests
that
are
more
common
across
all
platforms.
G
Yeah
in
your
interactive
events,
like
did
the
user
click
here.
Did
they
do
this?
Did
they
scroll?
You
know
stuff
like
that
yeah
as
well.
As
you
know,
just
a
generic
page
view.
Okay,
the
user
popped
up
this
dialogue,
or
you
know,
give
Etc
yeah,
which
we
can
debate,
whether
that's
just
another
type
of
page
action
but
yeah.
That's
where
we
get
into
the
details
of
you
know.
G
I
think
there
is
a
broad
chunk
of
events
that
are
generally
shared
in
terms
of
the
concepts
it's
just
the
nitty-gritty
details
and
unfortunately,
the
the
timing
ones
are
extremely
specific
to
browser
because
it
is
just
pulling
the
browser.
C
Yeah
sounds
good,
there's,
so
there's
a
just
Stefan
and
folks,
just
so,
you
know,
like
we
have
a
few
different
dogs,
they're
Linked
In,
the
at
the
top
of
the
here
like
links
here.
So
we
have
this
semantic
conventions
dark
which,
which
kind
of
has
the
goal
of
this
doc
was
to
actually
write
down
the
semantic
conventions,
if
all
of
them,
like
all
different
types
with
in
a
format,
that's
that
would
be
in
the
spec
specification.
C
So
we
have
at
the
bottom
here,
like
we
have
a
section
for
events
and
I
do
have
a
section
here
for
common
common
attributes.
C
So
this
would
be
you
know,
namespaced
attributes
that
are
the
same
for
mobile
and
browser,
and
then
I
have
a
browser
section
down
here,
which
has
browser
specific
but
like
Nev
would
never
saying
like,
maybe
like
certain.
Some
of
these
might
be
might
be
shared
between
mobile
and
browser
right.
So,
like
the
exceptions,
one
obviously
that
there's
a
lot
of
semantic
conventions
for
exceptions
and
interactions
potentially
will
be
shared
with
the
mobile
as
well.
But
that's
we
haven't
talked
about
this
yet
so
that's
deep
to
be
defined.
C
G
All
the
different
types
of
events
that
we
have
and
I
think
that
would
be
a
good
start.
Unfortunately,
I've
been
concentrating
on
getting
the
the
web
sandbox
going
when
I'm
not
getting
sidetracked
with
the
internal
stuff.
G
So
we
have
another
chance
to
do
that,
yet
so
I
guess,
Stefan
and
and
co.
If
that's
something
that
you
could
do
from
your
side
of
things
in
terms
of
the
the
types
of
events
that
that
you
would
want
to
see
included
by
default
or
standardized
by
default,
that
might
be
a
good
place
to
start.
C
Sure
you
can,
you
can
take
a
look
at
this
at
this
plan
document
which
which
I
shared
like
it
has
where
we
listed.
You
know
some
of
these
events
this
we
did
this
like
a
long
time
ago,
probably
like
six
months
ago,
when
John
Watson
was
here,
he
was
was
working
on
Android
and
I.
Think
Bryce,
Bryce
Buchanan
was
working
on
iOS
on
Swift.
C
C
C
Browser
has
this.
You
know
we
said
you
know.
Stefani
said
that
there
is
a
potentially
some
commonality
for
Network
requests.
C
Browser
has
this
API
for
getting
details
about
these
requests
from,
like,
like
a
low
level,
API
Minnesota,
look
like
instead
of
just
wrapping.
These
Network
calls
like
the
browser.
Api
actually
gives
us
more
information
like
things
like
how
long
it
you
know
it
took
to
connect
how
long
it
did
it
take
to
look
up
the
domain.
The
main
lookup
start
redirect
request
start
response
start,
so
it
gives
you
like
more
details
about
the
the
network.
Request
does
do
things
does
something
like
that
exist
in
Mobile
as
well.
H
So
for
resources
not,
but
for
the
first
frame,
you
have
event
specific
points
that
you
can
capture
and
then
see
the
timing
for
the
first
frame,
but
for
the
exit,
when
all
the
data
status
no
way
to
determine
it
automatically.
C
H
No
because
they
are
not
linked,
and
so
of
course
they
have
different
names,
but
you
can
see
on
which
states
the
first
frame
would
run
through.
So
it's
visible
on
the
device.
H
So
normally
it's,
for
example,
I'll,
buy
background
with
a
loading
screen,
but
when
the
data
then
is
fully
loaded
and
available,
it's
not
possible
to
determine
that
directly.
C
C
C
I
guess
that's
I
have
so
my
my
other
topic
for
for
today
was
gonna.
Be
talking
more
about
the
timing.
The
some
medical
mentions
for
the
timing
events
but
I'm
I'm
wondering
if
it
makes
sense,
given
that
we
don't
really
have
a
lot
of
browser
folks
here.
C
Again
so
so
my
my
other
topic
for
for
today
was
to
talk
to
talk
more
on
in
detail
about
semantic
conventions
for
the
timing,
events
for
browser,
but
we
don't
really
have
you
know
it's.
We
don't
have
any
other
browser
folks
who
usually
join
so
I.
Wonder
if
you
should
postpone
that
till
tomorrow.
G
Yeah
I
think
Skip
that
I
I
really
need
to
spend
some
time
like
I
think
we've
covered
most
of
it
already.
It
really
is
okay,
so
yeah,
let's
deal
with
it
tomorrow,.
C
Okay,
yeah,
just
one
just
to
give
you
give
you
a
heads
up.
One
thing
that's
been
kind
of,
on
my
mind,
is
figuring
out.
When
do
we
use
spans
and
when
do
we
use
events.
G
Will
want
to
include
the
span.
Some
people
won't
because
yeah
for
the
page
for
the
yeah
yeah.
Let's
talk
tomorrow.
C
Okay
sounds
good
I
think
that
might
be
a
longer
discussion
with.
Probably
we
need
more
people
involved,
yeah,
okay,
Stefan
do
you
does
so
like
so
I
think.
Does
this
give
you
enough
information
to
start
start
with?
Do
you
want?
Do
you
have
any
other
questions
or.
D
So
from
my
side,
it's
clear
one
of
my
colleagues
already
had
some
questions
to
me.
What
else
like
so
there
seems
we
already
found
the
missing
event
and
two
events
in
Mobile
that
are
very
similar
and
quite
related.
Actually,
okay,
so
you
already
have
a
review
on
on
the
mobile
events.
Yeah.
F
B
B
C
I
see
yeah
that
might
be
duplication,
yeah,
oh
okay,
now
and
actually
one
is
I
think
for
a
browser.
It's
just
like
for
browser,
it
might
be.
Did
we
lose
in
connection
and
did
we
restore
connection
as
opposed
to
change
in
the
like
the
type
of
connection.
G
Yeah
the
description
there
was
that
seemed
wrong
as
well
for
the
thing,
because
the
determining
the
network
changes
the
listening
to
the
online
offline
events
from
the
the
Navigator
as
opposed
to
visibility,
change,
which
is
the
hydration
stuff.
So
switching
to
be
the
description.
I'll
talk
about
we'll
see
the
visibility.
Visibility
is
only
what
to
do
with
the
browser
foreground
background
and,
if
you're
on
a
mobile
device,
it
could
be
that
the
cat
got
hydrated,
which
I
guess
is
for
the
react
side
of
things
as
well
yeah.
C
Sorry,
okay
passed
it.
G
Which
again,
like
Stefan,
was
talking
about
another
Network
change
down
down
below,
so
in
the
browser
we
can't
detect
whether
it's
a
change
of
a
network
type
just
the
world,
whether
online
or
offline,
but
that
could
just
mean
we
Define
it,
but
we
don't
emit
it
for
a
browser.
C
C
C
So
Stefan
I
think
finding
like
defining
the
events
that
you
would
like
to
see,
captured
and
also
prioritizing
them
would
be,
would
be
good
like
which
do
you
think
are
the
the
top
priority
like
to
be
captured.
C
For
for
browser,
I've
been
thinking
we
want
to,
we
want
to
Define
semantic
conventions,
for
exceptions,
for
timing
events
and
for
interactions.
D
D
So
basically
the
timing,
I
would
say
it.
Then
let's
make
life
cycle
events
and
so
few
in-depth
life
cycle
and
user
interaction.
It's
again
the
same
concept.
The
naming
is
slightly
different.
So
in
in
a
browser
you'd
say
you
click
on
a
button,
whereas
on
in
a
mobile
application,
you'd
rather
say
you
touch
on
a
button.
D
D
D
I
mean
there
is
this
exception:
semantic
convention,
where
you
can
report
the
stack
Trace
on
iOS,
it's
more
a
crash
dump,
so
something
similar
that
Windows
native
application
would
report
and
not
a
stack
Trace,
because
it
already
includes
more
information.
Like
registers,
the
stack
traces
of
all
active
threads
loaded,
Frameworks,
maybe
yeah.
D
So
we
could
abuse
the
SEC
Trace
in
this
case,
or
we
could
Define
it
on
basically
for
each
operating
system.
D
D
So
the
let's
say
that
the
crash,
an
application
correction
on
Android
and
on
iOS,
is
different,
because
on
Android
you
will
have
something
like
an
exception.
So
I
throw
it
like.
You
know
any
Java
application,
whereas
on
iOS
you
have
a
a
dump
of
the
process
which
includes
already
more
information
than
just
the
stack
Trace.
So
something
like
the
windows
dump
that
you
get
when
an
application.
Yeah.
G
That
might
be
a
case
of
two
separate
events.
We
have
a
generic
one
which
is
okay,
it
crashed
so
that
that's
a
signal
so
that
someone
can
log
a
crash
and
then
you
we
could
have
like
a
a
crash
detail,
maybe
which
is
then
specific
to
the
platform
that
it's
on,
and
we
probably
want
to
create
some
sort
of
hash,
which
I
think
we
talked
about
in
a
previous
thing,
so
that
you
can
group,
though
the
crash
dumps
together.
Thank
you
just
a
thought.
D
So
that
suggestion
would
be
we'll
have
a
separate
demand
for
crashes
and
and
exceptions.
G
Well,
you
can
still
have
a
you,
can
still
throw
an
exception
saying
that
the
app
crashed,
so
you
can
still
have
that
there
was
the
problem,
but
then
you
have
so
effectively
in
the
case
of
a
crash
I'm
saying
we
potentially
emit
two
events,
one
is
an
exception
saying
it
crashed
and
the
other
one
is
the
exception
detail.
G
What
would
which
enables
the
you
know
you
to
go
and
dig
in
deeper
into
the
into
the
crash.
But
the
initial
signal
saying
there
was
a
problem
was
was
listed.
So
does
that
make
sense.
D
G
Yeah,
because
we
you
could
group
them
either
well,
they
should
have
the
same
session
I
think.
But
this
comes
back
to
the
thing
we
discussed
earlier.
You
know.
Maybe
we
create
a
span
to
group
those
two
things
together.
There.
D
So
usually
it
is
like
this
that
an
uncaught
exception
leads
to
an
application
termination
yeah.
Unless
you're
in
react
native,
then
the
app
will
just
continue
running
or
reset,
but
Nick.
E
Yeah
yeah.
We
have
that
like
check.
Basically,
if
it's
an
encoder
or
unhandled-
or
you
know
like
a
it's
supposed
to
terminate
the
app
basically
like
I,
can't
think
about
the
specific
wording
is
for
it,
but
essentially
what
you're
mentioning
like.
E
If
it's
something
that's
going
to
crash
the
app
or
it's
not
going
to
crash
you
up
and
then
report
it
based
off
of
that
like
if
it's
a
stat
like
has
more
information
for
a
stack
trace
or
the
report
stack
Trace
API
that
we
have
or
what
have
you
so
that
there's
other
additional
options
based
on
whatever
framework's
being
used,
because
yeah
that's
that's
hard,
because
everything
differentiates
between,
especially
in
the
hybrid
side,
the
the
Frameworks
and
how
you
really
want
to
report
it
or
approach
it.
E
So
that's
where
it
becomes
a
little
bit
difficult
to
keep
the
commonality
between
all
the
different
Frameworks
and
ways
of
creating
mobile
apps
and
such
but
yeah.
That's
a
definitely
can
be
quite
tricky,
potentially
yeah.
G
And
that's
one
of
the
reasons
I
was
thinking.
We
have
a
separate
common
one
that
just
says
something
really
bad
happened,
and
then
we
capture
the
detail.
If
we
can
as
a
separate
thing,
which
could
be
very
specific
to
the
Frameworks,
so
I
think
node
has
something
similar.
You
can
have
a
affected
the
terminal
event
handler
I,
don't
I,
think
a
background
might
have
something
to
go
through.
C
Great
I
think
that's
probably
good
for
today,
so
I
think
tomorrow,
yeah.
Let's
talk
about
more
about
the
timing,
events
and
yeah
thanks
thanks
guys
for
attending.
D
Thank
you
very
much
for
having
me
Martin.
If
you
will
continue
on
browser
related
events
tomorrow,
I'm
suggesting
to
keep
the
for
or
if
do
you
do,
you
think
there
will
be
other
questions
related
to
mobile,
because
then
I
would
invite
the
colleagues
otherwise.
D
C
I
I
can't
think
of
specific
questions
for
mobile
mobile
at
this
point,
I
think
you
know
probably
what
I
would
do
maybe
like
after
yeah
after
we
have
the
discussion
about
timing
events
tomorrow.
If
there
are
any
questions
about
mobile,
then
we
can
follow
up
with
those
questions.
Next
week.
C
And
yeah
sounds
like
these
timing
events
there
might
be.
There
may
not
be
a
lot
of
overlap
so,
but
then,
after
after
we
that
will
start
talking
about
interaction
events,
then
then
perhaps
we
should
plan
on
having
both
both
browser
and
mobile
together.
G
Well,
no
I
think
it's
for
a
case,
so
there
may
be,
like
you've
got
documented
effectively
the
entire
timing
set
of
events.
There
may
be
an
equivalent
of
one
or
two
of
those,
maybe
yeah
that
that
would
cross
over
yeah
but
yeah
like
some
of
the
resource
ones.
Yeah,
maybe
not
first
paint,
probably
definitely
not
yeah.
G
E
I
mean
that's
the
main,
like,
like
view
controller
or
activity
loads,
like
a
lifecycle
events
similar
to
what
the
page
loads,
but
that
the
first
two
on
on
react
native,
because
we
have
the
component
loads
and
everything
but
and
rendering
and
such
but
yeah.
There's
probably
something
similar
in
that
case.
But
I
don't
know
if,
like
there's
a
way
to
dynamically
change,
the
name
based
off
of.
If
it's
you
know,
if
the
whatever
finds
it's
a
browser
versus
a
mobile
app
or
whatever
else.
G
C
All
right,
my
kind
of
my
intuition
is
kind
of
shows
that
it
says
that,
like
it's
probably
better
to
to
not
try
too
hard
to
to
Define
like
common
common
names,
because
I
think
we
might
run
into
attributes
that
maybe
like
are
not
intuitive.
Like
you
know,
the
names
names
like
don't
really
make
sense.
C
G
Yeah,
which
is
why
I
I,
like
Stefan's
breakdown
of
you,
know
calling
them
life
cycle
events.
So
we
can
probably
have
the
major
life
cycle
events
as
common
and
then
we
have.
Then
we
have
a
set
of
environment,
specific
ones
that
happen
to
fire
as
part
of
life
cycle,
but
they're
not
standard
to
all
the
time.
C
So
would
you
actually
call
that
life
cycle
somewhere
in
the
names
I.
G
C
G
What
type
is
we
talked
about
last
week.
C
C
Okay,
so
Stefan
I
guess
I
I,
don't
know
that
you
need
to
pull
other
folks
in
tomorrow.