►
From YouTube: 2021-11-17 meeting
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
A
C
E
D
D
So
I
think
if
you
haven't
seen
the
pr,
please
take
a
look
it's
in
draft
right
now
and
I'm
not
actually
clear
if
it's
ready
to
be,
you
know
opened
for
for
review.
So,
like
initially,
we
talked
about
using
the
device
namespace
for
identifying
client-side,
client-side
telemetry,
and
then
I
think
there
was
some.
It
was
not
clear
like
where
exactly
iot
devices
would
fit.
You
know
like
do
they
are
they
client-side
or
are
they
not
client-side?
D
And
we
didn't
come
to
a
conclusion,
so
we
thought
maybe
the
device
should
not
be
designated
as
client-side,
necessarily
because
because
there
might
be
potentially
devices
that
that
do
not
represent
client
side,
but
I'm
not
sure
about
that.
So
the
the
other
thing
that
I
did,
I
added
the
app
namespace
app
attributes
to
distinguish
that
from
the
service.
D
B
So
there
are
multiple
topics
here
right.
I
think
I
think,
let's
get
to
the
iot
aspect
in
the
end,
because
I
think
it
seems
to
be
unclear
for
a
lot
of
us,
including
me,
but
I
do
want
to
talk
about
it,
even
if
we
don't
include
it
in
the
in
the
documentation,
but
I
think
browser
and
device
and
app.
These
three
namespaces
are
very
clear
because
you
just
mentioned
that
device
might
have
a
conflict
with
back-end
devices.
B
I
think
I
have
I.
I
do
agree
that
there
could
be
devices
on
the
back
end
too,
but
as
long
as
we
clarify
in
the
documentation,
then
we
lock
it
to
the
client
side,
and
so
with
that
we
can
proceed
with
finalizing
with
agreement
among
the
members
here.
B
The
namespace
is
browser
for
browsers.
You
know
no
matter
where
they
run
mobile
or
desktop
tablets.
Browsers
is
one
category
device
for
mobile
and
app
dot,
name
or
app
name
space
for
the
apps
on
the
client
side.
So
if
we
agree
on
these
three,
you
know
we
could
you
know
lock
them.
So
do
we
any
thoughts
on
this.
D
On
I
think
in
three
terms,
so
I
think
you
know
like
one
like
one
thing,
that
one
of
the
reasons
like
that
we
want
to
introduce
these
like
the
app
I'm
specifically
thinking
about
the
apps
namespace
is
like
to
be
able
to
identify
the
telemetry,
that's
to
be
a
client-side,
so
like
specifically
like
when
we
get
when
we
consume
logs.
On
the
back
end,
we
want
to
be
able
to
say
these
are
client-side
logs
or
events,
and
you
want
to
send
them
like
a
different
processing
pipeline.
B
Yeah,
that
is
a
side
benefit
for
sure.
That
is
a
needed
for
sure.
Apart
from
that,
we
at
appdynamics
also
want
to
use
apps
in,
in
conjunction
with
r,
are
similar
with
a
similar
meaning
as
the
services
on
the
back
end
because
different
you
know,
services
interact
with
each
other.
Similarly,
there
is
you
know
one
service
like
thing
out
on
the
internet.
B
You
know
from
where
you
know
users
interact
with
the
services
on
the
back
end
right,
so
it
serves
that
purpose
as
well
that
similar
to
how
back-end
services
are
represented.
There
is
one
service
in
the
cloud
which
is
you
know
calling
it
a
services
is,
you
know,
is
more
confusing.
Therefore,
we
want
to
call
it
a
new
app
and
those
apps
interact
with
these
services.
D
B
For
server
applications,
the
recommendation
is
to
use
service.
D
B
Yeah
I
mean
the
the
term
service
is
more
commonly
used
in
the
back
end.
D
Yeah,
it's
it's
just
like
I'm,
I'm
just
thinking
like
if
there
are
any
like
if
they're
gonna
be
any
cases
where
it's
not
clear
whether
you
should
use
service
and
app.
B
That
is
where
I
think
I
feel
we
should
define
the
term
client
side
in
the
glossary,
and
I
am
not
necessarily
preferring
the
word
climb
side.
You
know
if
we
feel
a
real
user
or
end
user
or
any
other
term.
That
is
fine,
but
you
know
I
think
we
should
designate
some
term.
B
D
Yeah
I
mean,
I
think
that,
where
it's
kind
of
gets
a
little
bit
fuzzy
for
me
is
like
when
we
talked
about
iot
devices.
If
you
have,
if
you
have
some
some
device
that
just
doesn't
interact
with
end
users,
but
it's
reporting
or
doing
some
work.
Maybe
periodically
then
like,
is
that
a
service
or
is
an
app.
B
B
Okay,
let's
talk
about
iot,
then
even
for
us,
iot
is
not
a
priority
at
this
point.
I
the.
B
Only
reason
I
wanted
to
I,
I
mainly
want
to
define
the
term
client
side
and
tomorrow
you
know:
whenever
we
get
to
the
iot,
you
know
we
could
fit
iot
into
the
client
side.
B
You
know
that
that
is
okay,
but
what
I
wanted
to
convey
was
that
you
know
even
the
iot
devices
from
what
I
have
seen
like
I.
I
worked
in
a
wireless
company.
You
know
before
this.
You
know
where
there
are
access
points
that
customers,
you
know
deploy,
and
they
are
remotely
managed
right.
They
they
connect
to
the
cloud
and
they're
managed.
So
for
again
in
you
know,
and-
and
there
could
be
your
cell
phones-
that
connect
to
the
wireless
access
points.
So
iot
is
something
similar.
You
know
they
either
connect
directly.
B
If
they
are
assuming
they
are,
they
are
internet
connected
at
iot.
Now,
on
the
internet
side
on
the
cloud
side,
you
know
that
refers
to
the
back
end,
so
these
are
in
the
field
in
the
customer
network
or
on
the
internet.
So,
from
a
networking
perspective
it
fits
the
definition
of
client
side.
B
Now
there
are
hubs.
Gateways.
Are
these
intermediaries
proxies?
You
know
they
are
still
in
the
customer
network
it.
You
know
the
deployment
is
very
similar
to
how
we
have,
let's
say
the
java
agent
connecting
to
a
collector
both
of
them
in
the
customer
network,
and
they
are
passing
on
the
telemetry
to
you
know
your
telemetry
back-end,
so
both
of
these
would
be
considered,
as
you
know,
client
side
right
because
they
are
all
on
the
on
in
the
field.
B
B
Sorry
so
the
customers
have
probably
a
server
application
running
in
their
data
center,
and
you
know
they
could
be.
Let's
say
it's
an
on-prem
deployment
right
so
where
the
server
could
be
in
in
in
their
private
data
center
and
their
devices
could
be,
you
know
all
over
their
office
or
outside
on
the
internet.
So
it
is
it
it
could
be
still
in
a
private.
In
the
sense
it
is
private
to
the
customer,
but
it
is.
It
is
not
backend,
because
there
is
a
separate
backend.
C
Yeah,
it's
typically
and
I'm
thinking
of
like
a
more
formal
definition
of
client
device
like
it's
something,
that's
probably
untrusted
to
an
extent
right
things,
things
running
in
your
own
server
cluster
are
trusted
and
something
that
generally
end
users,
or,
I
guess
in
the
case
of
iot
devices.
Sometimes
the
environment
interacts
with
as
opposed
to
processing
data
that
is
sent
to
it
from
a
client.
H
B
C
Yes,
so
it's
it's
a
pr
into
the
specification
repo,
so
it'll
be
people
on
the
open,
telemetry
technical
committee.
Who
I
mean
you
I
think
several
of
us
were
on
the
the
call
a
few
weeks
ago
and
he
met
with
the
the
specs
say.
Most
of
them
were
there,
so
that's
any
any
tc
member.
So
typically
it's
like
bogdan
carlos
tigran,
one
or
two
others.
B
C
And
unless.
C
D
When
we
talked
about
having
like
the
ram
or
end
user
definition,
which
is,
but
that
would
be
more
specific
to
just
end
user
devices
like
something
that
users
interact
with
so
if
you
want
to
include
iot
devices
or
other
use
cases,
then
client-side
probably
makes
more
sense.
C
C
B
D
Okay,
I
don't
know
if
the
glossary
is.
This
is
part
of
the
same
repo.
If
it
is
that
I'll
include
it
in
the
same
vr,
if
not
open
a
different
one.
D
D
But
I
think
other
than
that,
if
that's,
if
that's
the
case,
then
I
think
the
pr
from
my
point
of
view
is
okay
like
it's
got
like,
I
did
remove.
D
D
B
Now
you
would
now,
you
would
use
the
term
client
side.
D
D
D
B
Yeah,
it's
again
not
common,
but
I
think
it's
helpful
as
long
as
it
has
a
default.
So
I
think
you,
the
documentation,
says
if
it
is
not
specified,
then
an
unknown
is
a
name
space
by
itself,
right
so
yeah,
so
yeah.
We
are
good.
Then.
D
Yeah,
so
I
was,
I
was
just
basically,
I
was
just
here.
I
was
copying.
What
was
in
the
service
namespace,
where,
like
the
definition
of
of
the
device
dot
namespace
attribute,
was,
if
you
wanted
to
group
group
certain
apps,
maybe
by
team
or
by
like
some
higher
level
of
service
description,
then
you
would
use
namespace
so
so
it
that
made
sense
to
me
that
you
could
have
the
same
concept
in
client
side.
G
Sure
we
want
to
add
something
around
the
like
the.
I
don't
know
exactly
what
it's
called
across
across
implementations,
but
like
the
bundle
name,
that's
uploaded
or
that's.
You
know
sent
to
google
play
or
whatever
app
store,
and
things
are
in.
G
G
C
G
C
Yeah,
I
mean
also
valuable
for
organizations
that
aren't
explicitly
setting
the
version
number
or
aren't
using
semver
properly
the
bundle
name
it.
It
would
almost
be
like
looking
at
a.
I
know
it's
a
different
scenario,
but
if
sort
of
vaguely,
like
looking
at
say,
like
a
git,
commit
for
a
build
in
some
sense,
you
could
use
it
like
that.
A
F
Sorry
also
one
question:
regarding
the
version:
should
we
distinguish
between
the
human,
readable
version
and
version
so
talking
about
mobile,
app
versions
that
you
specify
on
the
app
store.
F
On
ios
you
have,
you
can
specify
the
cf
boundary
version
and
the
cf
bundle
short
version
string.
So
one
is
human
readable
which
you
can
specif,
which
you
can
give
any
value
that
you
want
and
one
has
to
follow
a
certain
semantic
convention.
So
in
android
it's
a
numeric
value
that
needs
to
create
increase.
Monotonically.
C
C
Video
things
rearranged
for
a
developer
who's
developing
on
ios,
which
one
of
these
would
they
typically
use,
or
would
it
depend
on
the
company
some
might
use
the
short
some
might
use
the
log
for
their
own
internal
processes
right
like
if,
if
a
developer
is
working
on
it
and
they're
told
you've
got
to
ship
this
in
the
next
version.
Would
they
be
like?
Oh
that's
version
2,
which
we
exposed
to
our
customers
or
version
175,
which
is
what
the
app
store
version
is
so.
F
C
It
would
be.
What
would
be
the
other,
the
the
other
attribute
name.
I
think
it
was,
I
think,
centos
or
someone
had
suggested
app.version
and
then
app
dot.
I
think
you
said
short
short
version.
F
D
B
We
said
it
makes
sense
so,
regarding
the
api,
so
the
log
record
data
model
for
events.
The
discussion
hasn't
happened
last
week
it's
happening
today.
Somebody
from
the
ebpf
team
is
joining
the
log
sig.
B
So
I
think
there
is
only
a
debate
about
whether
the
name
will
remain
as
a
high
level
top
level
field
or
the
name
should
be.
You
know
just
been
attribute
and
last
time
in
this
meeting
we
discussed
that
you
know.
Maybe
it's
okay,
either
ways
from
our
perspective.
B
You
know
we
could
define
a
semantic
convention
for
the
name.
That
is
odd
enough
that
you
know
people
are
unlikely
to
use
it.
So
with
with
that,
I'm
wondering
you
know
what
the
next
step
would
be.
You
know
before
on
the
sdks
start
using
the
data
model,
would
it
be
defining
the
apis?
If
so,
you
know,
would
it
be
just
one
api
and
for
recording
an
event
and
nothing?
Last
time,
john,
you
mentioned
maybe
one
more
to
include
an
exception.
C
So
you're
asking
sorry
because
I
was
just
approving
the
the
pr:
are
you
asking
what
what
changes
that
we
as
a
group
want
to
to
make
specifically
okay,
now.
B
Basically,
we
want
the.
B
The
different
sdks
of
the
client-side
languages-
javascript-
maybe
you
know,
java
for
android
and
the
ios.
To
start
I
mean
we
also
have
to
define
what
are
the
different
events
we
want
to
capture.
We
want
to
define
semantic
conventions.
You
know
we
could
start
with
those
things.
First,
too,.
B
In
parallel,
if
we
could
agree
on
the
apis,
then
these
languages
need
to
implement
those
apis,
define
those
they
declare
those
apis
and
implement
those
apis.
Then,
on
yes
using
those
apis,
they
would
then
implement
this
event.
Capture.
C
And
that's
what
I
suggest
we
do
is:
let's
go
in
with
requirements
because,
like
it's
still
early
days,
I'm
part
of
the
npm
like
ebpf
group
as
well.
It's
still
early
days
for
their
requirements
for
events,
but
we
we
should
go
in
with
just
like.
We
can
have
a
data
model.
Everything
propose
if
we
want,
but
like
really
what
they
need
from
people
like
us
is
our
requirements
like
the
first
thing.
If
we
go
to
the
log
sig
that,
like
t
ground
is
going
to
ask,
is
okay,
but
why
do
you
want
events?
C
C
So
we
should
have
that
list
very
explicitly
like,
for
example,
I
assume
that
one
of
the
things
we'd
like
to
capture
an
event
as
an
event
would
be
like
user
navigation
in
a
page
or
in
an
app
right
or
perhaps
all
the
way
down
to
like
a
button
was
was
clicked
or
someone
pinched
to
zoom
or
user
interactions.
C
I'm
guessing
I'm
not
an
expert
in
rum,
but
I'm
guessing.
There
are
more
events
than
just
that,
and
so
we
should
just
literally
list
them
out
and
just
say
here
are
things
we
want
to
turn
into
events,
let's
build
a
list
and
then
for
each
describe
specifically
the
kind
of
metadata
or
information
that
needs
to
be
captured
with
it.
C
I
would
start
with
with
just
listing
like
even
before
that
was
like
just
literally
listing
like
here's
like
10
examples
of
things
we
want
as
events
just
to
start
the
conversation
because,
like
in
the
the
evp
npm
group,
the
events
requirements
are
strictly
for
npm,
not
not
the
general
ebpf
use
cases
like
they
have
their
own
requirements
around
like
hey.
C
I'm
guessing
that
some
of
the
things
that
we're
going
to
come
up
with
is
this
should
be
an
event,
and
particularly
actually
in
the
npm
group
like
t
grind
and
others
are
going
to
say
just
make
that
a
log
like
that's
more
of
a
log
than
an
event.
So
we
should
go
into
the
requirements.
So
we
can
drive
the
data
modeling
and
apis
from
there,
but
I
suggest.
C
H
Okay
in
the
planned
document,
we
have
like
a
bunch
of
events
and
accessories.
E
D
There
are
a
few
different
examples
for
browser
events
and
there's
one
at
the
bottom
for
ebpf.
C
Javascript
error
window
load-
nice.
Okay,
perfect,
I
think
like
this
is
really
what
we
need
to
to
go
chat
with
with
tigran
them.
If
we
haven't
already.
C
Yeah
yeah,
so,
let's,
let's
I
you
know,
we've
got
some
time
now
so
like.
Why
don't
we
just
start
expanding
the
list
a
little
bit,
even
if
we
don't
have
to
fill
in
the
schema
or
desired
data
model
for
them
like?
Let's
just
literally
get
the
list
of
like
things
that
we
think
should
be
events,
we
can
fill
them
in
then
later.
D
I
G
I
would
say
for
mobile
events,
there's
a
whole
bunch
of
lifecycle,
things,
at
least
in
android.
I
guess
there's
are
more
spans.
This
is
not
necessarily
events,
but
there's
also
kind
of
changes.
G
C
Quick
question
for
screen
navigation
just
to
clarify.
Does
this
mean
like,
within
the
context
of
an
app
like
moving
between
different
sort
of
pages
in
the
app
okay.
B
C
Okay,
yeah,
we
can
come
back
another
quick
question
and
I'm
probably
repeating
something
we've
discussed
in
the
past,
and
I
apologize
for
that.
We
talk
about
mobile
events.
I
I
presume.
Eventually
we
have
designs
that
this
could
be
used
for
like
desktop
applications
right
on
a
desktop
or
a
laptop
in
like
windows
or
mac
os.
I
kind
of
assumed
that
we
would
use
the
same
like
for
most
cases.
We
we
would
the
way
we
were
modeling
mobile
apps.
We
would
also
use
for
for
desktop
applications.
C
Is
that
what
we're
thinking
so
so
in
the
case
of
like
the
app.namespace
or
or
these
mobile
events?
I
kind
of
assume
it's
more
like
these
are
actually
like
app
events,
as
opposed
to
browser
events.
Is
that
how
most
people
are
thinking
about
it
or
should
do?
We
think
we
should
keep
those
use
cases
between
mobile
and
desktop
very
distinct.
B
Now
there
are
only
two
other
browser
apps
now.
What
os
there
are
none
is,
is
an
orthogonal
property
right,
whether
the
app
is
running
on
a
desktop
or
app
is
running
on
a
mobile
okay.
So.
C
F
B
C
Yeah-
and
we
can
always
separate
those
right
because,
like
what
I
mean,
it's
based
on
feedback,
let's
try
and
combine
them
and
then
because,
like
if,
for
some
reason
like
I
don't
know,
requirements
on
windows,
which
is
one
of
the
few
that
supports
both
that
somehow
those
need
to
be
separated.
We
could
create
a
separate,
separate
class
later
for
click
events.
B
It
is
not,
it
is
not
an
event,
it
is
queried
on
demand,
yeah.
E
G
C
G
B
Okay,
I
think
if
it
is
just
an
initial
list,
I
think
this
is
good
enough.
A
G
A
Good
with
the
comments,
this
is
ariel
right.
D
D
I
have
a
question
about
that,
so,
like
the
spans
are
gonna,
be
so
does
that
mean
that
we
would
be
generating
a
new
trace
for
I'm
like?
Would
those
be
just
like
processed
as
traces?
Then.
G
G
This
is
where
things
get
super
tricky,
because
when
you
click
that
button
it
could,
it
could
make
a
screen
transition
happen
right
and
that
causal
relationship
is
something
that
would
be
is
very
interesting
to
be
able
to
capture
because
screen
transitions
can
happen.
For
other
reasons,
so,
like
I
think
things
start
getting
really
tricky
in
here
is
all
I'm
getting
all
I'm
kind
of
getting
at,
but
things
that
have
a
time
are
often
very
nicely
modeled
as
spans
and
spans
also
capture
causality
in
some
sense
which
logs
cannot
and
events
cannot.
G
So
I
think
we
have
there's
some
tricky
things
in
here
around
the
modeling
of
this
stuff
and
especially
since
you
might
get
screen
transitions
that
are
happening
not
due
to
some
triggering
event
they
happen,
or
are
they
not
to
be
a
user
event?
It
could
be
from
something
else
anyway.
So
I
just
want
to
call
out
that
I
think
this
is
actually
more
complicated
than
than
as
soon
as
you
start
thinking
about
it
deeply.
It
gets
complicated.
D
Yeah,
I
definitely
have
like
a
lot
of
questions
around
this
area
like
one
of
them
is
is
is
like
is
like
spans
spans
through
of
like,
through
the
the
three
existing
like
sdks,
like
there's,
they're
sampled,
right
like
you
have
to
so
it's
like
what,
if
you
wanted
to
like
capture,
does
that
mean
like
it
would
be
capturing
that
both
metrics
and
and
spans.
G
C
G
Not
going
to
be
generating
enough
data
here
that
I
think
it
makes
sense
to
sample
okay,
I
think,
if
there's
any
sampling,
it
would
be
something
that
might
take
place
at
the
session
level
like
you
might
just
have
like
some
number
of
sessions.
You
actually
want
to
capture
in
some
number
of
sessions.
You
don't,
but
I
don't
think
at
the
individual.
I
think,
if
you're
trying
to
capture
a
session
we
shouldn't
be
trying
to,
I
think
it
would
be
a
mistake
to
stamp
to
remove
and
filter
out
some
settings.
C
Agreed
yeah,
I
would
roll
a
dice
if
you
are
going
to
sample
and
roll
the
dice
when
creating
the
session
or
deciding
to
sample
the
session
rather
and
a
session
that
is,
sampled
has
all
sample
spans
and
you
just
ignore
other
sessions
or
just
capture
everything.
It
really
I
mean
for
a
small
customer
capturing
everything
is
probably
the
way
to
go.
C
D
Yeah,
I
mean
so
this
the
sampling,
the
session,
that's
another
topic,
and
so
I
think
it's
at
some
point
maybe
like
we
can
think
about
that
for
next
time.
But
you
know
so
we
I
think
you
know
like
there
are
certain
types
of
data
that
you
want
to
collect
for
all
all
sessions
in
certain
certain
that
you
may
maybe
want
to
sample
that
session.
D
So
I
think,
like
last
time,
I
mentioned
the
use
case
of
of
like
the
session
replay
which
which
that
means
that
like,
if,
if
no,
if
let
me
say
if
I
say
this
correctly
so
like,
if
depends
on
the
use
case
right,
I
mean
there
are
certain
things
that
you
would
want
to
know
like
that
are
happening
across
all
users
and
certain
things
that
you
might
want
to.
Just
just
do
like
a
certain
sample
of
sessions,
and
why
would
you
then
sample
sessions?
D
But
then
you
also
want
to
know
like
how
long
do
these
these
transitions,
or
these
events
like
aggregated,
how
you
know,
how
do
they?
You
know
how
kind
of
what
durations
or
performance
they
have.
C
G
We
could
you,
could
I'm
thinking
out
loud
a
little
bit
here,
but
you
could
make
a
choice
when
the
session
begins
to
either
capture
all
the
spans
to
capture
just
the
timing
metrics
around
the
spans
or
capture
nothing
at
all.
So
there's
actually
kind
of
three
approaches
you
might
do,
because
the
timing
metrics
are
on
the
spans
is
going
to
be
much
much
less
data
that
needs
to
be
transmitted
versus
the
full
span
information.
G
G
I
guess
I
shouldn't
mention
these
things
that
are
going
to
even
make
things
more
complicated
than
they
already
are,
but
but
it's
worth
like
at
least
bringing
up
as
something
to
ponder.
B
It
also
depends
on
whether
the
causality
can
be
determined
in
all
the
different
programming
languages
right
like
what,
if
it
is
not,
it
is
possible
on
ios
but
not
on
android
what,
if
it
is
possible
on
mobile,
but
not
in
browser,
so
that
could
bring
some
inconsistency.
A
C
Of
these
that
only
work
on
one
like
I,
for
example,
it's
possible
that,
like
maybe
the
on
ios
and
android,
you
can
determine
if
the
app
has
been
closed,
but
maybe
only
on
android.
You
can
determine
if
it
was
through,
like
a
switch
to
a
different,
app
event,
but
not
a
close
event.
For
example,
I
don't
know
if
that's
actually
accurate,
but
but
yeah
there
will
be
cases
that
are
better.
Some
os's
have
more
support
than
others.
C
G
G
So
there
and
clearly
doesn't
make
any
sense
at
all
for
a
browser,
so
they're
they're,
the
three
and
we
haven't
even
started
talking
about
react
native
or
flutter,
or
those
sort
of
kind
of
hybrid
models,
like
the
shape
of
the
data
that
you're
able
to
capture
for
these
different
things
actually
varies
tremendously
between
each
platform.
D
C
We
should
generally
have
opinions
about
it.
I
think
like
we
should.
We
should
have
a
list
that
says
like
like,
because
we're
effectively
defining
the
specification
that
then,
is
going
to
be
implemented
by
like
the
javascript
group
and
or
sorry
by
the
the
swift
language
group
here
in
the
java
language
group
like
we
should
tell
them
like
the
these.
These
categories
of
of
things
should
be
cat
should
be
captured
as
a
span.
These
categories
should
be
captured
as
a
metric.
C
If
there
are
any,
these
categories
should
be
captured
as
an
event
and
in
some
cases,
maybe
there's
going
to
be
duplication
like
this
is
an
event,
but
also
you
should
have
a
time
series
metric
about
this.
C
Those
are
possible,
but
we
should
definitely
have
opinions,
because
if
we
don't,
then
I
mean
a
the
maintainers
of
language.
Six
are
going
to
be
very
grumpy
with
us,
because
now
we're
making
them
decide
and
b
end
users
are
going
to
be
even
more
grumpy
because
they're
going
to
say
what
the
heck.
I
can't
process
this
data
because
this
thing
is
an
event
coming
in
from
ios
and
it's
a
time
series
from
android
and
now
I
can't
make
sense
of
it
properly.
G
You
mentioned
something
there
morgan
that
I
actually
would
like
to
push
on
a
little
bit.
I
don't
think
any
of
this
instrumentation
that
we're
talking
about
here
should
be
maintained
by
the
same
people
who
are
maintaining
the
sdks.
I
think
this
is
a
very.
I
think
this
is
something
that
should
use
our
apis,
but
I
think
it
should
be
a
separate
concern.
Much
like
we
have
the
java
instrumentation
repository
with
all
of.
C
G
G
But
I
think
that
I
think
that
the
at
least
having
done
written,
android
instrumentation
now
for
the
past
six
months,
like
it's
a
super
different
thing.
It's
a
completely
different
skill
set
and
knowledge
base
than
writing
client
and
server
instrument
or
writing.
Http
instrumentation
and
server
instrumentation.
It
just
everything,
looks
totally
different.
G
But
the-
and
the
other
thing
I
wanted
to
comment
on
is
that
we
will
want
to
think
a
little
bit
about
what
can
be
kind
of
captured
automatically
like,
for
example,
on
android.
We,
like
you,
can
just
do
auto,
instrumentation
and
essentially
just
register
a
bunch
of
call
lifecycle,
callbacks
and
capture
a
whole
bunch
of
data,
but
not
everything
you
can't
capture
you
can
capture
screen
like
loading
and
being
torn
down,
but
you
can't
capture
the
transitions
between
screens
automatically
and
so
they're.
G
Part
of
what
we
probably
need
to
think
about
is
what
are
things
that
could
be
done
automatically
without
the
user
having
to
write
any
of
their
own
code,
aside
from
just
like
initially
initializing
some
library,
and
what
are
going
to
be
things
that
we
need
to
provide
apis
so
that
the
user
can
do
that
work
and
because
they
have
that
knowledge.
One
case
that
we've
run
into
very
repeatedly
at
splunk
is
what
it
means
for
an
app
to
be
started
like
what
is
the
app
startup
time.
G
G
The
application
developer
is
going
to
have
to
define
for
themselves
and
we're
going
to
need
to
provide
apis
to
help
them.
Do
that
and
some
of
these
things
we
are
going
to
be
able
to
capture
automatically,
probably
like
network
changes,
and
things
like
that,
where
you
can
just
register
listeners
in
your
instrumentation
library.
I
G
I
B
Yeah,
I
think,
once
we
are
closer
to
stabilizing
the
spec
set
of
things.
You
know,
I
think
we
could
start
participating
in
the
respective
language
sects
and
then
work
on
some
of
these
things.
B
So
so
going
back
to
the
next
steps,
morgan.
So
with
these
events,
you
know
once
we
present
them
to
the
log
seg.
Let's
say
they
reach
to
some
conclusion:
whether
to
keep
the
name
or
move
it
as
an
attribute.
That's
the
only
pending
thing.
B
Interacting
with
the
the
language
sex
right
to
how
do
we
take
it
forward
there
like,
unless
we
like?
Like
john
mentioned,
you
know,
the
implementation
will
have
to
be
a
separate
library
for
run
specific
use
cases.
C
Yeah
so
there's
there's
two
sort
of
paths
here
so
there's
events
and
let's
keep
that
one
to
the
side
for
a
moment
and
then
there's
the
core
rum
requirements
we
have
from
the
various
languages
to
john's
point.
Yes,
this
will
be
done
two
different
groups,
but
those
separate
groups
don't
exist
yet
so,
let's
just
for
the
moment
incorrectly
clump
that
together
just
call
them
the
language.
Sigs,
yes,
it'll
be
they'll,
be
split
out
eventually,
so
we
have
requirements
around
rom
right
about
the
the.
C
In
addition
to
events,
just
like
the
actual
metadata
and
things
we
want
to
capture
the
the
I
don't
know,
if
we've
any
requirements
around
like
new
apis
that
need
to
be
exposed
to
users,
we
might
but
there's
like
the
core
run
requirements
that
we
will
need
to
to
basically
push
via
the
spec
with
those
language
groups.
So
the
way
that'll
work
is
we
merge
all
of
our
spec
work.
C
We
get
it
done
and
then
we
work
with
the
language
groups
that
exist
today,
for
javascript,
for
browsers
and
and
for
swift
and
for
java,
and
probably
eventually
for
net
and
and
basically
show
them
our
requirements
and
start
working
towards
the
path
to
actually
implementing
these.
In
parallel.
C
There's
the
event
stuff
right
and
so
the
event
stuff
requires
us
to
align
with
the
log
sig
and
requires
us
to
align
with
the
ebpf
group
and
and
define
how
events
will
be
formally
modeled,
and
that
will
similarly
then
get
pushed
down
via
the
spec
to
other
groups
within
open
telemetry.
So
they
can
implement
that.
B
Yeah
yeah,
maybe
yeah.
It
was
more
than
what
I
asked
for,
but
I'm
confused
because
defining
the
apis
is
a
requirement
for
the
language
sex
to
even
start
on
the
events.
C
That
is
correct,
yes,
and
and
just
keep
in
mind
where
we
are
with
like
we're
gonna.
I
assume
pursue
this
through
the
logs
group
of
people,
even
though
events
may
end
up
being
distinct
from
logs.
I
think,
if
I'm,
if
I'm
correct,
that
that's
the
way,
these
conversations
are
trending,
just
that's
a
good
place
to
have
those
those
meetings
and
conversations
so
yeah.
I
mean
we'll
need
to
come
up
with
a
definition
for
for
what
an
event
is
right-
and
that's,
I
think
someone
mentioned
martin
or
yourself
mentioned-
that
that's
going
to
happen.
C
I
think
today
or
next
week
at
the
log
sig
and
that
will
then
get
pushed
down
via
the
spec,
as
I
mentioned
to
all
of
the
different
like
language.
Sigs,
keep
in
mind,
of
course,
like
the
event
stuff,
the
the
the
concept
of
an
event
right
events
like
apis
and
things
and
data
models
for
events.
Those
will
likely
be
implemented
across
all
language
sigs
and
the
collector,
whereas
our
rum
specific
requirements
would
be
a
subset
of
all
language.
Six.
C
Like
they're,
probably
I
mean
in
full
time
this
will
happen,
I'm
sure,
but
like
in
the
short
to
medium
term,
I'm
guessing
that
rum
will
not
have
a
lot
of
requirements
that
are
implemented
by
the
go
sig.
I'm
guessing,
there's
not
a
lot
of
go
client
applications
out
there.
As
far
as
I
know,
and
so,
but
go
will
need
to
implement
certain
event
things.
I'm
sure,
I'm
certain,
if
only
just
for
the
evpf
work.
D
Do
we
do
we
need
to?
We
need
to
wait
for
the
the
events
spec
to
be
finalized
before
we
can
start
working
on
the
api.
C
Not
for
building
prototypes
and
things,
but
but
you're
you're
pointing
out
something
that
I
think
is
very
good
and
that's
that's.
There's
the
rum
specific
parts,
as
I
mentioned,
there's
the
things
that
we
depend
on
events
for
the
rum
specific
parts.
The
timeline
is
really
on
us
and
the
language
maintainers
right.
As
long
as
we
get
it
merged
into
the
spec,
then
we
can
work
with
the
language
maintainers
to
get
them
to
produce
it.
I
will
point
out
the
language.
C
Maintainers
are
very
much
very
extremely
busy,
but
but
that's
a
thing
that
we
can.
We
can
at
least
drive
ourselves.
I
would
not
be
surprised
if
the
events
work.
I
could
be
wrong,
but
I
would
not
be
surprised
if
that
would
take
a
little
longer
because
there's
more
stakeholders
who
now
need
to
agree
right
because
for
events
we
need
the
the
people
working
on
network
performance
monitoring
to
agree.
We
need
the
people
working
on
logs
to
agree.
I'm
guessing
one
or
two
other
open.
C
So
we
should
certainly
build
build
prototypes
and
we
should
decide
if
the
sort
of
prototypes
or
alpha
versions
that
we
want
language
maintainers
to
work
on
if
they
should
take
a
dependency
on
a
also
like
a
sort
of
event
prototype
or
if,
in
the
short
term,
we're
just
gonna,
ignore
the
events
work
until
it
actually
comes
to
fruition.
G
C
G
Things
or
spans,
we
should
probably
design
that
api
independent
of
how
we
actually
end
up
modeling
the
data
under
the
hood,
and
then
we
can
map
to
that
modeling
and
tweak,
if
there's
things
that
are
really
incompatible
but
like
having
something
that
is
a
really
app
developer.
Centric
api
that
can
be
used
for
doing
these
things
is
going
to
be
really
important
and
not
kind
of
have
the
tail
wag.
G
B
So
could
you
point
us
to
I
mean
I
I
maybe
I
I
can
go
over
the
android
repo
you
that
you
are
shared,
so
there
were
only
primarily
two
apis
right,
one
to
record
generic
event
and
another,
including
an
exception.
G
Right
but
then
we
all
well.
We
also
have
another
thing,
which
is
basically
a
span
with
a
specific
name
called.
We
call
it
a
workflow,
although
that's
not
even
the
official
name.
I
don't
even
know
what
the
official
name
is.
It's
kind
of
a
working
working
name,
which
is
kind
of
a
business,
a
timed
business
thing
where
stuff
happens,
and
so
that's
not
an
event.
That's
a
like
a
named
like
a
custom
named
span,
essentially,
which
you
can
obviously
use
the
bear
open
telemetry
apis
to
to
do.
B
Are
we
meeting
next
week?
Okay,
are
you
planning
to
join
next
week.
D
So
yes,
I'm
planning
to
join
next
week.
Okay,.