►
From YouTube: 2022-05-03 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
C
So
ted
martin
and
I
want
to
talk
about
a
little
bit
of
planning
today,
like
for
a
few
minutes,
yes
see
where
we
are
going
and
what
we
want
to
do.
B
C
D
Regarding
all
the
discussions,
that's
going
on
around
this
right,
I
know
there's
a
thread
on
slack
where
we've
been
discussing,
and
apart
from
that,
there's
also
one
document
where
I
think
which
martin
started
or
something
where
comments
are
being
put
right.
Are
there
any
other
places
where
we
should
be
looking
at
for
discussions,
comments.
C
There
are
multiple
documents.
Maybe
if
you
look
in
the
client
side,
telemetry
slack
channel,
I
had
posted.
You
know
one
time
all
the
documents.
Actually,
our
agenda
document
has
all
the
links
at
the
top.
Okay.
C
C
Okay,
so
basically
we
have
come
a
long
way
in
terms
of
understanding
what
we
want
to
do.
C
Originally
when
we
started
it's
been
almost
like
four
to
six
months
now
we
have
been
you
know
doing
this
discussions
here.
It
appears
that,
or
rather
it
is
that
client-side
telemetry,
you
know,
has
been
there
in
some
loose
form,
but
not
in
any
particularly.
You
know
strong
form,
as
in
there's
no
specific
documentation,
specifically
for
client-side
telemetry
examples.
Being
you
know,
there
is
a
browser
sdk
javascript
sdk
for
the
browser.
C
Splunk
has
a
you
know
an
android
sdk
based
on
java
sdk,
and
then
there
is
a
swift
sdk
as
well
for
ios.
So
everything
all
languages
have
some
support
in
some
form,
but
I
think
in
in
this
sig
you
know
we
have
identified
several
things.
You
know
specifically
functionality
outside
of
traces
right.
C
So
I
think
all
these
three
that
I
mentioned
you
know
they
do
have
decent
support
for
tracing,
but
a
typical
rum
solution
has
a
functionality
beyond
you
know,
tracing
and
and
that's
what
we
have
been
trying
to
capture
and
I
think.
C
Fundamentally,
we
have
identified
logs
as
the
data
model
and
apis
to
represent
the
telemetry
outside
of
tracing,
and
there
we
did
make
progress,
I'm
close
to
submitting
you
know
tip
this
week.
I
I
need
to
iron
out
a
few
comments
in
in
the
lockseek
tomorrow.
After
that
I'll
submit
a
notep,
and
hopefully
we
can
get
started.
You
know,
building
things
with
that
api
there
are
sessions
is
is,
is
is
one
that
is
that
needs.
You
know.
C
Some
discussion
may
be
a
decision
on
on
what
we
need
to
do
but
other
than
sessions.
The
next
step,
ideally,
is
to
start
defining
semantic
conventions
on
the
attributes
for
various
events
that
we
want
to
capture
and
and
then
once
we
identify
them,
then
I
think
where
to
start
implementing
those
events.
Like
you
know,
things
like.
C
You
know
error
capture
is
one.
There
are
different
types
of,
at
least
in
the
browser
world
in
in
at
least
in
app
dynamics.
You
know
we
have
we
differentiate
between
ajax,
request,
page
request,
virtual
pages
iframes,
and
there
are,
you
know,
other
functionality
that
needs.
You
know
more
types
of
events,
so
we
we
could
start
defining
the
the
attributes
for
each
of
those
events,
standardize
them,
and
then
we
could.
C
I
don't
know
how,
since
there
are
multiple
teams
here,
I
think
we
will
have
to
figure
out
a
way
to
split
the
work
and
do
some
kind
of
a
project.
Management
to
you
know,
get
things
done
in
parallel.
C
So
sessions
is
the
is
the
tricky
part
and
ted
I'm
martin,
and
I
we
were
thinking
that
it
is.
I
think
today,
in
our
current
products,
we
do
repeat
things.
C
The
page
url
is
repeated
in
every
event,
but
now
we
have
an
opportunity
to
you
know,
take
some
common
stuff
out
and
and
then
not
repeat,
but
given
that
you
know
we
are
struggling
to
find
a
good
place
for
you
know,
keeping
this
common
attributes
somewhere
and
and
tigran,
and
hopefully
you
know
book
done
by
tomorrow.
I
think
tomorrow
he
will
join.
I
think
he
tigran
surely
agrees
sees
the
you
know
fit,
but
he
just
feels
that
you
know
there
isn't
an
easy
option
today.
C
You
know
either
you
wait
too
long
because
the
modifying
resource
you
know
for
accommodating
non-identifying
attributes,
although
it
is
seen
as
something
needed,
he
feels
that
it's
a
lot
of
work
and
therefore
he
says
that
you
know
get
started,
putting
it
in
every
span.
For
now
so
martin
and
I
you
know-
and
we
were
thinking
and
I'd
like
to
hear
from
you
all
that
you
know
what
is
the
way
to
get
started-
maybe
not
mark
things
as
stable,
but
you
know
come
back.
C
You
know
in
a
couple
months-
and
you
know
change
things,
but
with
the
with
the
requirement
on
maybe
technical
committee-
or
maybe
you
know
some
of
the
management
of
the
open
telemetry
that
that
they
should
prioritize
people
looking
at
you
know,
modifying
resource
or
are
accommodate
basically
addressing
our
need,
because
it's
not
something
this
group
can
effectively
handle.
It
has
to
be
more
people
involved
beyond
this
group
and
for
others
you
know.
Unfortunately,
it
may
not
be
a
priority
as
it
is
for
us,
so
you
know
we'll
need
you
know.
C
Your
guidance
to
you
know
make
a
case
for,
for
somebody
else
to
you
know,
look
at
it
at
priority
and
then
you
know
we
will
get
started
we'll
get
going
and
then
we
can
come
back.
The
other
problem
is,
you
know
the
the
api
will
change
based
on
where
the
data
is
going
to.
C
A
Yeah
I
I
totally
agree
that
session
that
there's
kind
of
like
two
bigger
picture
things
this
group
ended
up
needing
to
address
outside
of
just
defining
what
we
would
call
like
the
semantic
conventions
for
rom,
like
the
just
defining.
What
all
the
events
you
know
should
look
like
how
how
everything
should
get
reported.
One
is
because
there's
no
good
place
to
put
sessions,
we
we
are
stuck
trying
to
figure
out
how
to
sort
out
resources,
or
you
know,
instrumentation
scopes
or
something
like
that.
A
The
other
thing
that
we've
gotten
roped
into
is
defining
the
logging,
slash
events
api
for
open
telemetry,
since
we
need
that
thing
to
be
put
in
place
before
we
can
realistically
get
rum
fully
baked
in
so
so
those
are.
Those
are
two
basically
two
oteps
that
are
kind
of
prerequisites
for
the
rest
of
the
the
oteps
that
we
want
to
submit
and
and
get
approved.
A
It
seems
to
me
we
need
to
bake
an
otep
that
either
fixes
how
resources
work
or
or
otherwise
you
know-
confirms
that
we've
got
a
place
to
put
sessions
and
we've
got
to
get
a
logging
api
approved,
and
once
we
have
those
the
rest
of
our
oteps,
I
think
are
are
fairly
straightforward
or
at
any
rate,
don't
really
need
a
lot
of
approval.
A
I
I
don't
predict
they
will.
There
will
be
much
trouble
getting
approval
for
the
rest
of
the
stuff,
because
most
of
that
approving
will
be
deferred
back
to
the
subject
matter.
Experts
in
in
this
group
basically
will
get
people
added
as
spec
approvers,
specifically
for
this
area.
That's
the
thing
we
you
know
we
try
to
do
is
expand
the
number
of
approvers
on
the
specification
to
include
subject
matter
experts
for
various
areas,
so
I
imagine
people
from
this
group
would
become
who
are
willing
to
time
or
would
become
spec
approvers.
A
For
you
know
anything
client
related
which
will
be
helpful
when
other
people
potentially
come
in
later
and
are
like.
I
want
to
improve
or
add
or
change
how
rem
works
in
open
telemetry.
A
You
know
having
people
from
this
group
who
are
part
of
the
original
proposals,
be
pingable
on
github
to
to
have
a
look
at
those
future
proposals
would
be
great,
so
I
don't
see
any
any
real
trouble
there.
The
logging
api
honestly,
I'm
not
seeing
a
lot
of
trouble
there
per
se.
It
seems
like
when
we've
been
talking
to
that
group,
we're
like
fairly
on
the
same
page
after
some
initial
discussions
about
whether
events
are
a
good
idea
or
not.
There
seemed
to
be
agreement,
so
I
don't.
A
I
don't
anticipate
that
being
a
a
tricky
proposal,
however,
because
it
is
kind
of
like
a
big
deal.
You
know
you
know
I
I
feel
like
there's
still
room
for
some
surprises
to
show
up
the
the
hardest
thing
really
does
seem
to
be
sessions,
so
we
did
finally
start
getting
a
lot
of
attention
from
the
tc
members
who,
I
think
mattered
the
most
when
it
comes
to
that
which
is
tigran
and
and
bogdan
seem
to
be.
A
You
know,
they're
very
old-school,
members
of
open
telemetry
and
I
think
care
the
most
about
about
that
fundamental
piece.
It
seems
like
there
was
some
initial
confusion
about
like
the
scope
of
sessions,
and
you
know
why
sessions
couldn't
just
be
a
trace
level
attribute,
which
I
think
comes
from
backend
developers.
A
Seeing
you
know,
back-end
developers
run
services
that
concurrently
handle
lots
of
totally
unrelated
things
and
so
from
their
perspective
sessions
seem
like
transaction
level
context.
So
I
think
there
was
some
confusion
there
about
getting
getting
people
up
to
speed
as
to
how
the
world
looks
from
the
client's
perspective,
where
all
activity,
all
of
it
100
of
it,
is
related
to
a
single
user
and
all
the
activity
needs
to
be
captured.
So
it
can
be
replayable.
A
That's
to
me
why
it's
conceptually
wrong,
in
my
opinion,
to
to
just
go
sprinkling
the
session
id
around
as
like
attributes
all
over
the
place.
There
was
some
a
debate
around
like
efficiency,
where
we
were
saying
it's
not
efficient.
A
I
think
there
was
some
confusion
as
to
whether
compression
would
just
magically
solve
our
efficiency
problems.
A
Thank
you
nev
for
for
doing
some,
some
quick
write-ups
about
in
slack
about
like
why
that
just
was
was
a
non-starter
basically,
but
I
then
tried
to
kind
of
change
the
move,
the
conversation
away
a
bit
from
just
would
it
be
efficient
or
not
to
because
I
don't
actually
think
that
should
be
a
a
core
concern
when
it
comes
to
our
data
model
like
I
actually
think
we
need
to
be
developing
a
data
model.
That's
that's
coherent
for
people.
A
You
know
and
then
hope
it
gets
cleaned
up,
but
that
would
we
would
actually
like
lose
something
conceptual
if
we
did
that
when
machines,
when
we
try
to
apply
machine
analysis
to
this
data,
having
that
data
be
very
well
structured
and
being
able
to
differentiate
between
these
different
contexts,
I
think
is
really
helpful
and
that's
another
reason
in
my
mind
why
something
is
important
as
a
session
id
shouldn't
just
be
mixed
in
with
like
event,
attributes
and
and
span
attributes
it.
It
doesn't
seem
great.
A
So
I'm
not
sure
because
I
missed
the
meeting
last
week.
I
think
bogdan
showed
up
to
a
meeting.
So
I'm
not
I'm
not
totally
sure
where,
where
we're
at
with
resources,
I
did
have
a
look
at
the
dock
and
I
haven't
seen
any
new
comments
from
bogdan
or
tigrin
beyond.
A
I
think
tigran
at
least
I
think
coming
around
to
maybe
not
approving
updatable
resources,
but
at
least
I
I
feel
like
he's,
he
got
what
were
what
we're
up
to,
and
there
was
some
agreement
that
it's
not
just
about
efficiency
and
some
of
these
other
things
I
just
talked
about.
So
I'm
curious.
If
other
people
know
more
than
I
do
about,
maybe
where,
where
those
two
guys
are
at
as
far
as
updatable
resources
being
being
something
they
would
approve.
C
Yeah,
I
think
bogdan
certainly
agreed
that
sessions
fit
in
resources
in
in
a
resource,
but
he
he
reviewed.
You
know
our
change,
our
poc,
you
know
where
we
were
trying
to
update
the
resource
and
he
pointed
out
flaws.
Okay,
great
made
sense.
So
so
I
think
he's
at
a
point
where
he
he
definitely
agrees
that
there
is
some
need,
but
he's
not
sure
how
to
address
it.
C
So
I
think
I
think
both
of
them
are
not
clear,
so
they
are
trying
to
give
us
alternatives
on
on
how
to
you
know,
get
going
yeah.
A
Yeah,
it
does
seem
to
me
that
I
mean
we've
been
really
focused
on
session
id
and
but
I've
been
suspicious
that
there
are
actually
other
resource
level
attributes.
I
think
you
know
page
url
and
stuff
like
that
have
been
brought
up.
I'm
curious
whether
there
are
in
like
the
world
of
mobile
clients.
A
If
there
are
things
we
would
see
as
attributes
that
potentially
change,
I
don't
I
don't
know
quite
what
they
would
be.
Maybe
I
don't
know
the
accessibility
of
like
location
data,
for
example,
or
like
language,
preference
and
things
like
that.
But
those
also
seem
like
things
that
would
be
resources
that
might
might
change
time
zone.
But
again
I
don't
I'm
not
an
expert,
so
I
don't.
I
don't
have
like
a
list
of
things.
A
You
know
mobile
clients
like
report
today
that
that
would
be
in
that
list,
but
it
would
be
helpful,
I
think,
to
maybe
clarify
beyond
just
sessions
what
the
other
ones
are.
I
think
the
other
really
important
question
that
was
brought
up.
I
I
have
faced.
We
can
sort
out
the
details
about.
A
You
know
how
updatable
resources
and
a
resource
provider
should
work
under
the
hood
and
and
issues
around
like
thread
safety
and
and
all
of
that
stuff.
I
have
faith,
we
can
sort
all
of
that
out.
A
I
do
think
there
was
a
good
question
about
what
there
is
essentially
what
you
might
call
a
race
condition
between
something
updating
the
resources
in
the
background
and
any
stateful
telemetry
coming
out
of
the
system,
which
is
like
spans
for
the
most
part,
and
I
think
that's
that's-
maybe
something
we
would
want
to
to
address
there
like.
Are
there
we?
We
can't
stop
people
from
just
updating
the
resources
all
over
the
place,
but
it
would
be
good
to
understand
like
how
those
things
should
relate.
A
One
thing
that
comes
to
mind,
for
example,
is
you
know
if
a
span
starts
and
then
a
span,
and
then
we
change
the
resource
right.
We
change
the
session
id
and
then
you
continue
to
create
span.
Events
after
you've
changed
that
id.
If
those
were
span
events
attached
to
the
span,
then
they
would
have.
They
would
be
bucketed
in
with
the
old
session
id
like
the
old
resources
that
the
span
was
attached
to
when
it
started.
A
So
I
do
think
there's
there's
some
little
details
there
that
that
we
should
think
about.
My
feeling
is
like
in
general,
like
probably
these
resources,
don't
you
sh
like
it.
There
there's
something
strange
going
on
if
you're
updating
the
session
while
a
whole
bunch
of
activities
happening
like
I
imagine
that
usually
there's
some
amount
of
synchronizing
that
goes
on
there,
but
I
think
that's
that's
just
one
area
that
that
we,
I
think,
need
to
flush
out,
regardless
of
where
we
stick.
E
Thank
you
yeah.
I
I
just
on
that.
I,
I
think
your
concept
of
the
resource
provider
ted,
where
at
the
span
creation
point
it
gets
given
the
current
resource
provider.
I
think
solves
a
lot
of
those
and
we
just
say
well,
if
you
want
to
change
them,
you
create
a
new
resource
provider
and
say
this
is
the
new
one.
So
all
new
events
moving
forward
get
that
and
therefore
it
gets
rid
of
the
that
particular
problem.
A
Yeah
yeah,
I
mean
it
having
a
resource
provider,
hand
out
an
immutable
set
of
resources
like
when
the
span
starts.
You
say
these
are
the
ones
you
get.
I
I
think
allowed
us
to
to
move
attribution
from
this
end
of
a
span,
which
is
where
you
would
end
up
kind
of
doing
it
with,
if,
like
the
export
pipeline
or
something
was,
was
attaching
this
stuff
to
the
start
of
the
span,
which
is
logical.
A
The
only
thing
I
think,
that's
like
a
little
funny
honestly
is
span
events
versus
logged
events.
But
again
that's
that's
just
like
like
an
interesting
question.
If
you
have
a
span
that
starts
here
and
ends
there,
and
then
you
have
a
bunch
of
events
that
are
attributed
to
that
span
right
like
event,
handlers,
for
example,.
A
Should
they
be
getting
the
the
old
session
id
the
one
that
the
the
span
has,
or
should
they
be
getting
the
new
one
if
they're
happening
within
the
context
of
the
spam,
does
it
am?
I.
C
Articulate
how
to
explain
this
to
bogdan
too,
I
think
tomorrow.
I
think
he
and
I
think
it
is
natural
to
consider
sessions
as
something
deterministic,
that
they
have
a
fixed
behavior.
But
to
me
sessions
is
more
like
a
you
know
like
a
rough
marker
on
on
a
timeline
right
and
it,
its
purpose
is
really
to
you
know,
get
a
view
of
user
activity.
C
You
know
what
is
the
user
doing
and
there
are-
and
it
excludes
a
lot
of
you
know-
background
calls
being
made.
Ajax
calls
being
made,
so
it's
possible
that
you
know
how
we
detect
the
session
timeout.
It
will
be
different.
You
know
at
different
times.
You
know
there
might
be
it's
possible
that
some
events
fall
off.
C
You
know
in
the
previous
session
some
might
fall
into
the
next
session,
so
that
can
always
happen,
but
it
at
least
gives
a
rough
indication
that
hey
at
this
point,
the
user,
you
know
started
doing
something
or
at
this
point
they
started
stop
doing
something.
So
that
is
the
requirement
you
know
for
us.
C
So
it's
possible
that,
like
you
just
pointed
out
that
you
know
a
span
started-
and
you
know
it's
part
of
you
know
session
one,
but
then
at
that
point
the
user
was
actually
away
and
it
was
a
background
call
that
was
initiated
by
you
know
by
a
script,
in
your
browser
and
and
and
therefore
you
know
the
session
timed
out
in
the
middle
of
you
know
that
you
know
that
span,
you
know
before
it
was
complete
and
therefore
the
rest
of
the
events
are
in
the
next
span,
and
that
is,
in
my
opinion,
is
is
okay.
C
C
It
gives
you
a
rough
marker
of
you
know
when
the
session
timed
out-
and
there
is
always
a
fuzziness
around
the
edges.
There.
E
Yeah,
probably
to
answer
ted's
question
a
bit
more
directly,
so
any
events
associated
with
this
band
will
have
the
session
id
of
the
span.
I
think
that's
just
it
like
if
you've
got
a
background
task
and
you
happen
to
wrap
it
in
a
span
they're
all
associated
with
that,
so
you
want
to
group
them
together
anyway.
E
C
Yeah,
actually,
I'm
working
on
the
log
api
as
we
speak,
and
this
thing
has
come
up
there
where
I
am.
I
am
creating
events
and
it
happens
that
there
is
a
span
context
active
right
now
right,
so
should
that
span
context
be
associated
with
that
event,
because
the
the
log
record
has
a
trace
id
span
id
field,
and
you
know
what
else
needs
to
be
associated
if
that
span
is
associated
with
that
event,
it's
possible
that
you
know
some
events
pick
up
resource
a
some
events
pick
up.
C
You
know
a
different
version
of
the
resource,
so
there
is
a
good
possibility
that
you
know
things
are
not
consistent.
A
Yeah
that
that
might
be
the
only
real
squiggle,
which
is,
if
you're,
going
to
have
events
that
are
associated
with
a
span.
A
I
mean
it
would
probably
complicate
how
the
exporter
works,
but,
but
that
that's
the
only
little
bit
is
like
do.
We
want
to
clarify
in
the
spec
that,
when
you're
batching,
these
resources
like
when
things
are
getting
associated
with
a
a
resource
set
should
should
we
clarify
that
you
know
if
events
are
associated
with
a
span,
then
they
need
to
go
out
in
that
batch
and
be
associated
with
that
resource
set.
Like
should.
A
Should
the
the
sdk
under
the
hood
do
work
to
try
to
ensure
that
consistency
remains
or
are
we
gonna
say
like
don't:
go
updating
the
resources
in
an
unsynchronized
manner?
If
you
really
care
about
synchronizing
what
data
goes
into
what
batch
of
resources?
A
I
think
we
could
take
two
approaches
there,
but
if
we,
if
we
do
want
to
say
that
there
needs
to
be
some
synchronizing
happening,
I
think
we
then
also
have
to
put
that
in
our
like
at
least
one
of
our
prototypes
to
show
show
how
that
would
actually
affect
the
exporter
pipeline.
E
Yeah,
I
I
just
want
to
clarify
something
because
I
I
think
we're
probably
talking
about
overloaded
names
again.
So
when
I'm
talking
about
events
in
spans,
I'm
talking
about
you
say,
span
ad
event
as
opposed
to
a
rum
event
yeah,
I
I
think
the
rum
event
api
should
not
be
using
the
span.
Add
event
it
it.
It's
it's
the
case
with.
A
There's
also
yeah,
so
there's
this
middle
ground.
That
shows
up
when
we
add
the
logging
api,
which
is
in
general,
the
the
way
this
should
work.
Is
you
just
say:
I'm
I'm
logging
an
event
and
that's
it.
However,
the
under
the
hood,
the
sdk,
will
have
access
to
the
full
context.
That's
one
of
our
you
know.
Requirements
in
every
language
is
that
the
these
open,
telemetry
apis
always
have
access
to
the
entire
context,
which
is
in
most
languages.
Where
context
is
something
in
the
background.
A
That's
that's
trivial,
okay,
so
it's
it's
it's
trivial
for
the
most
part
to
say
that.
But
basically
what
happens
is
you
want
to
automatically
associate
an
event
with
an
active
span
if
there
is
one?
So
basically,
if
you
say,
I'm
logging
an
event
under
the
hood,
the
sdk
when
it
receives
that
log
event,
while
while
on
that
same
thread,
in
that
same
context,
it's
going
to
check
in
the
context
object
and
be
like.
Is
there
an
active
span
right
now?
A
If
there
is,
then
I'm
going
to
associate
this
vent
with
the
span,
because
it's
happening
in
the
context
of
the
span?
We
do
a
similar
thing
with
metrics,
where,
if
someone
you
know,
counts
a
metric,
we
might
include
the
trace
id
as
an
exemplar
associated
with
that
metric
and
the
end
user
doesn't
have
to
think
about
this
or
care.
It
just
happens
automatically
yeah.
So.
A
Yes,
so
so
this
is
an
inconsistency
with
open
telemetry
that
we
have
to
sort
out
which
is
before
we
only
had
span
events
which
live
in
the
span
data
structure.
Now
we
have
a
a
new
telemetry
signal
called
logs,
where
they
all
just
go
out
the
door,
and
there
is
as
if
you
look
at
the
log
structure
as
part
of
the
spec
there's
a
trace
context
associated
with
each
event.
A
So
we're
back
to
our
old
problem,
which
is
they
they
can
go
out
the
door
immediately.
But
then
you
would
have
a
a
duplication
of
the
trace
context
on
on
every
event.
E
A
Yeah,
that's
that's
true.
If
things
get
sampled
out
along
the
way,
then
you
know,
you've
got
you've,
got
some
blog,
that's
not
associate!
You
know
associated
with
the
sample.event.
It's
also
possible
going
forwards
to
start
sampling
logs
coherently,
which
was
never
really
feasible
when
you
didn't
have
something
like
a
trace
context.
A
So
if
you
do
know
that
this
trace
is
been
sampled
out,
you
could
also
drop
all
of
the
logs
associated
with
that
trace
too
and
sample
them
that's
getting
into
like
a
future
world
where
observability
systems
are
a
little
more
integrated,
but
at
any
rate,
if
we
want
the
events
to
go
out
as
part
of
the
the
logging
pipeline,
they
can
go
out
the
door
immediately.
A
There's
just
this
issue
around
again
around
not
having
these
events
bounded
into
any
kind
of
context
where
we
can
avoid
duplication
of
things
like
all.
The
events
that
are
associated
with
a
particular
trace
or
span
right
now
would
have
to
have
that
information
essentially
duplicated
on
every
event.
There's
no
there's
no
higher
level
structure
in
the
logging
specification
right
now.
So
that's
somewhat
unfortunate.
A
B
A
And
then
there's
the
execution
context,
yeah
yeah
anyways,
that's
that's
just
a
thing
we
can
look
at.
I
mean
there
there's
also
a
solution
or
an
imperfect
solution,
which
is
we
well
as
I
put
this,
we
need
to
add
to
the
spec
and
explanation
for
how
you
convert
span
events
into
logged
events
and
vice
versa.
A
In
other
words,
it's
at
any
point
in
your
processing.
You
may
say:
hey
all
these
things
that
came
in
as
span
events
on
a
span.
I
want
them
in
my
logging
pipeline,
so
I'm
going
to
turn
them
into
logged
events.
Conversely,
you
might
say:
hey
all
these
logged
events
that
are
associated
with
a
span.
A
I
want
to
stick
them
on
to
the
tracing
pipeline
and
span
events.
If
for
no
other
reason,
then
it's
like
some
point
down
the
line.
You
might
be
like
teeing
off
into
two
different
systems
and
you
might
want
these
events
in
both
or
one
or
the
other.
So
we
need
to
figure
out
how
to
specify
like
how
they
should
be
moved
from
one
to
the
other.
That's
that's!
Not
a
big
deal.
E
A
Oh
really,
do
we
not
have
do
we
not
allow
nesting?
I
thought
I
thought
that
was
universal.
That
attributes.
A
Like
map
and
array
values,
we
added
them
to
attributes
everywhere.
I
kind
of
hope
we
did.
I
I've
been
trying
to
push
for
that.
We
just
have
one
concept
of
attribute
everywhere
and
we
don't
have
like
this
kind
of
mess,
which
we
started
with
even
more
of
a
mess
where
we
had.
I
think
resources
were
only
allowed
to
be
strings
or
something.
E
A
E
I
thought
that
was
one
of
the
reasons
we're
choosing
logs
yeah.
A
That
that
would
be
unfortunate
if
going
that
direction
meant
you
had
to,
you
had
to
flatten
everything
that
would
suck.
But
if
that's
not
the
case,
it's
it
still
puts
you
in
a
tough
spot
nev,
where,
on
the
one
hand
you
could
have
this
information
deduplicated.
A
However,
it's
going
to
delay
when
it
gets
sent
out
to
in
this
the
batch
that
occurs
after
the
span
ends
or
you
can
have
this
information
go
out
faster,
but
potentially
have
this
trace
context
info
duplicated
all
over
the
place,
which
I
don't
like.
So
that's,
that's,
maybe
one
one
more
issue:
we
wanna
we
wanna
look
at
either
fixing
in
in
otlp
right
or
maybe
that's
that's
just
on
our
list
of
things.
A
E
A
E
Sorting
that
out,
I
I
guess
to
circle
back
to
the
original
discussion
that
santos
and
martin
were
talking
about
in
terms
of
just
starting
and
then
coming
back
later,
to
try
and
put
it
into
resources.
I
I
think
that's
brought
with
danger.
You
know,
based
on
ignorance
of
the
way
he
was
talking
in
the
spec
meeting,
he's
against
any
form
of
mutable
resource.
E
A
A
Really
should
be
on
everything
right,
so
things
like
your
kubernetes
pod
id
or
something
like
that,
and
it
was
super
clear
that
if
we
gave
people
mutable
or
updatable
resources
like
even
like
sdk
maintain
like
like
people,
didn't
totally
think
through
how
bad
it
would
be
if
their
first
batch
of
data
was
was
poorly
resourced
yep,
especially
because
some
of
those
resources
are
identifiers
that
you're
gonna
use.
This
is,
I
think,
why
you'll
hear
josh
and
other
tc
members
talk
about
identifying
resources
versus
not
tigran.
A
A
I
think
a
solution
here
is
to
actually
maybe
say
in
the
spec
that
not
all
resources
are
updatable
to,
even
though
we
can't
pull
them
out
into
like
another
box,
we
can
at
least
write
down
in
the
semantic
conventions
which
resources
you're
you're
allowed
to
update
versus
which
ones
you're
explicitly
not
allowed
to
update,
and
my
other
hope
is
just.
Everyone
has
now
done
the
hard
work
to
figure
out
how
to
have
a
good
mechanism
for
being
able
to
asynchronously
fetch
some
of
these
resources
and
delay
starting
the
sdk
or
delay.
A
Looking
to
rework
it,
I
know
I
know
right
because
it
it
makes
there's
no
top
level
of
weight
in
javascript,
and
so
it
it
really
does
make
your
startup
look
awful.
E
Yeah
everything
everything
is
a
promise,
so
one
of
the
the
basic
changes
not
from
last
week
the
week
before
that
daniel
was
talking
about
was
currently
the
api
is
if
everything
returns
a
promise.
E
A
But
that's
still,
I
think,
that's
great,
that
that
would
certainly
clean
up
the
code.
I
just
think
when
we
put
this
into
the
spec,
we
also
need
to
write
something
down
in
the
spec.
That
basically
says
you
some
of
these
identifying
resources.
A
You
can't
update
them
and
you
can't
attach
them
late.
Basically,
right
like
really
clarify
to
people
that,
if
you're
gonna
attach
something
like
you
know,
a
process
id
or
a
service
id
or
a
pod
id
or
any
of
these
other
things
that
that
has
to
be
on
every
batch
of
data.
A
E
Why
I
like
your
resource
provider,
idea,
because
you
could
actually
have
a
late,
binding
resource
provider
that
effectively
can
be
doing
this
stuff
in
the
background
on
a
thread
if
it's
a
in
a
multi-threaded
environment
and
it
can
effectively
at
the
point
of
export?
Or
you
know,
packaging
for
transport?
That's
when
everything
has
to
be
fully
resolved
and
it
can
actually
hold
up
the
transport
if
needed.
A
Yeah
yeah,
I
think
that's,
maybe
slightly
different
from
what
I
was
thinking
as
a
resource
provider,
but
but
what
you
said
earlier
around
having
a
resource
type
be
having
an
asynchronous
resource
value.
When
you
say
key
is
kubernetes
pod
id
and
the
value
is
maybe
that's.
You
know
what
you're
saying
like
a
a
provider
that
maybe
the
thing
I
was
talking
about
could
be
called
like
a
resource
set
provider
but
yeah.
A
I
totally
agree
having
this
an
asynchronous
resource
type
allows
all
of
that
startup
nonsense
to
be
deferred
to,
if
necessary,
yeah,
if
yeah,
exactly
only
if
necessary,
can
be
deferred
to
deep
in
the
export
pipeline.
E
Yeah
and
I,
and
it
gets
away
from
having
to
then
define
this-
is
the
set
of
resources
you
can
and
can't
change
by
just
saying.
Well,
you
just
give
it
a
different
resource
provided
yeah.
My
concern
with
in
the
specs
saying
you
you
cannot
change
this
is
that
evolves
into
okay.
We
must
enforce
that
that
the
user
never
tries
to
change
this
and
in
javascript
that's
just
a
nightmare,
because
it's
like
a
name
that
can't
be
yeah.
A
I
mean
I,
I
don't
know
that
we
have
to
enforce
it
in
code
it
you
know
we
could
enforce
it
as
like.
As
like
a
checker,
I
mean
with
all
of
our
semantic
conventions.
We
don't
like.
We
don't
enforce
encode,
that
you
described
an
http
request
correctly,
but
but
we
could
write
a
a
validator
that
that
notices
these
things.
Maybe
I
don't
know
it's
I
I
just
have
a
feeling.
There's
probably
needs
to
be
some
mortgage
around
that
because
of
this
tendency
for
people.
A
If
we
don't
tell
them
it's
bad
idea
explicitly,
then
they
might
go
and
do
it
right,
which
is
like.
Oh,
I
have
this
resource
provider
update
method,
so
I'll
just
use
that
thing
when
I'm
writing
my
my
resource
stuff,
but
if
we,
if
maybe
if
as
part
of
this,
we
we
also
push
through
asynchronous
resources
or
something
then
that
you
know
like
it's
just
it.
This
is
like
a
bad
tool
to
hand
out
to
people
without
a
big
warning
label
attached
to
it.
Basically,
but.
E
Yeah,
because
you
know
other
components
won't
be
expecting
those
changes
and
could
do
bad
things.
A
B
Okay,
so
with
all
that
said,
what
are
the
next
steps
that
we
should
do
like
when
I
think
there's
still
like
a
list
of
different
options
that
we
could
we
could
do
so.
A
I'm
I'm
gonna.
Look
at
the
instrumentation
scope
stuff
that
tigran
put.
I
did
at
first
glance,
it's
not
it's
not
sufficient
for
what
we
need,
but
it's
not
in
the
spec
yet
so
we
could
complicate
the
heck
out
of
instrumentation
scope
to
make
it
an
another
place
to
stick
this
stuff.
If
we
don't
want
to
touch
resources.
E
A
E
A
They
don't
get
handed
anything
when
they
get
started
right.
Every
piece
of
instrumentation
would
have
to
get
handed
a
session
manager
or
or
every
piece
of
instrumentation
would
have
to
get
handed
a
scope
provider
or
something
yep,
that's
not
in
the
spec
right
now
or
in
the
proposal.
So
so
I
don't
know.
If
we
go
that
direction,
there's
there's
work
there.
A
I
would
love
it
if
we
could
just
tigran
and
bogdan
that
updateable
resources
are
are
a
worthy
thing
to
put
into
the
spec,
and
then
we
go
write
an
otep
that
just
describes
how
all
this
stuff
should
work.
A
At
any
rate,
just
just
answer
your
question,
martin.
I
really
see
that
as
like
the
next
step
and
if
and
I'll
try
to
do
some
work.
A
Hopefully
I
have
some
time
today
to
to
to
at
least
for
tigran
write
down
what
all
would
have
to
happen
if
this
were
to
be
part
of
instrumentation
scope
instead,
since
you
know
he's
requested
that
as
an
alternative
proposal,
so
I'll
I'll
put
that
on
my
plate
to
to
just
write
down
that
proposal,
but
hopefully
we
can
convince
them
that
this,
like
resource
provider
approach,
is,
is
the
right
one
to
take
and
other
than
asking
them
to
come
to
this
meeting
and
otherwise
poking
them
on
slap
and
bothering
them.
I
don't.
A
You
know,
I
think,
that's
just
what
we
have
to
do
to
get
that
pushed
through
also
a
a
finish
finish,
a
prototype
that
passes
muster
for
cockton.
So
that's
that's.
Next
steps
sounds
like
bogdan
will
be
around
for
the
meeting
tomorrow,
yeah,
so
hopefully
we
can
get
that
clarified.
I
don't
think
he
green
can
make
it,
but
at
any
rate,
if
we
can
get
one
of
them
to
sign
off
on
it,
the
other
things
we
have
to
do.
A
It
sounds
like
an
otep
for
a
logging
api.
Someone
has
to
write
that
I
don't
know
if
that's
something
you've
been
thinking
about.
Martin.
B
And
actually
santosh
was
saying
that
he
had
that
proposal.
The
draft
and
he's
gonna
do
that
so
awesome
great
yeah.
What
else
did
we
need
the
the
other
luck?
So
we
had
that
original
otep
proposal,
which
is
the
we
called
it.
The
data
model
otep
and
which
is
basically
just
gives
a
background
for
you
know
why
we
want
to
model
client
cytometry
using
events
as
opposed
to
just
you
know,
tracing.
B
So
it's
more
of
a
background
document.
Do
you
think
that
that's
still
worth
putting
out
there
as
an
old
tap.
A
Yeah,
I
think
the
way
I
see
us
wanting
to
structure
these
oteps
is,
I
think
we
need
one
for
updatable
resources
or
whatever
the
hell
we
pick
to
shove
this
session
into.
We
need
another
one
for
the
logging
api
and
then
we
need
a
third
one
that
yes
just
describes
how
rum
is
going
to
utilize
all
of
this
stuff.
A
I
think
it's
worthwhile
to
to
write
that
down
as
a
proposal.
That's
where
we
would.
We
would
write
this
other
stuff
down.
A
That
proposal
could
include
maybe
some
example
semantic
conventions
we
don't
have
to
define
all
of
them,
but
I
think,
as
part
of
it
like
be
like
here
here,
are
some
concrete
examples
of
the
semantic
conventions,
we're
gonna
start
adding
to
this
spec
based
on
this
proposal.
This
is
this
is
what
page
load
is
going
to
look
like
this
is
what
all
of
that,
just
enough
of
those
that
that
model
can
get
approved.
A
I
don't
predict,
I
predict
we
will
not
have
a
big
problem
getting
that
one
approved
once
the
other
two
are
and
then
the
remainder
of
our
work
that
we
could
get
cracking
on
is
just
to
to
exhaustively
define
all
of
these
events
in
a
manner
that
you
know
we
would
write
them
down
in
in
the
open,
telemetry
spec,
because
because
we
want
to
get
them
all
added
in
there,
so
that's
that's
something
somebody
could
start
working
on.
A
Yeah,
it's
just
what
are
the?
What
are
the
attributes?
You
know
that
you
want
on
each
of
these.
What
is
the
event
name?
You
know
pattern
and
all
of
that
stuff
we
can.
We
can
just
start
writing
those
down
if
someone
has
a
has
the
cycles.
For
that,
I
feel
like.
I
can't
do
that
part,
because
I
I'm
not
a
subject
matter.
Expert.
B
Yeah
I'm
like,
and
I
can
definitely
help
with
that
one
yeah.
So
I
think
also
one
thing
that
we
haven't,
I
don't
think
decided
exactly
on,
is
how
how
these,
how
these
attributes
are
gonna,
be
structured.
If
there's
going
to
be
like
a,
we
talked
about
having
like
one,
you
know
one.
Maybe
one
attribute
that
that's
nested
as
nested
values
or
like
multiple,
but
they
would
have
repeated
or
or
like
a
serialized.
You
know
blob
field.
A
Yeah
yeah,
that's
exactly
there's
a
bunch
of
details
there
that
probably
have
to
get
worked
out
so
yeah
yeah,
especially
when
it
comes
to
yeah
these
nested
data
structures
that
you're
getting
from
the
system
itself
right.
That
seems
to
be
where,
where
some
of
the
questions
are
right,
like
yeah.
E
I
think
we
started
this
in
the
data
model
proposal.
Didn't
we
remember,
adding
a
lot
of
comments
there
and
and
pushing
us
towards
the
the
nested
data?
So
I
think
we
have
a
couple
attributes
and
then
we
just
say
event
data
or
something
but
yeah.
We
still
have
to
go
define
what
that
event.
Data
looks
like.
A
A
E
So
we
just
want
to
say:
jason,
not
stringify,
that's
the
fastest
way
we're
gonna
be
able
to
like
get
it.
Serialized.
B
A
I
will
say
it
is:
it
is
feasible
when
it
comes
to
the
individual
semantics
to
my
suggestion
would
be
to
not
try
to
shoehorn
too
many
things
into
a
standard
way
of
reporting.
If,
if
there
are
real,
substantial
differences
between
how
like
browsers
give
you
exceptions
or
or
other
you
know,
particular
events,
if,
if
they're
different
enough
from
what
you
would
get
from
ios
or
android,
it's
totally
fine,
I
think,
to
make
distinct
conventions
for
each
one
of
those
things.
A
A
E
B
Okay,
well,
I
can,
I
can
start,
maybe
I
can
put
together
some
few
examples
of
you
know
a
few
common
events
in
the
weekend
as
a
starting
point
for
discussion.
E
Yeah
I
can,
I
can
help
there
too
well,
once
I
get
some
cycles,
I
can
help
the
last
couple
weeks
been
a
nightmare
yeah.
A
Imagine
there's
also
some
like
exceptions
in
particular,
and
errors
are
like
an
area
where
there
will
need
to
be
some
thought,
probably
because,
like
stack,
traces
are
like
very
heavy
duty
things
like
so,
however,
mobile
clients
and
whatnot
wanna
decide
when
or
how
they're
gonna
be,
including,
like
a
high
volume
of
data
versus
not
yeah
yeah.
I'm.
E
We
we
have
a
common
way
that
we
that
we
handle
it
across
languages,
that
we
can
add
to
the
proposal
so
awesome
and
we
just
limit
the
the
size
of
the
stack
race.
That's
really
the
only
way
you
can
handle
that
because
otherwise
it
just
becomes
a
nightmare
when
you've
got
multi-threaded
environments
going
deep.