►
From YouTube: 2022-03-23 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
Do
you
know
if
ted
is
going
to
join?
I
don't
know
I'm
going
to
ping
him
just
in
case
he
can
join.
D
B
And
I
I
talked
to
him
yesterday
and
he
said
he
was
he
was
sick,
so
maybe
he
still
is
okay,
okay,
okay!
Well,
let's,
let's
get
started.
B
So
I
I
put
a
few
things
on
the
agenda.
I
think
the
main
thing
just
for
an
update
to
everyone
is
that
we're
we're
still
working
on
the
on
the
draft
for
the
otap
proposal.
B
We
there
we
had
a
bunch
of
comments
on
the
first
first
revision
and
we
we
put
together
a
secondary
vision,
which
now
has
a
bunch
of
comments
as
well.
It's
linked
here
in
the
first
bullet
point.
If
you
haven't
seen
it,
please
look
at
it
and
then
so
I
the
one
thing,
the
one
thing
I
wanted
to
that.
The
one
feedback
that
I
got
that
I
think
it's
it's
missing
is
that
we
should
include
a
proposal
about
sessions
because
essentially,
essentially
this
proposal,
what
we're
proposing
is
number
one.
B
We
need
the
events,
events,
api
and
we're
proposing
using
the
log
data
model
and
the
number
two
that's
kind
of
unique
to
client
side
is
sessions,
so
managing
sessions
so
and
we
haven't-
worked
in
sessions
yet
so
I
think,
unfortunately,
we
might
need
to
wait
just
a
little
longer
to
actually
opening
that
proposal
and
until
we
have
until
we
have
something
to
include
about
sessions
in
the
proposal.
C
I
have
you
know
a
question
to
others
on
on
the
sessions.
The
same
question
that
I
asked
you
martin,
which
is
is
sessions
implemented
on
the
client
side
in
in
your
current
agent,
are?
Is
it
done
on
the
back
end.
A
A
We
actually
have
some
customers
who
do
it
for
the
entire
browser
or
in
fact
it
browser
session,
which
could
be
multiple
browsers
instances
on
over
multiple
days.
We
have
other
customers
who
that
were
actually
partners
who
are
embedded
on
the
web
page
that
have
their
own
session
per
every
instance
that
they
bring
up.
A
C
So,
actually,
going
back
to
my
original
question,
I
I
I
want
to
make
a
you
know
a
point.
Basically,
the
the
reason
I
separated
the
sessions
details
from
the
original
proposal
was
because,
at
least
for
some
of
us
you
know
these
sessions
has
been
mostly
implemented
in
the
back
end.
It
is,
it
is
a
tricky
to
get
it
right
in
the
on
the
client
side
to
cover
all
the
use
cases.
It's
something
that
is
not.
C
It
looks
equal
into
a
trace
containing
a
bunch
of
spans,
but
it
is.
It
is
not
really
an
equivalent
because
with
sessions
you
know
there
are
corner
cases
to
handle
with
respect
to
ending
the
sessions
right
and
therefore
it
might
take
some
time
unless
you
know
somebody,
like
you
said,
that's
why
you
know
I
asked
you
know
unless
somebody
has
experience
in
implementing
sessions
entirely
on
the
client
side,
where
you
start
a
session
and
you
deterministically,
you
know
end
the
sessions
entirely
on
the
on
the
client.
C
Of
course,
there
are
cases
where
the
browsers
or
the
mobile
app
crashes
and
you
can't
end
the
session,
but
there
are
other
cases
such
as.
Let's
say
user
is
watching
a
video
you,
you
know,
you
think
it's
the
user
is
idle,
but
he's
not,
and
then
there
are
the
converse
case
where
you
think
there
is
activity
going
on,
but
it
turns
out
to
be.
You
know
just
some
background
heartbeats
you
know
going
so
in
my
opinion,
it's
you
know
it's
something
that
I
feel
we
should
not
include.
C
As
a
you
know,
first
class
entity
right
away.
You
know
it
should
be
more
as
a
added
as
a
plugin,
where
you
know
you
know,
your
first
version
could
work
without
sessions,
but
the
sessions
can
always
be
introduced
as
a
as
something
you
know,
as
a
plugin
that
will,
you
know,
seamlessly
fit
in
and
you
know
transparently
add
the
session
id
into
each
event,
and
and
that's
why
you
know
with
that
thought
process,
I
I
suggested
to
martin
that
hey
you
know
his
original
document
had
too
many
topics.
C
So
in
the
in
the
interest
of
making
you
know
progress
and
facilitated
discussion
on
smaller
topics.
I
I
took
out
both
the
sessions
and
sampling
into
you
know
separate
documents,
so
yeah
any
thoughts
on
that.
E
Y'all
agree
with
that,
I
don't
think
we
see
sessions
as
an
inherent
property
of
events
like
we
can
see
cases
where
you
might
not
have
a
session,
but
you
still
want
to
transmit
events,
and
I
kind
of
see
that
as
a
property
that
you
may
want
to
include
or
an
attribute
they
may
want
to
include,
but
not
necessarily
inherent
to
to
like
the
event
infrastructure,
so
yeah.
I
kind
of
agree
with
that
and
that
fits
with
our
model.
A
I
I
guess
from
from
our
model:
it's
okay,
so
we
always
have
an
id
which
we
do
call
session
id
and
even
if
we
can't
rehydrate
a
cookie,
we
create
a
random
one.
So
for
that
entire
run
time
of
that
session
in
quotes,
all
the
events
are
then
linked
together
so
and
really,
in
a
browser
case
the
what
you're
talking
about
in
terms
of
knowing
when
to
end
it.
That
was
the
problem
we
talked
about
last
week,
where
you
don't
you
know
a
session
is
a
long-running
group
of
events.
A
It's
not
you
know
we
can't
use
a
span
to
say
start.
The
span
start
accumulating
all
the
events
and
then
end
the
span,
because
that
just
doesn't
work,
but
they
could
have
the
the
the
session
open.
For
you
know,
days
or
months.
A
You
know
it's,
it's
not
a
time
restricted
thing
now,
but
in
terms
of
the
sampling
yeah,
that's
a
separate
issue.
We
do
talk.
I've
got
a
comment
later
about
the
the
specific
issue
in
relation
to
limiting.
I
won't
call
it
sampling,
but
limiting
the
number
of
javascript
errors
that
get
sent
or
exceptions,
but
yeah
sampling
separate
is
fine,
but
I
think,
having
a
field
which
groups
the
events
for
a
session,
I
I
would
vote
to
have
that
as
a.
E
So,
for
example,
if
if
a
user
has
disabled
all
browser
storage
and
you,
you
can't
store
something
across
pages,
for
example,
then
the
notion
of
a
session
is
kind
of
moot
in
that
case,
and
you
might
not
want
to
to
attempt
to
do
that
and
that's
an
example
of
a
case
where
you
might
just
want
to
send
events
without
having
a
notion
of
a
session.
Of
course,
you
just
you
could
just
say
you
know
the
null
session
id
means
you
couldn't
get
it
get
90
or
something
like
that.
A
Yeah,
but
you've
still
got
that
page
view
so
yeah
to
that
page,
where
you've
still
got
the
session.
The
fact
that
you
couldn't
persist
in
in
session
storage
or
or
a
cookie
is
is
just
okay.
When
you
get
another
page
view,
you've
got
a
new
id
sorry,
so
sad
too
bad.
You
can't
link
them.
E
C
So
yeah,
so
how
about
this?
Maybe
we
should
discuss
about
sessions,
but
I
would
you
know
how
about
prioritizing
the
the
the
first
document
you
know
which
doesn't
include
sessions,
and
maybe
you
know
you
know,
let's
get
to
the
sessions
after
that
and
then
together
you
know,
let's
you
know
you
know
we
can,
you
know,
put
them
together.
You
know
once
you
know,
we
we
make
incremental
progress.
F
Yeah,
just
just
make
it
clear
in
the
otep
that
we
submit
that
that
there
should
be
a
clear
section
for
everything
that
we're
leaving
out
and
just
explaining
why?
Why
we're
leaving
it
out-
and
I
think
also
maybe
making
it
clear
that
the
something
you
said
earlier,
that
the
the
model
we're
still
proposing
in
that
otep
is
still
fully
functional.
F
Right,
like
you
can
say
like
like
sessions,
are
important.
However,
you
know
you
can
you
you
can
still
do
rum
without
without
session.
So,
yes,
we
do
want
to
figure
out
a
a
way
for
to
do
sessions
with
open
telemetry,
but
you
can
look
at
the
rest
of
this
without
without
needing
that.
I
do
think
we
we
need
to
to
come
up
with
an
answer
for
this
stuff.
F
Just
you
mentioned
satoshi
mentioned
plugins,
but
it's
important
to
remember
that
a
very
common
situation
is
going
to
be
that
the
end
user
has
set
up
open
telemetry
like
stock,
open,
telemetry
and
they're.
Now
coming
to
whatever
back
end.
It
is
that's
going
to
ingest
the
run
data
and
they're
going
to
be
saying
like
I'm
going
to.
F
I
just
want
to
point
the
fire
hose
at
you
now
and
it's
possible
to
come
back
and
say
yes,
but
you
need
to
install
like
this
plug-in
or
like
our
company's
open,
telemetry
distro,
or
something
like
that
in
order
to
first
send
us
data
and
that's
going
to
create
friction
right,
they're
going
to
they're
going
to
say
like
yeah,
but
I
don't
want
to
install
stuff
I
just
want
to.
F
Even
if
it's
just
something
like
yeah,
we
generate
some
kind
of
session
id.
You
know
as
like
a
resource,
and
it's
just
there
at
the
beginning.
It's
just
it's
just
a
regular
resource
right.
You
can't
mutate
it
or
change
it.
It's
just
there
at
the
beginning,
and
we
have
some
stock
detector
that
can
be
there
for
pulling
a
pre-existing
session.
F
You
know
out
of
a
couple
of
different
places
like
a
cookie
or
somewhere
else
we
might
might
put
it.
I
do
think
it's
it's
worthwhile
to
if
we
think
that
would
be
good
enough.
Whatever
we
think
the
good
enough
default
solution
is
we
we
should
put
it
put
it
down
in
another
in
another
otep
and
make
that
a
proposal
try
to
follow
up
quickly
with
a
proposal
like
that,
it's
even
more
important.
I
think
that
we
follow
quickly
if
what
people
feel
like
they
need
in
order
to
do
sessions.
F
If
we
can
get
away
with
a
session
id
just
being
an
immutable
resource
that
you
set
on
the
tracer
right
at
the
beginning,
and
you
know
I
think
you
can
have
multiple
nev.
I
wasn't
sure
if
I
think
in
the
case,
you're
talking
about
you're
also
running
multiple
tracers
right
when
you
have
multiple
vendors
right
who
want
different
session
ids.
Is
that
true.
A
Correct
yeah
right,
but
they
may
want
to
change
the
session
id
after
so
having
an
immutable,
would
be
a
problem
exactly.
F
So
I
think
those
are
the
those
are
the
situations
where
we
need
to,
I
think
be.
We
can't
leave
it
to
a
plug-in
for
sure
right
if
it
requires
some
fundamental
change
to
how
open
telemetry
works,
like
resources
becoming
mutable,
which
is
a
thing
that
we've
stated
before
is
kind
of
a
kind
of
a
requirement.
So
so
we
either
need
to
like
bend
on
those
requirements
and
be
like
you
just
get
like
you
can
like
have
a
continuous
session
that
that
can
maybe
persist
across
multiple.
F
You
know
browser
tabs
and
refreshes,
but
you
can't
have
you
can't
have
like
a
partial
session.
It's
on
you
and
on
your
back
end
too,
to
sort
that
out
or
we
have
to
say
look.
We
need
mutable
resources
or
we're
going
to
use
some
other
mechanism
to
to
attach
these
session
ids.
F
So
so
to
me
that
that's
the
part
where
there's
actually
the
most
work
when
it
comes
to
to
sorting
sorting
this
out
with
the
open,
telemetry
community
right,
because
if
everything
we're
doing
is
just
within
the
bounds
of
the
primitives,
we
already
have
then
like.
No,
I
won't
say
no
one
cares.
What
we're
up
to,
but
it's
like
no
big
deal
right.
It
only
really
becomes
a
big
deal
if
we
start
saying
no,
we
need
like
resources
to
become
mutable
or
something
like
that.
C
So
how
about
this?
Okay,
I
take
it
back
that
you
know
it
cannot
be
a
plug-in.
It
has
to
be
part
of
the
stock
offering
yeah.
So
I
I'll
accept
that.
But
can
we
discuss
the
basic
aspects?
You
know
there
are
a
bunch
of
comments.
You
know
that
we
got
feedback
on
martin's
document.
C
F
Yes,
no,
I
I
totally
agree
with
the
idea
of
pulling
it
out
of
like
that
can
be
its
own
rfc
right,
and
we
just
need
to
make
it
clear
like
in
this
one
we
submitted
by
saying:
hey,
there's
this
big
topic
sessions.
F
It's
super
important,
we're
not
gonna
talk
about
it
here,
because
we
need
it,
but
it
doesn't
affect
the
rest
of
this
we're
confident
it
doesn't
affect
the
rest
of
this
model.
However,
we
end
up
doing
sessions,
doesn't
affect
all
the
rest
of
the
stuff
we're
proposing
so
so
we're
just.
F
F
We
don't
have
a
clear,
easy
answer,
but
we're
also
confident
that
that
we
could
we
can
decide
that
after
after
the
fact,
it's
not
going
to
cause
us
to
change
our
minds
about
events,
or
you
know
any
of
the
other
thing
we're
proposing
here.
So
as
long
as
that
says
that
in
the
otep,
I
think,
okay,
we're
good.
In
fact,
the
open
telemetry
community
likes
really
likes
to
work.
That
way,
we
like
we
like
carving
things
out
when
and
where
we
can,
because
it
helps
focus
the
discussion.
F
C
Martin,
I'm
thinking,
maybe
you
could
share
your
screen
and
let's
go
over
the
comments
and
and
then
resolve
them.
You
know
in
the
call,
and
one
of
the
fundamental
topics
that
I
think
never
brought
up
last
week
was
that
our
assembly
brought
up
was
that
the
attribute
names
are
quite
long
and
repeating-
and
you
know
that
could
affect
the
size
of
the
payload
and
and
even
the
prototype
of
encoding
versus
json
encoding,
you
know,
maybe
the
json
stringify
is
is-
is
more
efficient
than
protobuf.
C
So
I
think
that's
a
fundamental.
You
know
topic
to
discuss
because-
and
I
think
somebody
in
the
call
use
the
term
you
know
we
should
use
a
new
signal
and
in
in
I
was
thinking
about
it
and
I
felt
like
yeah
when
in
our
current
product
you
know
we
use
like
one
letter
variable
names
for
the
attribute
keys
or
it's
not
even
you
know
separately.
C
You
know
like
key
equal
to
attribute
value
equal
to
value.
It's
not
like
that.
You
know
it's
just
like
key
equal
to
value
right
that
that's
how
the
objects
have
the
the
fields
I
felt
like
you
know.
This
could
be
a
topic
of
encoding.
C
You
know
which
could
be
again
independently
considered.
It
could
be
a
topic
for
how
the
exporter
would
export
the
data
it
doesn't,
you
know,
require
a
new
signal,
or
even
even
if
it's
a
new
signal
signal
is
just
like
another
data
structure,
but
the
way
we
represent
attributes-
and
you
know
the
fields
will
remain
the
same.
C
So
I
think
who
ever
brought
it
up
last
week.
You
know,
could
you
clarify
what
you
meant
and
talk
about
it.
A
Yeah,
that
was
me
so
fundamentally
in
the
in
the
browser.
There's
a
couple
of
limitations
that
you
have
to
worry
about.
One
is
just
the
amount
of
time
it
takes
to
serialize
the
object
or
the
event
that
you're
trying
to
package
and
then
not
just
the
the
processing
time,
but
then
the
resulting
size
that
goes
out
the
door
so
like
during
there's
a
there's,
a
really
basic,
fundamental
limitation
that
we
have
in
that
during
unload
perfectly.
A
You
can't
do
xhr,
sync
anymore,
so
you're
really
limited
to
send
beacon
or
fetch
with
keeper
live,
both
of
which
have
the
64k
limit
for
the
total
data
going
at
the
door.
So
if
you
have
a
lot
of
events
that
you
want
to
package
up,
if
the
total
package
size
is
greater
than
that,
the
browser
will
just
say
no
and
you've
just
lost
all
those
events,
so
constructing
a.
A
A
a
payload
that
is
efficient
for
both
packaging
and
and
serializing
it
and
the
total
size
going
out
the
door.
I
I
think,
is
a
fundamental
requirement
from
a
from
a
client
perspective
so
and
like
and
in
the
case
of
what
you're
talking
about
you're,
replacing
single
character.
That's
just
a
compression
technique.
A
It
doesn't
get
away
from
the
the
issue
like
martin,
I
haven't
read
the
the
current
one,
but
in
martin's
original
one
where
we
had
affected
the
attributes
completely
flattened
out
that
I
think
would
just
be
untenable
from
both
the
cpu
and
the
payload
size,
because
you'd
be
gonna,
effectively,
walk
an
object
structure
and
then
flatten
it
out.
A
I
think
I
I
spoke
to
martin
on
slack
one
other
technique
was
we
have
a
single
field
which
is
just
a
blob
field,
and
that
blob
field
is
just
the
you
know,
a
stringified
json
blob.
So
we
can
say
the
type
is
exception
and
then
the
data
is
just
the
string
of
five,
but
that
has
issues
as
well,
because
then
you've
got
like
extra
slashes
to
encode
the
quotes
and
stuff.
A
But
if
we're
going
to
try
and
ram
it
into
an
existing
signals,
especially
considering
this
week,
the
the
logs
went
stable
in
terms
of
its
definition.
C
Is
it
only
a
matter
of
new
signal,
or
is
it
even
about
how
you
know
the
fields
and
the
attributes
you
know
are
represented
inside
that
object.
A
A
F
Can
I
suggest
it's
to
me?
It's
it's
not
seems
like
it's
less
about
having
a
separate
signal
and
more
about
having
a
new
protocol
and
even
a
new
sdk
implementation
for
clients
like
browser
clients
and
in
particular,
because
everything
you're
talking
about
it
seems
like
you
know
it
affects
all
the
the
data
but
doesn't
necessarily
affect
the
api
that
you're
writing
instrumentation
with
or
that
the
end
user
is
using.
F
I
think
it
would
be
good
to
know
if
it
would
affect
the
api
because
it
seems,
like
you
know,
traces
spans
metrics,
like
like
all
of
this
stuff
is
going
to
be
subject
to
the
same
issues,
and
so
what
we
would
want
to
do
is
define
all
of
this
stuff.
Semantically,
like
these
are
the
events
you
use
these.
Are
you
know
the
how
you
use
spans,
etc,
etc,
and
then
we
would
come
back
with
like
a
new
protocol
and
browser
implementation
and
say
like
when
you
want
to
actually
consume
this
api
in
the
browser.
F
Here's
like
the
specialized
implementation
that
you
need
to
to
do
it
properly,
because
the
browser
is
such
a
special
environment
and
here's
a
special
protocol
you'd
want
to
send
it
on
that
is
like
highly,
very
lightweight
and
and
deals
with.
You
know
the
limitations
that
you
have
with
what
browsers
can
do
and
stuff
like
that.
Does
that
seem
reasonable
yeah?
I.
A
Think,
mostly
in
terms
of
the
way
the
api
is
defined,
you
know
for
for
clients
generally
there's
a
lot
of.
I
don't
need
to
start
starting
to
stop
a
span.
It
is
just
the
case.
I
have
an
event
and
I
just
want
to
fire
it
off,
which
is
why
I
think
martin
was
talking
about
using
logs.
F
F
A
Yeah,
the
the
ajax
schools,
you
know
to
the
to
the
back
end
and
then
you
want
to
use
tracing
all
correlated,
so
those
are
definitely
the
span
cases.
F
Yeah
so
they're
around,
I
agree,
they're,
maybe
not
as
maybe
not
as
prevalent
as
as
like
in
other
environments.
They
might
be,
and
certainly
we
need
a
lot
we
need
to
define.
F
We
haven't
been
very
heavy
with
defining
like
events
like
you
know,
semantically,
defining
events,
we've
mostly
been
focused
on
defining
spans
and
metrics.
You
know
to
describe
things
like
http
requests
and
stuff,
and
it
seems
like,
with
rom
we'd
end
up
defining
a
whole
bunch
of
like
specific
events.
F
You
know
so
that
you
know
a
click.
A
click
is
a
click.
You
know
standard
descriptions
for
what
a
lot
of
standard
events
could
be.
F
So
we
got
a
lot
of
work
to
do
there,
but
it,
but
it
seems
like
to
me
that
the
the
basic
primitives
of
events,
traces
and
and
metrics
are
and
resources
are,
are
like
the
primitives
that
we
need,
and
so
it
would.
I
guess
where
I
want
to
like
push
back
a
little
bit
is
the
idea
that
we
need
to
create
a
new
signal
because
we're
sending
a
different,
a
different
kind
of
data.
F
F
The
the
networking
is
so
constrained
that
you,
you
just
wanna,
you
just
wanna,
implement
it
differently
and
we
are
looking
at
additional
protocols
to
be
clear.
There's
work
being
done
right
now
on
adding,
like
a
column,
compressed
protocol
for
high
throughput
based
on
apache
arrow.
F
So
that's
like
a
very
highly
compressed
protocol.
That
would
be
very
useful
as
like
a
gateway
protocol
right
so
like
when
you
have
your
like
huge
pipe
of,
like
all
of
your
data
coming
out
of
your
whole
system
and
you're,
trying
to
egress
all
of
that
data
to
the
back
end
storage,
you
want
you
want
something.
That's
like
more
efficient
than
this,
like
basic
protocol
that
we
have
so
far,
which
is
just
logic.
You
know
very
straightforward,
protobuf
encoding
of
the
objects,
but
I
I'm
guessing.
F
You
know
that
that
apache
aero
approach
would
not
be
the
right
approach
for
browser
clients,
sending
data
right
like
you're,
still
going
to
want
something
pretty
specialized
to
that
environment,
because
you
don't
you
know
it's,
it
has
to
be
like
string
encoded.
I
imagine
still
these
days,
though
yeah.
F
Rusty
and
yeah
you're,
not
presuming
like
a
big
fat
like
pipe
right.
You're,
presuming
like
a
really
flaky
network
scenario
and
that's
like
cost
the
user
money
right
to
to
to
send
data
on
yeah.
A
It's
also
the
cpu
time
involved
in
creating
that,
like
yeah,
most
of
our
people
don't
implement
the
gzip
encoding
to
send
it,
which
is
one
way
to
crunch
it
down
because
of
the
cpu
intensity.
Unless
you
shift
your
sending
workload
off
into
a
a
worker,
you
know
a
background
worker
effectively
while
it's
serializing
the
ui
threads
frozen
and
that
directly
affects
the
yeah,
the
interactivity
for
the
user,
and
that
can
be
not
insignificant
if,
depending
on
the
payload
size,
you're
sending.
F
All
of
that
and
then
have
a
a
follow-up
that
might
even
you
know
the
move
over
to
the
the
javascript
sig,
which
is
to
go
over
to
them
and
say
like
because
I
think
this
is
I
mean,
maybe
that
to
some
degree
this
affects
swift
and
android,
but
I'm
guessing
browsers.
Are
you
know
it's
its
own
special
beast,
and
so
you'd
want
to
go
to
the
javascript,
sig
and
basically
say
hey
we
want
to.
F
We
want
to
start
up
an
initiative
to
build
like
like
a
highly
specialized
like
browser,
sdk
and
protocol,
and
we
want
to
work
with
you
guys
to
to
make
that
a
reality.
Does
that
seem
like?
Would
that
work
for
you,
nev,
like
taking
take
an
approach
like
that.
F
Right
now,
it's
like
from
understand
the
approach
so
far
has
been
to
just
engineering
efficiency
right
like
reuse
as
much
as
possible,
keep
them
as
similar
as
possible,
so
that,
like
something,
can
get
out
the
door
yeah,
and
this
would
be
like
like
round
two
right:
okay,
we've,
we've
stabilized
traces,
metrics
and
and
logs
like,
like
we've
hit
our
baseline
of
of
making
it
work,
and
now
we
can
come
in
with
like
round
two
which
is
building
a
new
implementation
of
all
that
stuff
for
the
browser.
F
That's
that's
like
highly
optimized,
but
we're
doing
it
now
that,
like
all
those
signals,
are
stable,
so
we're
not
like
trying
to
build
that
and
then
someone
changes
like
the
definition
of
how
spans
work-
and
you
have
to
like
redo,
that
that
was
like
one
of
the
things
that
that
they
were
struggling
with
at
first
was
just
the
thrash
of
nothing
being
stable.
Yeah.
A
And
and
like
yeah,
there
is
nothing
in
the
the
js
sdk
for
logs
at
this
point,
not
even
a
prototype.
Sorry.
F
Yeah,
I
I
imagine
that
will
be
more
straightforward
to
build,
though
than
traces
and
and
metrics.
F
But
also
the,
but
the
more
important
thing
is
that
that
it's
stable
in
this
spec
right,
like
that's
kind
of
what
we've
been
waiting
for,
is
like
for
the
spec
to
be
stable.
So
you
know
like
nothing.
There
is
going
to
change
that,
isn't
backwards
compatible.
So
if
you
want
to
have
an
adventure
and
go
write,
a
totally
new
super
efficient
implementation,
you
don't
have
to
worry
that
you're
you're,
trying
to
optimize
for
for
moving
target
of
some
kind.
F
So
anyways,
I
guess
what
I'm
saying
is
it
feels
like
like
by
the
time
we
get
this
logical
model
done,
metrics
and,
and
logs
will
be,
will
be
stabilized
or
nearly
there,
and
it
would
be
if
like
we're
willing
to,
if
we
have
like
resources
to
bring
to
the
jsig
to
actually,
you
know,
work
out
like
the
the
browser
tool
chain
and
then
build
it.
F
It
seems
feasible.
It
seems
like
this
is
like
the
right
time
to
to
go.
Do
that
stuff,
but
we'd
have
to
help
the
jsig
out
to
do
it
like
we
can't
just
go
to
them
and
be
like
go
build
this
for
us.
We
wrote
a
spec.
F
And
I
guess
that
gets
back
to
my
original
question
of
like.
Is
there
anything
about
the
api
that
we've
built
so
far?
That
is
really
going
to
be
a
fly
in
the
ointment,
not
not
just
for
like
this
rum
stuff,
but
I
mean
like
for
traces
and
metrics
like
like
the
whole.
F
The
whole
thing
you
know,
there's
like
basic
stuff
around,
like
you
know,
don't
don't
use
strings,
you
know,
use
constants
and
then
in
like
the
browser
you
could
like
replace
those
constants
with
like
one
character,
you
know
string,
values
and
stuff
like
that,
but
I
think
our
basic
api
of,
like
you
have
events
you
have
metrics.
You
have
traces.
F
You
have
like
a
context
manager
that
you
stick
all
this
stuff
in,
like
that
all
the
stuff
you
would
be
using
when
you're
writing
instrumentation
would
be
would
be
fine
and
we
could
go
back
in
and
really
do
it
as
like
an
sdk
level
overhaul
under
the
hood,
but
it
would
be
good
to
know
if
there
is
something
about
the
api
we
have
going
so
far.
That
that's
actually
like
would
be
like
a
huge,
huge
problem
from
creating
creating
that
new
implementation.
A
There
is
a
couple
of
things
that
I
noted,
and
I
think
I've
commented
on
this
in
the
past,
and
that
is
like
the
global
context
is
a
problem
great
for
most
simple
apps.
It's
easy
for
spas,
where
you've
got
multiple
components
that
want
to
play
different
tasks.
Having
the
sdk
in
a
lot
of
cases
require
that
the
global
context
has
the
current
context
to
pass
it
between.
Instrumentations
is
a
problem.
A
You
know
I
I
know
when
I
brought
it
up
last
time.
We
I
think
it
was.
You
ted
mentioned
that,
yes,
you
can
have
different
instances,
but
it's
the
way
the
sdk
is
implemented.
Requiring
that
that
context
we
have
its
value
set
is
problematic.
A
Apart
from
that,
I
I
think
generally
it's
just
it's
an
api
surface.
It's
like
how
you
interact
with
it
so
yeah,
and
then
it's
just
the
transport
like
I
haven't
looked
at
the
the
log
spec.
My
my
biggest
thing
with
the,
where
we're
talking
about
the
the
context
keys
or
the
attribute
keys,
is
if
an
attribute
can
actually
have
an
object
as
a
value
rather
than
having
a
string.
That
would
probably
solve
some
of
the
serialization
issues.
C
So
so
how
about
this
you
know,
maybe
nev.
Could
you
maybe
write
it
up
and
present
to
us
next
week?
What
you're
talking
about?
Because
I
think
I'm
just
just
for
the
in
the
interest
of
time
and
to
be
more
concrete.
A
Yeah,
I'm
not
sure
I'll
have
next
week,
maybe
the
week
after
I'm
just
working
on
a
high
priority
thing
at
the
moment
internally,
that
I
need
to
get
out
the
door.
C
Okay
and
and
to
answer
ted's
question,
you
know
that
topic
doesn't
necessarily
are
significantly
affect
any
of
the
current
other
api
and
discussions
right.
C
Can
it
be
done
transparently
and
separately.
C
As
in
should
we
hold
off,
you
know
talking
about
other
things
until
that
you
know
is
discussed
or
it's
it's.
Okay
to
you
know,
continue
talking
about
other
topics.
A
A
Yeah
well,
based
on
what
ted's
saying
where
we
want
to
try
and
not
introduce
a
new
signal,
then
I
think
that
is
the
only
path
forward.
F
F
F
It's
a
problem
for
like
all
tracing
that
might
be
happening
in
javascript
and
like
all
logs,
that
you
wanna
you
wanna
log
and
and
like
all
metrics
that
you
would
wanna
create
and
so
like.
It's
not
if
it's
a
problem
that
we
have,
we
have
it
with
our
existing
apis
and
we
would.
We
would
need
to
modify
those
apis
and
deal
with
like
the
backwards
compatibility
issues.
F
I'm
hoping
we
don't
have
to
do
that,
and
and
if
we
we
don't
have
a
problem
there
then
there's
no
problem
using
these
existing
primitives
to
to
model
what
we're
trying
to
model,
and
so
it
seems
like,
like
it's
two
separate
things
to
me,
just
like
get
this
model
approved
and
then
once
all
of
that
stable
go
to
town
on
a
javascript
implementation.
That's
that
solves
the
the
implementation
and
optimization
issues.
F
So
that's
that's
my
hope.
If,
if
that's
not
true,
it
would
be
great
to
to
identify
like
where,
where
that's
problematic,.
F
A
Maybe
so
we
just
need
a
new
span
kind
to
pass
down
to
say
the
client
is
starting
the
request,
which
may
or
may
not
be
linked
to
a
previous
distributed
trace,
but
just
so
the
back
end
can
identify
that
this
is
an
ajax
call
which
is
equivalent
to
in
martin's
original
one.
He
had
the
client
type
in
the
in
the
log
definition
just
so
the
back
end
can
can
identify
that
this
is
a
client
request,
not
a
server
request.
F
Interesting,
okay,
because
it
might
need
to
do
something
different
like
like
send
back
like
us,
give
the
client
back
a
a
span
id
for
it
to
use
as
part
of
the
response,
headers
or.
C
No,
no,
I
I
I
can
clarify,
I
think
what
he
means
is
so
there
are
two
different
topics
actually
in
in
here,
so
we
introduced
semantic
conventions
and
resource
attributes.
C
Saying
that
you
know
all
clients
at
telemetry
must
have
either
a
device
attribute
or
a
browser
attribute
right,
and
you
know
if
either
one
of
them
is
present,
it
means
it's
a
client
side.
So
this
is
at
the
resource
level.
C
So
this
alone,
you
know,
might
be
sufficient,
and
what
nav
is
talking
about
the
span
kind
is
is,
you
know,
is
only
applicable
at
the
span
level
right,
I
think
if
it
is
available
at
the
resource
level,
you
know
you
don't
again
need
any
differentiation
at
the
you
know
in
the
spans
that
is
coming
from
a
client
side.
F
Right
right,
this
is
this
is
for
the
the
data
pipe
coming
out
this.
So
not
we're
not
talking
about
in-band
communication
between
the
clients
and
server
like
application,
client
application,
server,
you're
saying
when
you're
you're
fire
hosing
you're,
sending
this
data
out
the
telemetry
out
for
back
end
to
collect.
You
want
to
be
able
to
know
that
this
this
all
this
telemetry
is
coming
from
like
a
browser,
client
and
yeah.
F
I
would
love
for
that
to
be
handleable
through
through
resources
yeah
at
like
the
resource
level
or
even
as,
like
a
connection
header
attribute,
or
something
like
that
right,
because
it's
not
probably
that's
I
mean
maybe
you're
you're
talking
about
like
further
down
the
telemetry
stack
where
you
it's.
It's
all,
maybe
getting
mixed
together
now,
as
opposed
to
just
data
coming
from
a
from
a
client.
F
C
Yeah,
I
think,
based
I
I
didn't
fully.
If
it's
a
question
I
didn't
fully
follow,
are
you
asking
that?
Are
there
use
cases
where
we
need
to
separate
the
client
side,
data
from
the
other
telemetry
data,
and
if
so,
how
do
we?
You
know?
What
do
we
use
to?
You
know
classify
that.
A
Yeah
but
like
for
azure
monitor,
we
effectively
all
send
it
to
the
same
back
end
and
then
the
event
type
identifies
whether
it's
the
server
or
the
client,
and
then
we
have
like
the
the
application
map
can
identify.
Okay.
This
is
all
all
happening
on
the
client
and
then
it's
it's
talking
to
the
the
back
ends
for
this
stuff.
So
yeah,
that's
what
we're
talking
about
here?
Okay,.
F
F
We
can't
defer
the
way,
we're
carving
out
sessions,
maybe
or
or
sampling
as
part
of
this
otep,
we
have
to
explain
like
how
we
expect
the
telemetry
pipeline
to
actually
shunt
this.
You
know
presuming
you're
in
a
situation
where
you
have
a
specialized
back
end
that
you
only
want
the
client
data
to
go
into
like
how
does
this
proposal
plan
to
to
allow
you
to
do
that?
It
seems
like
that
needs
to
be
part
of
the
part
of
the
hotep.
A
Yeah-
and
I
think
I
thought
our
leader's
proposal
for
having
a
separate
signal
was
about
great,
so
the
back
end
can
more
readily
identify
that
these
are
client
events
versus
server
events.
F
B
Yeah
I
mean
we-
we
talked
about
this
a
long
time
ago
for
a
long
time
like
we
originally,
so
we
essentially
the
idea
is
that
we
want
to
be
able
to
distinguish
on
the
resource
level
by
presence
of
attributes.
Great
great,
that's
right.
B
That's
like
the
direction
we
got
from
the
tc,
and
it's
like
we
originally
proposed,
adding
like
add
app,
namespace
or
attributes
that
will
shut
down
because,
like
we
need
some
common
sort
of
attributes
across
all
types
of
telemetry,
so
like
we're
now
proposing
to
use
either
browser
presence
of
browser
or
device
attributes.
That's
one
option.
The
other
option
is
looking
at
the
value
of
some
existing
attribute
like,
for
example,
the
process
runtime
name
is,
would
be
browser
for
browser
or
always
os.net
would
be
something
for
ios.
F
And
that
makes
sense
to
me
because,
because
you're
never
going
to
have
these
other
signals
separated
from
the
resources
right,
like
the
in
general
events
and
metrics
and
and
spans,
aren't
very
useful
if
they
aren't
packaged
up
along
with
the
resources
right
as
a
batch.
So
you
should
always
have
this
resource
data
attached
to
them.
It's
never
going
to
get
mixed
in
with
like
data
from
other
sources.
So
so
it
seems
to
me
it
seems
fine
to
use
resources
like
like
a
device
and
browser
to
to
do
the
switching
but
but
yeah.
F
A
Yeah,
I
I
I
think
I
had
this
in
the
a
comment
in
the
previous
one:
the
immutability
of
resources
on
a
browser.
A
C
A
You
may
not
be
active
for
three
minutes,
especially
in
a
browser.
You
could
have
client-side
redirects
you're
there
for
fractions
of
a
second.
So,
and
you
want
to
like
capture
that
redirect
like
in
the
case
of
someone
authenticating,
you
want
to
capture
the
fact
that
you
did
authenticate.
Then
it
could
have
been
a
silent
authentication.
F
Okay,
but
but
that
sounds
like
like
the
issue,
there
is
like
a
general
issue
of
implementing
resources
in
some
of
these
environments.
Right,
like
like.
That's,
like
that's
a
general
issue
we
have
with
with
resources
right
now.
Is
that
there's
this
asynchronous
loading
problem,
and
I
know
we've
gone
round
and
round
about
how
to
implement
that
best.
F
Like
do
you
just
like
hold
off
on
sending
the
first
batch
until
those
things
have
resolved-
or
you
know,
do
you
just
like
fire
hose
the
data
out
and
your
initial
batches
of
data
might
be
missing
some
resources,
because
those
resources
are
asynchronous.
A
Yeah,
it
comes
back
to
the
immutability,
so
if
you
crack
a
user
agent,
you
can
sort
of
determine
like
if
you
look
at
a
chrome
or
an
edge
user
or
agent
today,
you'll
think
you're
running
on
windows
10,
but
you
could
actually
be
running
windows
11,
because
windows
11
doesn't
identify
itself
in
the
user
agent
anymore.
You
have
to
use
the
high
entropy,
so
you
may
actually
set
it
as
windows.
10
you'll
often
do
this
in
the
background,
if
it's
available,
because
depending
on
the
browser
may
not
be,
and
then
you
want
to
update
it.
F
Okay,
I
mean
that
sounds
like
like
yeah
personally,
I
think
the
days
of
resources
being
immutable
or
are
somewhat
numbered,
but
but
separate
from
that.
I
do
think
this
scheme
works
right,
like
there
are
some
fields
that
are,
you
could
only
grab
asynchronously,
but
as
far
as
being
able
to
to
pick
a
field
that
you
could
reliably
set
and
use
to
detect
that
something
was
from
a
browser
or
device
like
it
seems
like
we
would
be.
We
would
definitely
have
like
some
fields
that
we
could
use
for
that.
A
Yeah,
like
I,
I'm
not
not
discounting
that
argument,
I'm
just
from
an
efficiency
perspective
where,
if
you've
got
a
back
end
receiving
your
trillions
of
these
requests
right
having
to
completely
crack
the
message
and
route
based
on
the
individual
attribute
within
the
value
is
not
very
efficient.
F
Right
and
that's
where
to
me
the
question
of
like
some
kind
of
like
transport,
header
or
something
right
like
you,
you
kind
of
have
like
two
places.
You
can
put
it
right.
It's
either
like
buried
in
the
data
somewhere
right
or
it's
in
the
envelope
that
the
data
is
coming
in
yep.
So
far,
we're
just
talking
about
stuff,
that's
like
in
the
actual
protocol,
but
maybe
there's
a
way
to.
C
A
From
those
like
headers
have
another
issue
in
a
browser
and
that
if
it's
a
cross
origin
request,
it
will
cause
an
additional
network
options
request
to
occur.
But
you
can
put
in
a
query
string.
So
as
long
as
it's
fixed.
F
But
the
I
guess,
the
another
thing
I'm
thinking
of
not
to
get
in
the
weeds
about
like
the
pipeline,
but
you
do
have
this
thing,
which
is
that
everything
that's
coming
in
from
these
clients,
whether
mobile
clients
or
browser,
whatever
it's
coming
in
off
the
open
internet
right.
So
one
we
may
want
just
a
different
protocol
for
all
that
stuff
to
be
packaged
up
and
two
there's
gonna
be
some
kind
of
like
public
gateway.
F
This
stuff
has
to
go
to
that.
None
of
your
back-end
data
is
going
to
be
going
to,
and
so
I
wonder
if,
like
from
a
practical
standpoint,
that's
actually
the
way
that
you
do
this,
which
is
just
like
right
there
at
that
that
public
gateway.
F
You
know
you
know
everything
coming
in
off
of
that
is
coming
in
from
a
client
and
should
then
be
like
sent
off
to
you
know
a
run
back
end
or
something
like
that,
and
you
don't
even
have
to
sniff
the
data,
because
that's
the
only
the
only
data
there
is
in
that
pipeline.
B
That's
that's
a
good
point
because
I
I
wonder
like
if
this
is
something
we
need
to
solve.
You
know
like
like.
Is
it
something
like
if
you,
if
you're
able
to
are
willing
to
open
the
message
and
and
in
just
everything
in
one
pipeline
you
can,
or
you
can
have
two
separate
endpoints
yeah.
F
I
I
will
say
like:
I
definitely
think
we
need
to
clearly
define
how
you
detect
this
stuff,
using
resources
right
like
let's
just
say
you
end
up
in
a
world
where
it's
all
mixed
together,
somehow
like
like,
we
should
like.
I
do
think
it's
it's
worthwhile
to
say
like
yes,
you
should
use
this
device.
Look
at
this
device
attribute
for
this.
This
browser
attribute,
if
you
want
to
know
that
it's
a
device
or
browser-
and
these
are
required,
attributes
that
you
have
to
set.
So
there
is
some
way
to
like.
F
I
do
think
we
should
say
that,
but
as
far
as
like
the
practical
perspective
of
like,
what's
the
most
optimal
way
to
do
this,
that's
maybe
like
not
something
we
have
to
worry
about
in
this
proposal.
That's
just
gonna
be
a
thing
that
will
come
out
of
how
how
you
implement
that
that
pipeline
by
basically,
like
keeping
all
of
this
data,
basically
sending
this
data
to
a
different
endpoint,
then
you
send
send
the
server
side
data,
so
you
don't
have
to
do
any
sniffing
at
all.
B
We
are
at
time
we
didn't
go
through
all
the
topics.
One
thing
that
I
wanted
to
propose
is
that,
in
order
to
make
faster
progress
that
maybe
we
can
meet
more
frequently,
maybe
we
could
either
either
have
the
whole
sig
more
frequently
or
we
could
spin
off
like
working
groups
based
of
interest
or
topics
like
we
could
do.
You
know,
there's
a
people
interested
in
working
on
sessions.
We
could
spin
off
like
into
a
working
group
for
sessions,
for
example,
any
any
thoughts
on
that
or
interest.
A
As
long
as
it's
not
eight
o'clock
in
the
morning,
pf2
I've
already
got
like
three
eight
o'clock
meetings.
You
know,
tuesday,
through
thursday
generally
so.
B
Yeah
I'll
post
a
message
in
the
slack
channel
with
maybe
some
some
options
for
time
and
see
who's
interested
in
in,
and
maybe
you
can
begin
start.
Maybe
by
having
a
separate
group
for
sessions
to
talk
about
sessions.
F
Yeah,
if
we
can
make
progress
asynchronously
as
well,
I
think
that
we
should
also
try
to
right.
We
we
have
this
stuff
written
down
in
proposals,
or
at
least
some
of
it.
So
maybe
that's
that's
the
other
thing
we
could
try
to
do
to
move
it
faster.
Is,
I
guess
we
don't
have
all
of
these
things.
Some
of
these
things
are
not
yet
to
the
point
where
we
have
a
proposal
about
it,
but
for
everything
that
we
do
kind
of
like
commenting
on
those
proposals,
it's
probably
very
helpful.
F
So,
for
the
for
this
stuff,
for
example,
I'll
try
to
go
back
into
your
proposal,
martin
and
point
out,
based
on
our
conversation
today,
what
what?
What
sections
need
to
be
flushed
out
a
little
bit
more
okay,.
F
F
C
Actually,
I
posted
I,
I
wrote
up
the
sessions
proposal,
my
document
and
I
posted
the
link
in
in
the
in
the
slack
channel.
I
I
don't
know
if
you.
C
Yeah
yeah,
so
so
there
are
separate
documents,
for
you
know,
sessions
and
the
sampling
and
also
how
we
would
you
know,
want
to
design
the
apis
around
events
and
the
combination
of
events
and
spans.
C
It's
it's
a
it's
a
very
brief
one
pager,
but
I
think
a
lot
more
needs
to
be.
You
know
fleshed
out
in
that,
but
that's
a
starting
point.
So,
if
you
could,
I
posted
all
the
links
in
the
in
the
client
side,
telemetry
channel.