►
From YouTube: 2022-01-26 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
D
C
C
Okay,
well,
I
think
we
can
get
started
ted
welcome
back.
Did
you
want
to
continue
the
discussion
from
last
week.
C
There
is
what
what
I'm,
what
we're
hoping
to
do
is
create
an
ulta
proposal
for
a
client-side
data
model,
and
I
started
a
draft
in
a
google
doc,
and
so
what
I
would
like
to
do
is
just
maybe
just
go
through
like
the
options
that
I
listed
there
and
have
a
discussion
around
see
if
anyone
has
opinions
one
way
or
another
or
another,
and
we
can
also
go
through,
we
discussed
one
of
the
ideas
was
to
use
zero
duration
spans
to
represent
events
that
happen
in
a
client
session,
and
we
put
together
a
table
of
examples,
so
we
can
go
through
that
through
those
as
well.
C
Let
me
just
let
me
actually
start.
First,
I'm
gonna
share
my
screen
and
let
let's
first
start
with
with
the
proposal,
because
I
just
wanted
to
outline
the
options
that
I
can
think
of
they
have
so
let
me
share
my
screen.
C
Okay,
so
what
I,
what
I
did
is
I
listed
the
the
options
that
I
can
think
of,
and
I
didn't
at
this
point.
I
did
not
fill
in
the
proposal
yet
because
I
I
feel
like
I
want
to
have
when
I
have
a
agreement
among
this
group
before
I
fill
something
in
so
let
me
just
go
through
the
options
first,
so
so
we,
I
think
we
all
agree
that
in
in
a
client
session,
there
are
things
that
happen.
C
Certain
events
that
happen
that
we
are
trying
to
figure
out
how
to
capture
and
so
the
the
options
that
I
could
think
of
is
originally
we
thought.
Okay,
maybe
you
can
use
logs
because
the
specification
says
that
basically,
events
are
the
same
as
logs.
C
C
So
these
spans,
I
think,
would
be
all
tied
together
by
having
an
a
session
session
id
attribute
so
kind
of
like
the
bigger
the
higher
level
like
session
trace.
Recession
is
represented
by
the
session
id
attributes
and
and
individual
events
would
be
spans
that
that
basically
have
their
own
their
all
the
root
spans
or
most
of
them
are
root
spans
with
their
own
trace,
ids,
but
the
way
they
tied
to
each
other
is
through
the
the
session
id
attribute
and
then
then
option
three
would
would
be.
C
The
idea
with
option
three
is
that,
if
you
think
of
the
session
itself
as
a
as
a
span,
then
then
everything
could
just
basically
go
from
there
and
we
could.
Potentially,
we
could
have
like
a
single
trace
id
for
the
whole
session.
C
There
would
be
then
child
spans
for
events,
or
they
could
be
even
like
the
the
span.
Events
on
the
session
session
span
now
there
are
some
challenges
with
that,
like
like
the
fact
that
these
session
sessions
are
very
long,
so
I'm
not
sure
like
if
that's
even
possible,
but
I
wanted
to
list
that
as
an
option.
C
The
four
apps
for
both
option
was
some
combination
of
of
logs
and
spans.
You
know,
I
think
it's
if
you,
when
we
look
at
the
examples
of
of
those
events.
I
think
it's
clear
that
some
of
them
could
be
represented
as
as
spams
or
would
make
definitely
makes
sense
as
fans,
but
maybe
some
of
them
would
make
more
sense
as
logs.
C
So
maybe
that
would
be
a
combination.
The
question
is:
how
do
we,
you
know?
How
do
you
would
you
determine
which
one
to
use
and
then
the
last
option
I
just
want
to
throw
it
out
there
for
for
having
a
complete
picture,
which
is
having
just
a
completely
new
signal,
and
that
goes
back
to
the
otep
from
last
summer,
which
was
to
introduce
like
around
like
a
new
signal
type
of
for
ram
events.
C
A
I
have
a
small
comment
on
options
with
the
one
with
the
session
the
session
span
yeah.
So
there's
a
there's
a
maybe
a
twist
on
that
which
we
could.
E
Have
the
session
start
be
a
zero
length,
zero
duration
span,
that
is,
the
parent
of
all
of
the
spans
that
happen
or
whatever
the
root
spans,
the
rest
of
the
root
spans
that
happen
during
that
session.
I
don't
know
that
it's
a
great
idea,
but
I
just
wanted
something
that
popped
into
my
head
as
a
possibility.
E
A
E
Some
something
that
jumps
into
my
head
when
I
look
at
this
is
sort
of
like
like
a
middle
ground,
between
option
four
and
five,
rather
than
necessarily
introducing
a
whole
new
signal
with
new
event
types
and
all
of
that
stuff,
you
could
add
a
concept
of
a
session
to
the
context
right.
We
have
a
context,
object
that
can
store
all
different
kinds
of
contexts
in
it.
E
E
So
it's
you
know,
you
would
still
end
up
with
something
like
you
know,
a
session
id
attribute
on
spans,
probably,
but
it
would
be
a
place
where
you
could
actually
store
attributes
and
information
about
the
session
itself
and
without,
while
keeping
it
a
separate
concept
from
like
a
trace
or
a
span,
so
that
back
ends
could
potentially
do
something
different
with
it
deal.
Perhaps
with
the
fact
that
starting
and
certainly
ending
a
session
is
probably
nebulous
so
so
just
want
to
throw
that
out.
There
is.
C
B
Sounds
sounds
reasonable,
so
the
concept
of
session
in
the
context
could
be
it's
an
orthogonal
topic
right.
It
could
be
present
in
each
of
the
options
mentioned
here.
E
Yes,
yes,
correct
as
it's
just
another
scope
right
that
you
could
just
create
a
pointer
to
from
logs
and
spans
and
then
use
logs
and
spans
to
store
the
actual
event
data
depending
on
what
it
is.
B
So
in
option
three
martin,
you
mentioned
that
events
could
simply
be
span.
Events
on
that
one
session
span.
E
Effectively
right
like
you,
they
would
just
be
events
right
like
logs,
probably,
but
you
have
the
same
way
you
can.
If
you
look
at
the
logging
model,
you
can
associate
logs
with
a
trace
context
right,
so
you
can
say
these
logs
occurred
in
the
context
of
this
span,
which
is
like
moving
past.
The
original
context,
concept
of
span
events
right.
We
now
have
just
like
we.
E
We
have
span
events
that
are
literally
stuck
onto
the
span
as
far
as
our
data
model,
but
we
also
have
logs
that
can
point
to
a
span
context
and
say,
like
I
occurred
inside
the
concept
context
of
this
span,
you
could
also
have
those
logs
say
I'm
inside
the
context
of
the
span,
I'm
also
inside
the
context
of
this
session.
B
I
think
I
think
what
is
confusing
is:
are
those
individual
events
in
the
session
represented
as
events
on
the
session
span?
Are?
They
are
separate
spans
in
the
same
trace
and
each
event
is
in
a
separate
span.
E
I
think
I
think
there
would
be
options
there.
So
when
we
just
had
tracing,
we
had
a
concept
of
a
span
event
that
was
literally
part
of
the
spanned
data
model.
And
what
is
nice
about
that?
Is
you
don't
have
to
repeat
information
right
like
you
have
all
the
spans
are
stored
in
arrays,
so
they
don't
each
need
to
have
a
copy
of
like
the
span
id
on
them.
So
there's
like
a
just
a
data
efficiency
data,
modeling
thing
when
it
comes
to
our
protocol.
E
You
can
talk
about,
but
the
problem
with
having
a
something
called
a
span
event
is
you
have
events
that
are
not
occurring
inside
the
context
of
a
span
right,
and
so
we
added
logs,
which
are
just
events
at
that
point.
It's
kind
of
weird
to
have
some
events
live
over
here
as
like
something
glued
onto
this
span
and
other
events
floating
around
over
there
purely
based
on
whether
or
not
a
span
context
happens
to
be
around.
E
So
we
added
a
span
context
structure
to
the
logging
model
so
that,
if
you
wanted
to
just
have
all
of
your
events,
come
out
as
logs
and
have
the
ones
that
were
occurring
when
they
were
occurring
inside
the
context
of
a
span.
Just
point
back
to
that
span
context.
You
can
do
that
with
our
login
model.
E
We
haven't
gotten
too
deep
into
that,
because
logging
is
still
in
this
experimental
stage,
but
you
might
say
like
in
the
future
that
span
events
become
deprecated
and
anytime
someone
records
a
span
event.
It's
actually
just
gets
recorded
as
a
log
with
a
pointer
to
his
fan
context.
E
So,
following
that
same
model,
you
could
have
a
session
context
and
that
session
has
an
id.
It
has
a
bunch
of
attributes
attached
to
it
structured
object,
and
then
you
could
point
other
things
that
occur
within
that
context.
Like
a
span
can
occur
within
that
context,
but
you
could
also
have
events
occurring
within
that
context.
C
So,
do
you
think
that
we
would
have
to
introduce
like,
like
a
session
id
attributes
or
like
field
on
on
the
log.
E
Probably
that
that
would
be
the
way
to
do
it,
unless
I
I
only
say
probably
because
I
just
I
feel
like
conceptually.
That's
that's
the
way
you
would
do
it
when
it
comes
to
like
an
efficient
wire
protocol.
E
C
E
Yeah
that
that
would
be
the
other
way
to
do
it,
the
only
difference
there
is
now
you
have
a
concept
of
a
span,
that's
being
used
a
little
bit
differently
from
the
way
we've
been
using
spans
right,
and
I
don't
know
if
that
has
like
practical
implications
conceptually,
I
don't
think,
there's
anything
wrong
with
it.
It's
more
just
like
the
practical
implications
of
like.
E
Like
you
know,
sessions
are
long
running.
They
can.
They
have
a
higher
chance
of
not
ending
right,
like
the
user,
just
closes
their
browser
or
or
walks
away
or
something,
and
if,
if
nothing
in
our
system,
if
our
system
can't
tell
whether
it's
trying
to
model
a
session
versus
trying
to
model
a
span,
are
there?
Are
there
just
like
practical
implications
there?
That
would
make
make
life
better
if,
if
you
had
it
as
a
separate
concept,
but
I
think
conceptually,
like
all
the
practicalities
aside,
I
don't
actually
see
yeah.
C
D
E
D
Would
have
one
question
regarding
if
we
modeled
that
as
spam,
don't
we
have
any
problems
with
web
applications
where
that
are
loaded
from
the
server
so
where
each
page
is
loaded
again
from
the
server
and
requested
from
the
server?
Can
we
carry
over
a
session
or
represent
it
as
spam?.
E
Like
if
we
were
tracing
like
standard
normal
tracing
ideas,
all
the
way
from
a
session
through
to
the
back
end
and
into
databases,
etc,
we
would
end
up
with
a
very
strange,
like
the
same
trace
id
being
shown
up
on
the
back
end
traces
of
span
traces
over
and
over
and
over
and
over
again,
which
would
be
very,
which
would
be
very
unusual.
I
think,
and
probably
not
something
that
anyone
would
want.
So
I
think
it's
actually
a
bad
idea,
so
I
rescind
my
suggestion.
E
E
E
You've
now
have
exponentially
more
data,
you're
shoveling
into
that
one
one
thing,
and
if
you
had
a
session
concept,
you
have
the
opportunity
for
there
to
be
some
some
loose
coupling
there
so
yeah.
I
think.
A
E
Is
the
same
but
the
same
objection
from
the
from
the
analyst
perspective
as
mine
from
the
operator
perspective
right,
it's
and
I
think
the
the
the
one
thing
I
just
heard
is
yes,
it's
totally
true
that,
like
sessions
persist
across
page
reloads
and
like
other
like
set
the
way
sessions
persist,
are
different
from
the
way
traces
persist.
At
least
right
now.
Yeah,
when
we
are
looking
at
async
stuff
like
messaging,
is
another
place
where
traces
kind
of
are
async.
E
C
Yeah
yeah,
we
actually
so
we
talked
about
it
internally
at
new
york
about
and
considered
using
links
for.
If
we
had
like
a
session
that
consists
of
many
many
traces
and
the
traces
like
can
can
go
to
back
end
backhand
spans,
so
you
have
like
you
know
like,
for
example,
like
an
xhr
client
span.
C
That
goes,
you
know,
makes
a
call
to
the
back
end
and
you
have
a
completely
separate
trace
like
when
you're
analyzing
the
session
and
separately
from
analyzing,
the
the
back
end
trace,
like
you,
could
have
a
link
from
the
backend
trace
to
the
session
to
the
session
trace.
C
I
also
actually
wanted
to
get
get
opinion
on
this
as
well
like
there's.
There
is
some
thinking
that
essentially
sessions
like
user
client
sessions
are,
could
be
modeled
the
same
as
tracers
they're,
just
you
know
and
so
like.
Why
not
just
use
the
same
same
like
user
experience,
but
I
disagree
with
that,
but
I
wanted
to
get
like
everyone's
thoughts
on
that
too.
E
I
I
personally
I
try
to
be
wary
of
the
what
I
call
the
found
art
approach
to
to
data
modeling
in
some
cases,
if
something
is
semantically,
the
same
like
events
like
we
just
have
events,
and
so
I
get
nervous
when
we
start
maybe
churning
out
new,
separate
data
structures
to
represent
events.
E
It's
kind
of
why
I
want
span
events
to
get
deprecated,
it's
like
if
we
have
logs
well
like,
let's,
let's
deprecate,
let's
just
put
all
the
events
in
one
spot,
please
and
have
one
way
of
modeling
them,
but
when
it
comes
to
something
like
a
session,
it's
true
that,
if
you
squint
at
a
transaction
you
can
say
like
well,
a
session
is
sort
of
like
a
transaction
turned
on
its
side
or
something
it's
true.
But
it's
also.
It's
like
it
seems
less
intentional
and
maybe
just
more
more
convenient.
C
E
So
but
again.
E
Persist
across
page
reloads
and,
like
other,
they
persist
in
ways
that
are
different
from
the
way
a
transaction
persists.
We
really,
I
think,
are
trying
to
scope
transactions
down
to
a
a
synchronous.
E
Operation
like
a
a
trace
is
something
where
a
bunch
of
resources
are
being
held,
open
in
synchronicity,
right,
they're,
being
all
chained
together
and
that's
not
that's
not
what
a
session
is
right.
Right,
yeah.
C
Yeah,
I
think,
though,
the
reason
it
comes
out
comes
up
sometimes
is
like
when
we're
discussing
these
different
use
cases
and
using
spans
to
represent
these
other
concepts
like
we're
talking
about
maybe
using
a
span
to
represent
a
session
we're
talking
about
maybe
using
a
span
to
represent
an
event.
C
You
know
so
so
now
spans
were
originally
intended
as
to
represent
like
a
like
a
they're
they're,
intended
for
a
specific
purpose
like
for,
like
a
part
of
a
trace,
yeah.
E
A
live
operation
when
you
have
a
machine
consuming
resources
somewhere
to
do
a
specific
task.
That's
that's
a
span
and
when
this
machine
is
consuming
resources
to
do
this
specific
task-
and
it's
doing
it
because
this
other
machine
is
telling
it
to
do
it.
And
it's
doing
that,
because
this
other
machine
is
telling
it
that
machine
to
do
something.
E
That's
that's
kind
of
what
we
see
as
a
transaction
right,
because
sorting
that
specific
problem
out
is
like
a
really
big
deal
in
the
kind
of
you
know,
internet
service
programming
that
we
do
right,
like
that's,
just
the
interaction
between
resources
being
used
and
the
the
requests
being
made
to
consume
them
and
all
of
those
happening
concurrently.
That's
just
like
where
operators
are
trying
to
untangle
a
hair
ball
like
all
the
time.
E
That
that
focuses
on
that
and
yeah,
I
personally
think
it.
It
would
be
better
to
differentiate
some
of
these
contact
other
concepts
if
they
don't
fit
in
cleanly,
which
is.
B
E
You
know
zero,
zero
duration.
Spans
are
a
thing
that
that
pop
up
occasionally
in
open
telemetry
when
we're
modeling
things
and
to
me
it's
like
always
a
smell
like
it
always
is
like
okay,
we
we
have
something
that
we
need
here.
We
need
some
kind
of
structured
thing,
but
it's
it's
obviously
not
not
an
operation.
We're
talking
about
so.
C
Yeah
I
wanted
to
call
it
call
it
out
also
in
relation
to
the
option
two
which
we
have
discussed,
which
is
like
using
spans
to
model
events
and
the
reason
that
the
reason
we're
considering
this
is
because,
like
we
need
causality
like
we,
you
know
we
want
to
be
able
to
say,
like
this
event,
potentially
triggered
something
else.
C
So
we
would
get
that
with
spans.
But
but,
like
you
said
like
it
to
a
certain
degree,
it
seems
a
little
bit
wrong
to
me
because
now
you're
you're,
saying
you're
saying
like
some
like
I'm
ingesting
spans
and
some
spans
are
spans,
but
other
spans
are
not.
Some
specs
may
not
be
spent
yeah
and
and
like
that's,
not
the
there's.
Not
a
stance
that
like
open
telemetry
has
has
taken
right,
like
open
telemetry
has
said
like
logs
are
the
same
thing
as
events,
so
I
feel
like
that's.
C
Okay,
but
like
from
the
model
events
as
spams
like
it
doesn't
seem
like
it
was
intended
that
way.
E
It
yeah
it
wasn't.
I
will
say,
though,
the
it's
the
only
place
where
we
have
a
a
causal
relationship
right,
like
events,
don't
have
any
kind
of
happens
before
or
causal
relationship
other
than
their
time
stamps,
but
they
can
be
scoped
into
context
right.
You
can
say
this
event
happened
in
this
span
context.
You
could
just
as
easily
say
it
happened
in
the
context
of
this
session,
so
you
can
contextualize
events.
E
I
don't
I
feel,
like
I
don't
understand
the
rum
model
enough
to
know
why
or
where
you
would
have
events
that
have
like
a
direct
causation
chain
that
that
weren't
being
modeled
as
like
part
of
just
regular
spans
like
an
operation
like
I'm
doing
something,
and
so
I
called
this
function
and
it
started
doing
something,
but
I
I
literally
don't
don't
know
so,
I'm
sure,
there's
stuff,
so
an
example
would
be
the
user
touches
a
button
on
their
screen,
which
triggers
a
whole
series
of
things
that
happen.
E
That's
an
event
like
it
takes
basically
zero
time
right
and
then
it
triggers
a
whole
bunch
of
things.
So
if
we
were
to
model
that
as
a
log,
we
lose
the
causality
aside
from
just
the
fact
that
we,
it's
probably
a
single
threaded
model
and
there
happens
to
be
time-
that's
moving
forward,
which
you
know
is
a
possible
way
to
approach
it,
but
it
does.
E
We
do
lose
information
in
that
in
that
modeling,
but
so
the
way
we
do
this
today
and
again,
this
is
not
saying
there
isn't
more
to
rum
because
we
have
not
really
dug
into
gui
programming,
but
the
way
you
would
do
that
today,
like
let's
say
it's
the
checkout
button.
E
You
know
so
they're
gonna
click
this
button
and
then
that's
going
to
trigger
a
bunch
of
http
requests
and
stuff,
and
then
you
know
a
bunch
of
state
might
change
on
the
screen
as
a
result
of
all
of
that,
the
way
we
would
model
that
today
is
where
they
click
the
button.
E
You
would
start
a
trace
to
represent
the
transaction
of
of
checking
out
and
then
the
the
click
the
button
would
be
the
the
first
event
in
the
in
the
trace
right.
So
you
start
a
trace
and
add
an
event
to
it.
E
But
we
so
you
know,
having
worked
on
the
instrumentation
side
of
things
for
non,
you
end
up
with
exactly
the
same
issue
right,
because
everything
ends
up
being
async.
You
essentially
end
up
with
a
zero
duration
or
a
microsecond
duration
span.
That
starts
the
transaction
starts
the
transaction
operation
like
in
because
of
because
it
just
kicks
off
a
bunch
of
async
stuff
and
it
ends,
and
the
user
is
then
able
to
interact
again.
E
There
isn't
really
like
the
user,
doesn't
have
any
there's,
no
long-running
thing
from
the
user's
perspective,
but
also
and
the
same
thing
when
you
get
an
ace
like
a
you're,
an
async
server
and
you
start
a
transaction
start.
A
trace
like
the
first
span
just
ends
immediately,
and
yet
it
ends
up
being
this
weird
zero,
like
microsecond
duration
span,
that
is
the
parent
of
a
whole
bunch
of
asynchronous
operations,
which.
E
A
particularly
great
model
for
how
things
are
working
today,
yeah
yeah,
so
for
clarity,
the
the
the
clicking
of
the
button
would
be
an
event
right,
because
I
agree
that
has
like
no
time
the
the
span
you
would
be
starting
would
be
something
like
checkout
right,
and
that
would
start
when
they
hit
the
button,
and
it
would
end
once
everything
had
returned
from
the
server
with
like
a
big
thumbs
up
and
like
checking
out
is
complete.
E
You
know
like
this
transaction
is,
is
finished,
and
that
would
be
the
end
of
that
span
way
over
there,
and
then
things
like
http
requests
and
stuff
would
be
children
of
that
span
because
that's
like
a
whole
transaction,
the
checkout
transaction,
does
that.
Does
that
make
sense.
B
E
Not
the
way
it
works
in
your
async
http
servers,
though
right
you
don't
keep
a
single
span
open
for
that
whole
duration
of
the
actual
operation
until
the
response
goes
back
to
the
user.
In
most
cases
I
mean
end
users
have
to
model
that,
because
automated
instrumentation
can't
can't
generally
do
that
for
them,
but
they
do
they
do
do
it
when
that's
the
thing
they
want
to
model.
So
you
know,
for
example,
when
lyft
wants
to
model
hailing
a
ride.
E
E
You
know
they
have
a
span
that
models
that
and
all
the
chunks
of
stuff
that
happen
under
that
are
are
sub
spans
and
that's
because
they
need
to
model
how
long
that
whole
transaction
takes
how
far
into
it
before
someone
hits
cancel,
for
example,
because
a
lot
of
money
is
lost
when,
when
that
transaction
or
parts
of
it
start
taking
too
long.
So
you
end
up
with
that.
Our
normal
thing,
like
the
user's
phone,
drops
off
the
network
and
you
never
get
that
thing
reported
at
all
because
it
never
ends.
E
That's
that
is
also
a
problem
with
with
mobile
version
of
this
is
the
fact
that
the
it's
expensive
to
send
this
data,
it's
slow.
It
has
to
go
over
the
public
internet,
it
like
they
could
just
go
into
a
tunnel
and
the
phone
could
turn
off.
You
know
like,
like
the
the
possibility
of
of
just
broken
data,
is
much
much
higher
here,
which
is
why
I
think
something
like
a
session
which
is
like
way
longer
than
even
like
order
me.
A
ride
transaction
is
super
sus
to
me.
E
E
That
we
have
this
kind
of
smaller
thing
than
a
session
which
is
like
what
you're
talking
about,
which
is
like
a
user
transaction,
a
bigger
business,
yes,
and
because
of
the
extremely
lost
potentially
extremely
lossy-
and
you
know-
we've
we've
dealt
with
customers
in
south
america,
where
the
internet
is
not
yeah.
B
E
Good
as
it
is
in
silicon
valley
or
in
portland,
because
of
that
extremely
lossy
model
or
network,
it
often
makes
sense
to
have
very
small
atomic
things
that
you
send,
rather
than
trying
to
have
things
that
are
long
and
won't
get
sent
to
land
yeah,
two
two
things
there,
one,
you
know
the
the
incremental
spans
that
represent
something
like
an
http
request.
E
You
know
those
can
go
out
the
door
before
the
parent
span
goes
out
the
door,
but
I
think
and
again
this
gets
to
like
wire
protocol
bottling
versus
conceptual
modeling,
but
you
can
have
an
event
event-based
wire
protocol
that
shovels
this
all
out
the
door
as
it
comes
right.
E
So
in
our
current
model,
what
you
would
lose
when
they
drop
off
is
you
would
have
all
of
the
subspans,
except
maybe
the
last
one
that
was
open
when
they
dropped,
and
you
would
not
have
the
that
overall
parent
span,
you
would
know
it's
there
right,
because
you
would
have
ids
on
its
subspans
all
linking
to
this
span
that
you
don't
have.
But
you
wouldn't
know
when
that
span
started.
E
You
wouldn't
have
the
attributes
that
were
attached
to
it
and
if,
instead,
we
had
a
protocol
that
just
that
didn't
try
to
do
any
kind
of
buffering,
I
don't
like
the
way
we
do
client,
buffer
and
cook
whatever
like
if
it
if
it
was
just
an
event
based
protocol
where
it
sent
start
event
ad
attribute
event.
You
know
that
kind
of
stuff
and
then.
B
E
Yeah,
just
a
streaming
total
100
streaming
model
and
then
something
on
the
other
end
is
catching
it
and
putting
it
back
together
into
some
kind
of
data
structure.
You
know
you
would
have
a
less
lossy
model.
Potentially
I
mean
you,
you
have
like
other
problems
with
that
model,
but
anyways
it's
a.
I
just
want
to
throw
that
out
there
as
like
a
wire
protocol
issue
like
that
can
be
handled
in
terms
of
a
wire
protocol.
It's
a
bit
different
than
the
conceptual
modeling
we're
doing.
B
E
Think
we
have
the
expertise
totally
hard
to
tackle
yeah,
I
think
so.
So
I
think
maybe-
and
I
think
you
bring
up
a
really
good
point.
Maybe
we
need
to
just
write
down
this
assumption
that
we're
not
going
well
either
we're
not
going
to
write
a
new
wire
protocol
for
this
yeah
we're
going
to
use.
What
we
have,
which
does
is
a
constraint
that,
on
our
on
our
data
modeling
for.
E
Ill,
it
is
a
constraint
or
we
are
going
to
tackle
a
new
wire
protocol
for
rum,
which
is
obviously
much
bigger
than
what
we've
been
intending.
E
So
so
the
reason
why
this
this
isn't
as
bad
for
transactions
as
it
would
be
for
sessions
is
it's
true
that
the
user
could
drop
before
that
overall
transaction
is
complete,
but
if
they
do
that,
then,
generally
speaking,
that
transaction
is
failed
and
unrolls
in
some
fashion
right
because
it
means
they,
they
had
some
open
connection
as
part
of
going
through
these
steps
and
and
that
gets
dropped
and
the
whole
transaction
is
put
versus
like
a
session
where
someone
could
be
like
coming
in
and
out
and
doing
all
kinds
of
other
stuff
and
reloading
the
page,
and
things
like
that.
E
So
it's
just
why
I
guess
I
want
to
point
out
why,
in
practice
it's
true,
you
might
have
a
longer
running
transaction
like
a
checkout
or
an
order,
order,
a
cab
or
something,
and
you
might
lose
some
of
that
data,
but
generally,
when
you're
losing
some
of
that
data.
That's
that's
highly
associated
with
the
transaction
itself,
failing
to
complete,
which
wouldn't
be
the
case
with
a
session.
B
E
Do
we
is
the
is
our
so.
This
does
bring
up
the
the
other
issue
of
having
to
if
we
use
logs
for
anything,
that's
actual
signal
being
able
to
making
sure
our
sdk
has
two
logging
pipelines,
one
for
actual
application
logs
and
one
for
logs
that
are
actually
drum
events,
because
those
those
data,
the
the
eventual
sources
or
destinations
for
those
data-
sorry
not
sources
destination,
for
that
data
is
most
likely
or
very
often
could
be
different.
E
I
don't
think
so,
because
all
of
that,
all
of
the
spans,
the
purpose
of
I
think
I
mean
this-
is
at
least
the
way
we're
doing
it
at
splunk.
Right
now,
for
our
is
that
all
of
those
fans
that
are
everything
that
is
being
captured
from
the
like
on
the
on
the
device
or
in
the
browser
like
that
is
the
rum
signal
is
those
spans.
E
So
now,
if
our
signal
is
going
to
be
a
mix
of
spans
and
logs,
like
some
of
that,
is
going
to
be
the
true
rum
thing
and
some
of
it's
going
to
be
diagnostics
on
the
hardware
or
some
of
it's
going
to
be.
You
know
just
standard
logging
from
your
libraries
that
you've
picked
up
from
wherever
you
get
your
libraries
from
okay.
E
In
with
the
standard
rum
data,
I
don't
think
because
we
do
probably
want
to
present
those
kind
of
events,
the
realm
events.
Things
are
presented
to
the
end
user
to
the
analyst
or
the
to
the
operator
as
something
that's
different
than
just
kind
of
blogging.
That
goes
along
with
application.
Libraries.
I
think.
B
Yeah,
it
makes
sense,
I
think,
although
you
know
we
could
introduce
an
attribute
to
distinguish
logs
from
events
on
the
log
records,
but
I
I
see
the
larger
point
that
it
could
only
be
confusing
if
there
are
two
ways
of
representing
from
events
for
for
the
endless
scenario,
but
I
think
the
concern
I
have
with
spans
is
it's
it's
so
rich
and
complex
data
structure
that
there
is
a
good
possibility
that
people
might
you
know
misuse
it
or
are
you
know,
use
it
in
ways
that
you
know
we?
B
It
can
get
difficult
later.
E
I
actually
think
the
opposite
is
true.
I
think
the
logging
data
model
is
much
as
has
much
more
flexibility
and
richness
in
it
than
the
span
data
model
and
that
people
can
use
all
the
logging
data
model,
especially
the
body
which
can
be
arbitrary
maps
of
data
like
they
could
use
that
for
anything
and
figuring
out.
What
to
do
with
that.
Information
is
much
trickier,
I
think,
than
the
span
data
which
is
fairly
simple
compared
to
log
data.
Well,.
A
E
Yeah
the
way
I
mostly
see
people
misuse
spans
and
traces
for
what
it's
worth
is
having
too
many
of
them.
The
the
most
common
thing
I
see
is
people
see
the
span
as
a
closure,
and
a
function
is
a
closer,
so
like
every
function
should
be
a
span
and
well
that's
not
conceptually
wrong.
That's
just
like
way
too
much
overhead
and
you're
better
off
with
these
coarse
grain
spans
with
lots
of
attributes
on
one
span.
E
E
If
we
don't
give
them
something
else,
john,
I
have
a
question
about
rum
events
just
for
clarity,
you're,
saying
that
when,
when
a
client
like
a
mobile
app
or
something
like
that,
like
in
today's
model
of
rom,
there
are
there
are
like
logs,
like
application
logs
that
are
totally
separate
from
from
rom
events
and
get
sent
to
to
separate
places.
E
Sorry,
an
application
developer,
wanting
to
record
an
event
which
has
something
to
do
with
the
network
changing
or
with
the
with
the
user
clicking
a
button
or
with
an
actual
like
a
checkout,
a
successful
checkout
or
something
like
that
like
I,
I
think
you
wouldn't
want
to
commingle
those
things
they're
both
important,
but
I
think
they
are
different.
I
think-
and
again
I'm
really
just
trying
to
think
about,
but
I
think
they're
of
a
different
kind.
E
That
so,
I
think
application
logging
or
I
don't
even
know
what
to
call
it,
but
that
kind
of,
like
I'm
just
logging
stuff,
that's
happening
because
somebody
wrote
a
library
that
does
logging,
I
think,
is,
I
think,
just
feels
different
of
a
kind
to
me
and
it's
not
really
a
log
level
like
I
wouldn't
want
to
log
my
my
my
checkout
successful
event
at
debug,
like
I
don't
even
think
that
makes
sense
right.
That's
that's
not
something!
That's
a
debug
or
an
info
or
a
warn
or
an
error.
E
E
E
E
End
community
learning
how
to
to
model
things
with
that
stuff
and
it's
okay,
the
actual,
like
user
interaction,
ui
events-
I
I
wonder
if,
like
that's
something
where
it's
become
super
noisy,
if
all
of
those
become
regular
events,
I
don't
I
don't
know,
but
that's
the
one
kind
of
thing
I've
heard
mentioned
that
to
me
sounds
like
something
that's
like
totally
different
than
what
what
we're
currently
modeling
in
other
areas,
like
you
know
like
like
on
the
the
server
side
on
the
other
end,
you
know
you
model
at
checkout
things
like
that,
but
you.
E
E
E
I
mean
I
mean
I
guess
that's
why
I
was
asking
like.
Is
it
just
like
a
log
level
issue?
Is
it
just
that
stuff
is
noisy,
so
you
turn
it
off
versus
it's
it's
a
different
in
in
kind
right
like
if
okay
http
was
logging,
some
like
severe
problem,
it
was
having
around
like
network
shenanigans
or
something
you'd
want
you'd
want
those
logs,
probably
right.
E
E
We
need
we
need
some
way
to
discriminate
between
all
of
like
the
the
the
initiator
of
a
particular
piece
of
the
signal,
atoms
or
in
some
way
or
another.
And
I
don't.
I
don't-
have
a
really
well
fleshed
out
understanding
in
my
head.
But
there
are
things
that
are
user
user
initiated
like
clicks,
and
things
like
that
and
they're
things
that
are
machine
initiated
like
okay,
http
logging
and
having
some
way
to
distinguish
between
those
things
feels.
E
Yeah,
I
guess
I
just
wonder:
is
it
enough
to
be
able
to
just
scan
these
events
and
have
them
have
you
know
like
you
can
use
event
attributes
to
model
all
this
stuff
to
some
degree
right
like
you,
can
have
a
event
attribute
that
signals.
It's
a
it's
a
gooey
event,
and
but
I
don't
know,
if
that's
that's
good
enough,
I
mean
the
the
one
number
one
reason
I've
been
pushing
us
to
think
really
hard
about
zero
duration.
Spans
for
events
is
the
causality
issue
like
modeling
that
causality.
C
Yeah
so,
like
I
just
kind
of
circled
back
around
to
santosh
asking,
could
we
have
spans
and
and
events
or
logs,
like
we?
We
did
this
exercise
when
we
defined
like
different
types
of
events
that
we
think
could
happen
in
a
client
session,
and
then
we
thought
about
like.
C
Could
this
event
actually
have
a
duration,
and
could
it
have
a
relationship
with
some
other
events?
So
this
is
what
we
came
up
with
like
this.
This
column
here
has
like
two
questions:
gonna
have
a
relationship
doesn't
have
more
like
about
greater
than
zero
duration,
so
some
of
them
like
a
lot
of
them,
have
no
to
both
some
of
them
have.
Yes,
I
think
it's
and
some
of
them
are
unclear.
I
think
it
depends
on
on
on
the
type
of
instrumentation.
C
So
I
think
one
of
the
challenges
might
be
like
if
he
say:
okay
like
we
might
be,
we
allow
both
spans
and
end
logs
or
events
as
logs.
Then,
how
do
you
know?
How
do
you
make
that
decision
which
one
like,
maybe
it's,
maybe
like,
maybe
some
in
in
some
environment?
You
could
capture
that
relationship
between
between
events
and
some
you
could
not
so.
E
Yeah,
I'm
willing
to
take
it
as
homework
to
to
try
to
go
through
this
list
and
see
if
I
can
present
some
like
scenarios,
some
like
scenarios
of
at
least
the
things
I
see
in
here
where
I'm
like.
E
Oh
this,
this
maps,
this
maps
cleanly
to
stuff,
we
already
got
here's
here's
an
example
versus
things
in
here
where
I'm
like.
I
I
have
no.
I
we
actually
don't
have
anything
today
that
I
could
point
you
at
that.
Would
cleanly
explain
how
to
do
this,
so
I
could
take
a
crack.
Maybe
other
people
should
should
too,
though,.
C
E
E
C
E
But
I'll
try
to
take
a
look
at
this
and
come
back
next
week
with
with
some
advice,
if
I
can,
but
I
don't
want
to,
I
feel,
like
I'm
a
being
a
bit
of
a
bull
in
the
china
shop
right
now,
just
kind
of
like
barging
in
so
I
want
to
be
cautious
of
that
as
well.
I
think
we
we're
we're
all
wandering
around
the
maze
and
we
need
the
minotaur
to
help.
E
Yeah,
okay,
I
can
at
least
make
some
infographics
of
like
looking
at
these
things
and
being
like.
Well,
here's
how
I
would
model
it
if
I
were,
if
I
were
making
a
mobile
app
today
and
then
y'all
can
be
like
that's.
E
I
that's
makes
no
sense
to
me
or
that's
that's
dumb,
and
maybe
we
can
get
somewhere
through
that,
but
I
can
at
least
identify
how
some
of
these
things
that
look
like
span
events
where
I
might
pull
it
apart
and
say:
here's
the
span
operation
and
here's
how
this
is
an
event
in
this
operation.
E
I
think
the
web
vitals
discussion,
though,
is
also
a
real
one.
That's
really!
Maybe
maybe
something
to
that.
We,
I
think,
we've
been
sweeping
under
the
rug
a
little
bit,
even
though
it
is
listed
here
that
those
things
are
basically
metrics,
like
recorded
by
the
browser
and
then
reported
like
reportable.
C
Yeah,
I
think
a
lot
of
these
things
should
be
captured
as
metrics.
That's
like
the
use
cases
you're
looking
at.
I
think
one
of
the
use
cases
obviously
is
looking
at
like
the
the
patterns
over
time
right
and
and
then
like.
Maybe
like
you
want
to
drill
in,
like
a
specific
user
session
like
to
see
what
happened
in
that
session,
and
in
that
case
you
need
to
capture
all
these
things
in
in
that
session,.
E
So
how
to
deal
with
that
from
a
metrics
perspective
is
because
we
we
would
want
to
be
able
to
look
at
a
specific
session
and
see
what
the
timings
were.
Not
just
the
aggregates
exemplars
yeah
perhaps
have
a
look
at
metric
exemplars,
because
that
that's
how
we
associate
metrics
with
traces
right
now,
for
example,
to
get
around
get
around
that
problem
in
this
case.
In
this
case,
what
would
the
exemplar
would
need
to
be
not
a
span
but
a
session
right,
and
I
don't.
I
have
no
idea
how
that
yeah,
how.
E
Yeah
yeah
weirder
you're,
not
with
with
a
span
exemplars
one
thing
you're
not
trying
to
do,
is
like
count
how
many
times
this
thing
happened
in
this
span
right,
it's
more
the
relationship
of
like
when
I'm
seeing
these
metrics
and
I'm
like
what
are
all
of
these
500
errors,
or
these
timeouts
or
like
like
I'm,
seeing
a
metric,
and
then
I
want
to
know
something
about
the
transaction
that
was
going
on,
or
maybe
the
session
that
was
going
on
when
that
happened,
being
able
to
have
a
sampling
of
spans
and
sessions
that
it's
like
well,
when
this
thing
was
marked
as
500
or
whatever.
E
This
was
the
span
that
was
open
when,
when
that
happened,
and
so
it's
a
way
to
then
link
over
and
look
at
the
tracing
side
of
things,
but
you're
not
trying
to
use
them
as
a
as
like
a
label
like
a
dimension
that
you're
modeling,
if
that
makes
sense,
yeah
the
the
big
difference
being
that
you
kind
of
that's
mandatory
to
do
it.
E
That
way,
when
you're
talking
about
a
server,
that's
getting
tons
and
tons
of
requests
when
you're
on
a
client
device,
I
mean
you're,
not
you're,
not
like
the
fact
I
mean
you,
don't
sampling
exemplars
like
every
everything
would
be
an
or
it
would
be
a
sample
example,
or
in
that
case,
so
it's
a
little.
It's
slightly
different
kind
of
yeah,
the
motivation
behind
it.
I
guess
the
question
I
would
have
is
is
when
you're
associating
metrics
with
sessions
are
you
are
you
trying
to
count
like?
E
Are
you
trying
to
like
break
break
them
out
by
session
and
that,
like
how
many,
how
many
times
did
this
event
happen
in
this
session
versus
this
other
session
versus
this
other
session?
I'm
not
I'm
not
totally
sure
that
that
you
would
do
that
in
this
case.
It's
not
events,
I'm
thinking
about
like
longest
contentful
paint
right
like
that's
like
a
in
this
particular
page
page
load.
E
But
modeling-wise,
I
don't
think
it
has
any
correlate
that
I
can
think
of
kind
of
in
backhand,
okay
observability,
but
I
could
be
wrong.
Maybe
there's
a
good
quarrel
and
I
just
haven't
been
able
to
think
of
it,
but
it's
very
different.
I
think
it's
just
maybe
the
thing
to
think
about
when
you're
thinking
about
this
relationship
with
metrics
is.
E
I
can
like
kind
of
pivot
to
looking
at
this
other
kind
of
data,
if
that,
if
that
makes
sense
so
so
that
that
would
be
a
thing
to
to
think
about,
is
it
is
it
that
I
just
sometimes
when
I
see
like
a
weird
metric
like
a
weird
value
on
a
metric,
I
want
to
then
dig
into
the
specifics
of
like
re.
I
want
to
replay
this
session,
where
that
happens,
for
example,
or
is.
C
E
I
want
to
have
like
my
alerts.
Actually
you
know
where
I
want
my
dashboard
to
be
broken
up.
This
way.
C
Anyways
anyways,
so
we
are
at
time
I
just
wanted
to.
I
just
want
to
say
like
so:
I'm
gonna
hold
off
on
the
old
tap
because
I
don't
think
we're
anywhere
near
agreement
of
like
how
we
should
model
this,
but
I
wanted
to
I
wanted
to
say
I
don't
know
how
how
much
each
each
of
you
like
has
time
to
like
think
about
this
over
the
week
but
like
I
would
like
to
continue
making
progress
and
I
actually
do
have.
C
I
do
have
dedicated
time
to
this
project
now.
So
what?
What
could
I
do
to
help
this
group
with
with
like
making
that
making
these
decisions.
D
C
E
C
E
I'm
gonna
try
to
put
effort
into
digging
into
this
model
that
you've
produced
around
these
different
kinds
of
events.
I
think
that's
that's
a
helpful
thread
for
me
to
pull
on
a
basic
prototype
would
probably
be
helpful.
I
know
it's
unfortunate
that,
like
it's,
we
have
like
at
least
three
very
different
programming
environments.
So
probably
it's
not
easy
for
everybody
to
look
at.
E
You
know
the
same
example,
but
it
might
be
helpful
to
see
an
example
of
like
a
difficult
case.
Yeah
I'm
struggling.
C
With
so
do
you
think
would
be
helpful
to
have
a
prototype
for
all
these
different
options,
or
just
pick
one
that
you
think
is
more
like
most
likely
to.
I.
E
I
think
what
might
be
helpful
is
to
create
a
small
sample
app
that
has
examples
of
some
of
the
scenarios
you're
struggling
with
right.
That
would
be
like
a
good
place
to
start,
and
then
you
could
start
with
the
approach
of
well.
If
I
just
took
what
we
have
today
at
open,
telemetry
and
just
like
glued
it
in
here
it
would.
It
would
look
like
this
so
that
that
could
be
a
place
to
start
yeah.
One
downside
is,
we
don't
have
a
logs
api
yeah?
That's
that's!
A
E
B
B
E
Of
this
stuff,
extraordinarily
difficult
to,
I
know
we
need
to
get
logs
get
logs
over
the
finish
line,
but
there
is
like
at
least
in
some
of
these
environments
like
a
way
to
capture
logs
from
like
log
for
j
yeah
yeah,
because
you
can
use
any
logging
api
that
you
want
right.
It
wouldn't
be
for
java.
I
don't
know
if
swift
and
js
have
that
feature
yet.
E
Prototype
but
yeah,
but
you
could
you
could
as
like
your
very
first
start.
You
could
just
be
like
you
know.
If
you
stick
to
like
the
existing
open,
telemetry
clients.
That
means
you
could
actually
send
that
data
somewhere
right
and
maybe
that's
like
a
good
starting
point
to
be
like
well.
If
we
yeah
this.
C
Okay,
okay
sounds
good.
Well
thanks
for
a
great
discussion
and
we
can
continue
in
slack
and
santosh
and
martin.
Maybe
I
can
send
out
an
invite
for
some
sometime
later
this
week.