►
From YouTube: 2021-12-21 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
B
C
E
A
D
C
Yeah,
so
for
people
who
may
not
be
in
the
know,
which
is
probably
maybe
only
tyler
and
anthony,
there's
been
some
so
we've
we've
started
up
a
new
special
interest
group
for
client
telemetry
in
the
past
couple
months,
aka
from
real
user
monitoring,
so
the
purpose
of
which
is
to
understand
how
to
do
monitoring
of
what
we
call
client,
client-side
applications,
so
mobile
applications
and
web
applications
for
the
most
part,
although
there's
potentially
other
clients
like
fat
clients
on
the
desktop,
we
haven't
really
been
talking
much
about
that,
because
we
think
it's
a
fairly
small
space
but
at
any
rate,
one
of
the
main
one
of
the
big
things
that
we
need
in
rom
monitoring.
C
C
Those
other
examples,
transition
screen
transitions
can
be
that
also,
although
they
generally
may
be
modeled
better
by
spans,
there's
other
things
that
are
kind
of
background
events
that
happen,
like
the
network
changes
from
being
wi-fi
to
5g
or
whatever.
That
might
be
so,
there's
a
definitely
a
need
to
be
recording
this
kind
of
telemetry,
which
is
point
in
time
set
of
attributes
and
usually
a
name,
so
the
name
would
be
like
touch
event
or
network
changed,
or
something
like
that.
C
So
our
hope
has
been
that
we
would
be
able
to
model
use
model
these
using
the
log
data
model
and
probably
provide
a
specialized
api
that
we
would
need
to
specify
around
how
to
how
to
record
these
and
then
expose
them
to
users
for
recording
business
events
like
user
logged
in
or
something
like
that,
so
there's
a
whole
class
of
these
point
in
time.
Events
that
are
extremely
important
to
the
client-side
monitoring,
inflammatory
story.
C
So,
as
I
said,
our
hope
has
been
that
we
would
use
the
log
data
model
for
this
with
a
custom
api.
So
then
the
task,
then,
is
to
figure
out
whether
we
can
fit
this
data.
The
shape
of
this
data
into
logs,
which
the
answer
is
obviously
yes,
because
the
log
data
model
is
so
wide
open.
You
could
put
anything
in
it,
I
mean
you
could
put
spans
in
it.
We
don't
I
mean
you
could
probably
put
metrics
in
it.
C
You
could
put
anything
into
the
log
data
model,
it's
completely
wide
open,
but
that
doesn't
necessarily
mean
it's
the
right
thing
to
do
like
we
don't
put
spans
into
logs
right,
I
mean
we
need
to
make.
We
need
to
figure
out
whether
this
is
the
right
thing
or
whether
the
log
data
model
needs
tweaking
or
something
like
that
around
and
to
make
in
order
to
make
this
work,
if
it's
what
we
want
to
use.
So
my
main
concern
at
this
point
is
that
the
log
data
model
has
calcified
and
solidified
extremely.
C
I
would
not
say
quickly,
but
in
a
way
that
has
basically
not
involved
enough
people
to
understand
all
the
use
cases
for
it.
For
example,
this
client-side
telemetry
use
case
is
extremely
important
and
there
is
basically
we're
at
the
point
now
where
the
logs
say,
and
I
think
tigran's,
probably
you
speaking
for
the
log
saying,
is
saying
well,
the
data
model
is
what
it
is
it's
finalized,
so
we
can't
change
it.
So
if
you
want
to
use
it,
you
have
to
figure
out
how
to
make
your
stuff
fit
into
it.
At.
C
D
C
C
There
was
the
questioning
of
the
name
field
in
the
data
model,
which
would
be
very,
very
useful
for
rum
style
events,
because
these
are.
This
is
something
that,
from
at
least
a
user
perspective,
both
on
the
kind
of
analysis
and
visualization
side,
but
also
on
the
api
and
recording
side.
These
events
generally
have
something
that
fits
feels
very,
very
much
like
the
name,
and
so
that
is
why
I
have
said
that.
Yes,
there
is
a
use
for
this.
I
think
it
would
be
a
good
thing
to
have.
Yes,
of
course,
we
could
make.
C
We
could
always
create
an
attribute
attribute
for
this,
but
is
that
the
right
answer
I
don't
know
so,
there's
I
think,
there's
one
more
kind
of
tricky
thing
with
saying
that
events
and
logs
are
essentially
exactly
the
same
thing,
and
that
is
that,
like,
let's
just
take
the
case
of
a
mobile
application,
mobile
application
is
going
to
have
application
logs.
So
it
will
be
like
your
typical
application
logs
where
an
app
developer
is.
You
know,
logging,
miscellaneous,
debug,
information
or
whatever
it
might
be.
C
C
So
if
we
make
them
into
if
we
use
just
the
standard
logging
sdk
for
this
we'll
end
up
having
to
pull
them
all
apart
somewhere,
whether
it
be
in
the
collector
or
whether
it
be
in
a
back
end,
and
it
feels
like
that
is
certainly
possible,
but
it's
also
probably
relatively
expensive
to
have
to
pull
that
stuff
apart
and
then
put
it
back
together
into
separate
payloads
and
send
it
to
separate
back
ends
or
wherever.
D
D
The
level
of
details
maybe
is
different
right,
like
maybe
when
you're
saying
the
mobile
application
has
application
logs,
which
are
maybe
describing
what
happens
inside
the
application
versus
the
user
initiated
actions
which
you
want
them
to
be
to
be
recorded
as
something
that
you
call
an
event
to
me.
These
are
the
same
thing
that
we
all
can
call
an
event.
D
Are
they
different
kinds
of
events?
Probably,
should
they
be
completely
different
streams
of
telemetry?
I
doubt
that
that
should
be
the
case.
Should
they
be
filterable.
I
think
yes,
you're
right,
you
probably
want
to
be
able
to
somehow
differentiate.
Maybe
you
want
to
show
them
differently
in
the
ui.
D
So
I
don't
think
that's
a
very
different
so
that
they
need
to
be
very
different
streams
of
telemetry.
One
goes
to
one
backhand,
the
other
goes
to
another
backhand
and
then
I'm
maybe
scrambling
to
figure
out
how
to
maybe
correlate
these
two
things,
because
I
somehow
separated
them
at
the
source
of
generation.
C
D
C
Exact
arguments
could
be
used
about
spans,
like
literally
the
exactly
the
same
argument
can
be
used
for
spanzing.
We
have
deliberately
chosen
to
separate
those
things
right.
If
you
really
want
to
see
the
spans
that
are
generated
from
a
particular
touch
event
you
really
want
to,
and
yet
we
don't
really
have
a
way
to
correlate
from
a
log
to
a
span.
We
can
only
go
the
other
way
right.
So
I
think
that
same
argument
is
it's
like.
D
I
think
it
there
is
no,
but
if,
if
you
think
that
the
differences
are
sufficient,
then
fine,
let's
make
a
proposal
an
auth
which
says
this
is
a
new
signal
type
explain:
why
is
it
and
how
it
is
different
from
from
the
log
records,
and
maybe
we
work
on
that
right
so
far,
my
understanding
is
that
they
they
fit
in
the
log
record
nicely
enough.
They
are
in
a
way
a
kind
of
a
log
record
in
my
opinion,
so
we
can
try
to
model
them
as
log
records.
D
I
think
it's
possible
to
do
now,
whether
it's
the
right
thing
to
do
or
no
that's
that's
kind
of
very
subjective
right.
So
if
you
think
that
that's
a
wrong
thing
to
do,
I'm
fine
make
a
proposal.
Let's
review
it:
let's,
let's
discuss
that
if
we
assume
that
they
fit
in
the
log
record,
if
we
assume,
let's
say
make
that
assumption
that
it's
a
good
enough
fit
to
put
the
user-initiated
events
into
log
records,
then
I
think
we
can
do
that
it's
possible
technically
and,
in
my
opinion,
the
name
field
is
nothing
really
special.
D
If
you
want
to
record
that
the
identifier
typically
in
javascript,
you
have
this
identifier
of
an
event
right,
the
button
was
clicked
or
whatever
happened.
If
you
want
to
record
that-
and
you
do
want
to
record
that-
certainly
there
is
a
very
good
attribute
name
that
you
can
invent
for
that
right.
You
can
call
it
rom,
dot,
event,
type
or
run.event,
name
or
or
ram.browser
event
or
whatever
right,
something
that
is
clearly
rum
specific
and
then
that
allows
you
to
do
that
splitting
of
the
telemetry
into
two
different
destinations.
D
C
D
So
why
not?
Why
so
you're
talking
about
the
specific
use
case
right,
let's
stay
on
that.
If
you
want
to
generalize,
we
can
do
that
as
well.
But
let's
talk
ram
events,
you're
saying
name
is
a
very
useful
information
to
record
for
ram
events
right.
So
let's
record
it
what's
what's
the
problem,
why
can't
we
do?
Why
can't
we
record
it
as
an
attribute.
C
C
D
D
C
C
D
C
C
D
C
What
I'm
saying
is,
I
think
we
need.
I
think
events
are
extremely
important
and
I
think
events
have
structure
in
which
the
name
is
is
probably
the
most
important
piece.
Like
often
an
event
is
just
a
name
and
a
timestamp,
and
that's
really
often
that's
all
you
get
because
a
user,
because,
especially
when
you're
talking
about
a
business
event
generated
by
like
a
like
a
checkout
event
or
something
that
happens
like
it's
often
just
that's.
The
only
thing
they
want
to
record
is
this
thing
happened
with
this
name
at
this
time.
C
D
Okay,
are
you
happy
with
the
current
definition
of
the
name
field,
the
way
that
it
it
describes
what
should
be
recorded
there?
It
says
some,
I'm
I'm
quoting
short
low,
cardinality
event
type
that
does
not
contain
varying
parts.
Name
describes
what
happened
yeah.
I
think
that's
exactly
the
way
it
would
be
used
in
in
run
events.
B
So
I
I
have
a
couple
questions
just
around
this
discussion,
the
first
one
for
john.
It
seems
like
your
conception
of
them
being
the
same
type
means
that
they
have
to
be
in
the
same
data
stream.
Don't
we
have
concepts
of
multiple
like
multiple
events
could
go
to
be
routed
to
different
locations?
Could
that
helps
alleviate
that
kind
of
problem
where
the
things
that
are
rum
events
specifically
generated
by
rums
are
are
delivered
to
the
rem
endpoint,
but
it's
still
an
an
event.
G
We
don't
have
anything
like
that
in
any
of
the
existing
sdks,
so
also
just
to
challenge
this
there's
a
buffering
kind
of
concern
and
like
a
loss
of
data
concern
and
an
overload
concern
like
one
of
the
ideas
behind
isolating
different
signals
is
I
can
control
like
the
amount
of
quality
that
each
signal
gets
like.
I
can
sample
traces
differently
than
metrics
than
logs
and
there's
different
expectations
of
what
they
are.
So
one
of
the
questions
here
with
events
is
that
I'm
asking
is
effectively.
G
Does
it
deserve
to
be
lifted
out
as
a
concept,
not
for
any
reason
like
related
to
modeling?
We
could
model
it
exactly
the
same,
but
does
it
deserve
to
be
lifted
out
just
so,
you
have
those
kind
of
controls,
first
class
like
where
I
can
kind
of
control
my
my
event,
stream
separately
in
a
very
clear
way
to
a
user.
Is
that
a
thing?
That's
expected
you
know,
so
I
can.
I
can
set
up
sampling
of
events.
I
can
set
up
the
quality,
the
the
amount
of
memory
it
takes
to
do
this
signal.
D
G
C
But
event
is
not
a
span
right
because
it's
a
point
in
time.
It
does.
H
C
Doesn't
doesn't
work
because
those
span,
those
spans
that
you're
modeling
a
session
might
be
hours
long
and
they
may
never.
They
never
never
end.
If
the.
If
the,
if
the
user
drops
off
the
network,
which
is
going
to
happen
very
often
in
mobile,
it
does
not
make
sense
to
model
sessions
as
spams,
because
they
they
often
will
never
end
or
cannot
be
reliably
ended,
and
then
the
events
on
them
would
never
get
reported
or
would
be
reported
hours
later.
H
A
streaming
sdk
would
perhaps
alleviate
those
concerns,
but
that's
another
discussion
here
nor
there.
I
I
think
the
important
point,
though,
is
that
the
idea
of
a
provider
for
the
signal
being
able
to
be
configured
differently
from
another
provider
from
the
signal
in
the
same
application
gets
to
josh's
concern.
G
Not
not
really,
I
mean
we're
putting
a
lot
of
complexity
on
the
user
if
this
is
like
a
common
use
case
that
this
happens
all
the
time
and
we're
forcing
the
set
of
multiple
providers.
Do
you
really
expect
people
to
do
this
in
practice
and
like
to
say
this
is
a
great
api
for
what
I'm
doing
like
I
just
I
feel
like
that's.
G
G
Our
spans
are
modeled
as
a
holistic
thing
that
gets
written
once
when
the
span
is
done.
They
are
not
written
as
a
start
span
and
n-span
event
when
I've
done
client-side
monitoring
in
the
past.
If
I
wanted
to
have
a
span,
I
would
write
start
span,
n-span
events
and
I
would
not
ever
expect
to
have
to
see
the
n-span
event,
as
john
said
like,
because
things
go
out
because
of
the
way
we've
modeled
spans.
G
H
G
In
the
protocol
where
this
works,
like
again
we're
like
span,
requires
a
time
stamp
in
the
protocol,
which
means
you
have
to
have
a
start
and
an
end.
Stop
like
you
can't
stream
events
in
our
current
span
protocol
is
what
I'm
saying
like
if
you
change
the
protocol.
Yes,
I
buy
it
but
like
when
I
talk
data
model,
I'm
talking
our
protocol
and
and
we
can't
write
spans
as
events
right
now.
That's
just
not
a
thing.
C
I
want
to
say
this
event
happened,
and
then
these
three
network
requests
showed
up
as
a
result
and
there's
a
very,
very
strong
causal
relationship
between
the
user
clicking
a
button
and
three
network
requests
being
made,
and
we
don't
currently
have
a
way
to
model
that
we
have
a
model
the
way
to
model
the
span
causes
logs,
but
not
the
log
causes
spans
or
log
causes
other
pieces
of
telemetry
to
exist,
and
we
or-
and
we
also
don't
have
a
way
to
say
this
log
slash
event-
is
correlated
with
these
metrics.
That
happened.
C
This
is
the
thing
that
might
point
us
to
events,
not
beings.
As
long
as.
D
We
could
do
that,
but
I
I
I'm
worried
that
we're
going
to
end
up
reinventing
duration-less
spans
traces
of
duration-less
spence,
like
in
a
sense
that
that
will
be
events
which
have
causal
relationships
right.
That's
that's
what
you
could
model
as
duration,
less
spans
and
a
trace
of
those
spans
becomes
sort
of
that
that
what
you're
describing
right.
C
C
I
mean
these
are:
these
are
like
real
life
use.
Cases
like
we
actually
have
this
problem
today
in
rum
is
like
we
don't
have
a
way
to
do
this,
this
causal
relationship,
and
it's
actually,
we
have
to
model
them
right
now
as
zero
duration
spans,
except
that
not
like
the
data
model,
doesn't
really
support
that
we
kind
of
just
have
to
say
the
start
and
end
time
or
right
now,
or
we
start
it
and
end
it
immediately,
which
means
that
it
has
actually
like
a
couple
nanoseconds
of
duration
rather
than
zero.
E
From
the
from
the
javascript
side,
like
I
live
mainly
in
the
web
space
and
having
a
duration
of
span
is
exactly
what
I
have
to
do
to
get
events
out
the
door
so
yeah.
It
really
is
a
case
of
in
terms
of
the
start
and
end
that,
from
my
perspective,
they're
two
completely
separate
spans.
E
I'm
having
complications
at
the
moment,
because
I
have
no
parent
span
that
I
can
easily
allocate
to
that.
But
I'm
working
around
that
to
try
and
group
them
together
without
creating
a
parent
span
that
never
gets
ended
because
you
know
someone
closes
the
browser.
The
end
event
may
not
get
triggered
and
get
sent
out,
which
means,
as
josh
likes
to
point
out
you
end
up
with
this-
can
incomplete
spans,
which
you
don't
want.
So.
C
Yeah,
there's
a
there's,
a
side,
minor
complication
and
that
zipkin
spans
can't
have
zero
duration
just
period.
They
have
to
have
at
least
a
duration
of
a
microsecond
which
is
extra
annoying
because
you
end
up
with
all
of
these
one
microsecond
duration
spans,
which
makes
your
metrics
all
look
very
strange
when
you
generate
metrics
off
of
them.
But
anyway,
that's
probably
that's
a
zipkin
specific
thing
and
not
something.
I'm
incredibly
concerned
with.
C
So
I'm
not
I'm
not
sure
where
to
head
from
here:
zero
duration,
spans
events,
events
meaning
like
realm
events,
meaning
zero
duration
spans
so
that
we
can
have
causal
relationship
feels
like
an
acceptable
answer
to
me.
It's
not
any
prettier
than
using
logs
as
the
model
like
they're,
both
kind
of
shoehorning,
something
into
a
model
that
wasn't
really
built
for
the
use
case,
but
maybe
either
of
those
cases
is
better
than
trying
to
invent
a
new
signal.
At
this
point,.
D
Well,
I
guess
yes,
but
sufficiently
efficiently
right.
Let's
say
you
can
model,
but
it's
probably
going
to
be
not
very
efficient.
If
you
try
to
do
that.
Take
metrics,
for
example,
john
is
right.
You
can
put
them
in
log
records,
but
it's
probably
not
going
to
be
very,
very
efficient
to
model
histograms
using
log
records.
Well
then,.
C
G
Yeah
but
I
was
gonna
just
gonna
mention,
there's
two
signals
that
I
think
are
coming
that
people
are
trying
to
work
on
proposals
for
one
is
on
profiling.
So
that's
that's
a
good
call
out
the
other.
One
is
multivariate
time
series
as
an
alternative
to
metrics,
so
there's
a
there's,
a
prototype
on
that
one.
That's
actually
pretty
darn
cool
using
apache
arrow,
where
effectively
you
invert
the
relationships
of
signals
so
that
you
have
multiple
data
points
per
one
attribute
set.
G
F
Yeah
always
like
bringing
new
signal
has
a
lot
of
consequences
like
the
exporters
receivers
and
otlp.
All
the
processors
in
collector
need
to
be
created
for
handling
new
signal,
but
actually,
when
I
think
about
signals,
the
interesting
thing
or
dimension
is
relationship
between
data
points
like
with
metrics.
We
have
time
series
with
tracing.
We
have
this
direct,
I
cycle
graph
with
locks,
we
have
just
let's
say
each
edge
lock
might
be
considered
separate.
So
I
think
that
for
me,
this
is
what
really
discerns
the
signals.
D
B
That
way,
we
don't
have
to
rehash
this
discussion
again
on.
Is
it
something
that's
there
if,
because
I
think,
that's
actually
really
insightful
and
if
we
could
say
something
like
hey,
if
the
relationship
can't
be
modeled
by
the
current
set
of
signals,
then
maybe
we
need
to
talk
about
anyone
like
that's
the
hail
mary.
D
B
That's
that's
again
what
what
I'm
saying
is
like
if
your
data
model
not
not
physic
like
the
the
way
you
lay
out
the
data
but
more
along
the
lines
of
this
is
related
to
this,
like
this
unit
is
related
to
this.
In
some
shape,
like
he
said,
you
know
the
acyclic
graph
for
for
traces,
it's
not
that
every
event
is
independent.
Every
trace
is
independent.
It's
it's
forms
a
graph.
B
That's
a
good
ch!
That's
a
good
opportunity
to
make
a
new
signal
type.
If
rums
don't
map
to
any
of
our
current
models
of
either
independence,
time,
series
or
graph,
then
maybe
it
is,
and
that
would
be
an
opportunity
to
start
capitalizing
on.
B
D
I
don't
know
if
we
will
be
able
to
come
up
with
generic
generic
recommendations
like
that,
but
but
I
I
think
we
have
a
work
group.
We
have
a
rom
or
what
do
you
call
a
client
side?
Work
group
right.
I
think
you
guys
are
the
experts
and
you
spent
weeks,
if
not
months,
already
thinking
about
this.
So
I
don't
think
we
outside
that
work
group
are
qualified
to
make
this
call
for
you.
D
Ultimately,
it's
all
your
your
decision.
You
need
to
decide
whether
you
want
to
model
them
as
logs,
whether
it's
good
enough
or
zero
duration
spans,
maybe
or
something
else
right
it.
I
think
it
needs
to
be
your
decision.
We
can
maybe
have
an
opinion,
but
I
think
it's
going
to
be.
Your
call
eventually
are
zero.
Zero
duration
spans
legal
in
otlp
in
otlp.
Yes,
I
don't
think
anybody
anything
prevents
that
from
being
legal.
Let
me
look
up.
C
If
that's
the
case,
I
think
the
the
structurally-
and
I
think
this
again,
I
think
I
agree
aaron,
that
this
is
a
very
strong
insight
that
the
relationship
between
the
signals
or
between
the
palette-
I
don't
even
the
telemetry
items-
I
don't
know
the
units
of
telemetry.
That
relationship
is
the
thing,
that's
really
important
and
I
think
events
in
the
real
user
monitoring
space
in
the
client-side
telemetry
space
model.
C
B
C
Think
the
and
I
wonder
whether
I
don't
know
anything
about
the
networking
space,
where
I
think
these
events
are
also
important,
but
I
don't
know
if
the
ebpf
group,
if
anyone
here
has
been
involved
in
that,
but
whether
the
events
there
might
model
better
as
spans
in
order
for
this
causal
relationship
to
be
modelable.
I
don't
know
I
don't
know
anything
about
that
space
at
all.
D
The
ebpf
case
is
a
bit
different.
They
have
extreme
efficiency
requirements.
They
are
generating
such
a
large
volume
of
events
that
they
may
need
to
have
a
stateful
way
of
representing
these
events,
so
that
you
don't
have
to
transmit
the
information
that
we
typically
encoding
the
resource
over
and
over
again,
so
that
actually
may
be
heavily
influenced
by
the
performance
requirements,
how
you
model
the
bpf,
but
you're
right.
That's
that's
also
another
discussion
that
is
not
very
active
right
now,
but
it's
going
to
happen.
C
So
I
have
a
so
just
as
a
follow-on
if
the
the
client-side
group
decides
that
we
should
model
these
zero
duration
spans,
which,
in
my
head
at
least
feels
more
structurally
useful,
would
and
I'm
looking
for
opinions
here.
Would
we
want
to
introduce
a
new
api
for
client-side
events,
or
would
we
want
to
extend
our
existing
tracing
api
to
facilitate
recording
zero
duration
expands.
C
D
D
C
C
Well,
I
think
it
would
be
as
simple
as
adding
just
adding
a
method
to
the
tracer
that
says
record
record
event
or
something
like
that.
That
would
be
a
name
and
some.
H
Activities,
I
think,
in
the
go
api
and
sdk,
it
could
be
done
by
adding
an
option
to
the
start
span
to
end
immediately
and
then
have
the
sdk
respect
that
to
create
a
span,
that's
ended
as
soon
as
it's
done.
Perhaps
other
sdks
could
do
something
similar.
C
C
Api
for
client-side
events,
client-side
telemetry,
which
will
also
I
mean
spans,
are
also
an
important
thing
in.
I
want
to
choose
a
little
weird
it'll,
be
like
the
hey,
johannes
you're.
Not
really
should
be
the
like.
It's
going
to
be
a
combination
of
spans
and
events
with
also
the
potential
I
mean,
there's,
probably
not
a
huge
amount
of
metrics
to
be
recorded
in
the
client-side
telemetry.
C
B
C
Impossible,
but
a
little
unusual,
so
yeah,
my
question
is
more
just
like
what
do
people
think?
What
do
people
feel?
What
are
your
feelings
about
tweaking
an
api
versus
building
a
new
api
for
for
the
clients
on
these
cases.
B
So
one
of
the
like
the
difficulty
here
is
right:
if
you
tweak
an
api,
that
is
something
that
every
language
is
going
to
have
to
go
and
support
and
make
changes.
So
that
is
a
large
change.
So
if
that
is
a
small,
like
addition,
it's
multiplied
very,
very
widely
that
I
think
is
probably
like.
B
The
use
case
is
if
this
is
something
that
does
make
sense
to
put
it
everywhere
in
every
language,
then
I
think
that
might
be
okay
if
we
can
keep
it
small
versus
if
it
is
a
fairly
heavy
change,
but
it's
only
going
to
be
implemented
like
twice
like
in
javascript
and
maybe
maybe
java
then
or
like
javascript
java
and
swift.
Maybe
I
don't
know,
then
maybe
it
makes
a
lot
more
sense
to
do
that
way.
Honestly,
I
think
just
take
your
best
judgment
right.
C
I
will
say
there's
at
least
one
martin
I'll,
let
you
speak
for
new
relic,
but
I
know
new
relic,
for
all
their
languages
essentially
has
an
event
api
built
into
their
sdk.
It's
not
not
the
open
source
ones
with
their
legacy
ones,
so
this
would
be.
I
know
something
that
at
least
new
relic
and
I
suspect,
honeycomb,
but
I
don't
know
that
much
about
the
hong
kong
data
model,
but
would
also
this
kind
of
zero
duration
event.
Zero
duration
span
as
a
way
to
model
user
driven
events.
G
G
That
sort
of
thing
like,
especially
if
you
have
alerts,
and
that
sort
of
thing
on
these
fan
things
that,
like
there's,
that
we
should
make
sure
that
the
model
accounts
for
the
fact
that
these
aren't
normal
spans
in
some
fashion,
so
it
should
be
called
out
in
some
fashion,
even
if
zero
durations
allowed
like
we
don't
want
to
confuse
those.
Basically,
events
with
actual
spans.
E
I
While
we're
on
this
topic,
I
just
had
one
other
thing
to
throw
out
there
and
correct
me.
If
I'm
wrong,
we
have
a
few
wrong
people
on
the
call.
I
I
get
the
sense
that
I
don't
know
that
perhaps
the
current
open,
telemetry
sdks
are
are
maybe
a
little
bit
heavy
for
the
browser
and
for
the
rum
use
case
and
that,
if
we're
thinking
about
whether
you
need
a
new
api
or
possibly
like
an
alternative
sdk
or
whether
we
should
add
the
stuff
into
the
current
sdks,
maybe
that's
something
that
should
be
factored
into.
C
I
don't
think
it's
been
a
big
issue.
It
definitely
hasn't
been
a
problem
with
android
like
the
volume,
and
I
think,
in
the
browser
too.
The
volume
of
spans
that
are
generated
is
actually
relatively
small
compared
to
what
you
would
expect
from
a
kind
of
a
server-side
service
implementation.
E
E
Yeah
and
and
for
for
android
you're
talking
about
client
side,
so
you
have
I'm
going
to
worry
about
delivery
time
for
web.
It's
a
huge
issue,
for
example,
like
I,
I'm
microsoft,
application
insights
once
it's
minified
code
and
zipped
it
it's
currently
around
40k
using
the
tracer
web
example
that
already
exists
in
in
open
telemetry
javascript.
E
J
Yeah
I
want
to
act
with
that.
Like
we
had,
we
had,
we
had
feedback
on
exactly
that
from
other
customers.
C
C
Well,
I
mean,
I
think,
that
I
think
that,
as
tigran
said-
and
I
agree
with
like
the
client-side
group-
should
come
with
a
recommendation
and
we
need
to
talk,
we
need
to
figure
out.
We
need
to
talk
to
multiple
people,
not
just
me
and
martin,
to
figure
out
whether
zero
duration
spans
is
a
better
way
to
model
air
vents,
and
then
I
think
it
probably
would
if
we
decide
that
that
is
the
right
way
to
go
recommending
a
new
spain.
D
Right,
thank
you
all
and
we'll
probably
see
each
other
after
the
holidays.
Yes,
sir.