►
From YouTube: 2022-04-12 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
Hey
martin,
I
have
to
leave
at
9
30,
so
I'll
drop
off.
D
A
So
I
know
you
and
martin
you
both
took
a
look
at
the
write-up
on
sessions.
Nev,
I
I
don't
know
if
you
got
a
chance
to
go
through,
it
did.
A
Okay,
okay,
so
so
so,
basically,
what
we
said
in
that
document
is
essentially
that
sessions
is
something
that
we
don't
want
to
make
it
a
default.
You
know
always
on
option.
A
Instead,
what
we
said
is
you
know
it's
something
that
is
available
in
the
in
the
stock
hotel
sdk,
but
it
should
be
something
that
people
will
have
to
explicitly
enable,
because
at
this
point
implementing
sessions
on
the
client
side
is,
is
we
don't
know
how
stable
of
an
implementation
we
can
get
so
until
we
do
prototyping
and
get
it
to
a
stable
understanding,
both
understanding
and
implementation?
A
You
know
it
would
be
kept
as
an
optional
feature
and
the
way
we
were
thinking
of
implementing
it
was
to
essentially
when,
when
you
opt-in,
essentially,
you
register
a
span
processor
and
at
the
same
time
you
also
generate
something
called
a
session
context
where
you
attach
some
information
about
the
session,
including
maybe
the
session
id
in,
and
you
keep
it
in
the
context
and
then
every
time
a
signal
is
emitted,
the
the
corresponding
processor,
whether
it's
a
span,
processor
or
metric
processor,
a
log
processor.
A
So
that
was
the
thought
and
I
was
supposed
to
do
a
prototype.
I
was
working
on
it,
but
I
I
ran
into
some
hurdles.
I
I'm
new
to
hotel.
That
way,
I
haven't
been
so
hands-on,
as
you
guys
are.
So
I
have
some
questions,
but
that
was
the
high
level.
You
know
overview.
B
Yeah,
so
so
what
I
would
suggest
about
the
prototype,
I
think
we
should
create
a
prototype,
and
what
I
would
suggest
is
that
we
extend
the
poc
that
we
started
with
with
martin.
A
Yeah,
so
the
question
I
have
that
the
problems
are
added
to
is
essentially
how
do
we
attach
something
to
the
root
context,
because
every
event
every
signal
that's
emitted
in
throughout
the
session
anywhere,
you
know,
needs
to
get
that
information
right
and
we
can
always
keep
it
in
in
a
separate
object.
That's
always
accessible
everywhere
and
then
pull
it
from
there
from
the
span,
processors
or
from
the
processor.
A
Maybe
it
should
that's
another
decision
point
so
attaching
to
the
root
context
was
something
that
you
know.
I
couldn't
do
it
very
easily.
A
So
any
thoughts
around
that
I'll
share
my
screen
and
show
you
what
I
tried.
B
Yeah,
I
suppose
we
just.
A
Took
this
xml
http
request
example
from
the
open
telemetry.js
and
in
this
example
at
the
beginning,
it
has.
A
So
when
I
started
the
span,
I
I
passed
this
so
when
I
create
the
session
and
start
it
it
it
starts.
It
gives
you
a
new
context
right
and
this
is
at
the
beginning.
So
this
is
the
initial
context
and
in
that
context
I,
when
I
put
the
session
id
it,
gives
me
a
new
context,
and
that
is
the
session
I
pass
to
the
start
span
right
and,
and
I
set
the
same
span,
I
use
the
same
context.
A
For
I
mean
I
use
it
to
pass
it
down
for
this
exact
scholar
and
what
I
noticed
is
for
this
ajax
call.
I
see
the
session
I
mean
when
I
in
the
in
the
processes
on
start.
A
You
know
I,
when
I
do
this
context,
attack
to
get
value.
You
know
I
get
the
value,
but
I
don't
see
this
on
every
span,
so
I
I
wasn't
sure
if
I
was
doing
any
mistake,
do
you
guys
have
anyone
any
thoughts.
C
C
In
web
this
context,
propagation
and
stuff
is
quite
tricky.
E
F
Yeah
yeah,
I
think
the
the
alternative
approach
is
to
use
resources
right
so
to
have
a
a
session
provider
where,
when
you
start
session
it,
you
know
it
sets
a
resource
on
the
sdk
and
the
only
tricky
bit
there
is
making
sure
when
we're
updating
resources,
if
we're
changing
resources
like
the
session
ideas
to
change
at
some
point
that
the
exporter
pipeline
is,
is
handling
that
well
and.
A
Sorry
to
interrupt
you,
but
I
thought
there
are
two
separate
topics
you
know
which
is
you
know
one
where
you
hold
it
in
memory.
You
know
so
that
it
can
be
retrieved
every
time
you
want
to
attach
to
a
signal,
and
secondly,
when
you
serialize,
you
know
where
do
you
want
to?
You
know,
keep
the
freshness
whether
it's
in
the
attribute
or
in
the
resource
yeah.
A
So
for
the
first
part
you
know,
I
was
initially
considering
the
context
to
keep
the
session
id
and
if
it's
it
doesn't
have
to
be
context,
it
can
be
anywhere.
It
can
be.
You
know,
another
object,
that's
accessible
everywhere,
that's
fine,
too,
but
I
think
that
that's
where
you
know
I
want
some
initial
opinions,
so
the
advantage
with
context
is.
A
It
could
be
specific
to
each
thread
right
like
tomorrow,
if
we
want
to
use
this
to
even
either
attach
it
to
each
thread
like
let's
say
on
the
browser,
it's
a
single
threaded,
but
on
the
on
android,
you
can
have
multiple
sets
so
by
having
by
using
context.
That
is
specific
to
your
your
thread.
F
Well,
I
think
it
either
needs
to
be
specific
to
the
execution
context,
which
is
what
a
context
is.
You
don't
want
to
say
specific
to
a
thread
right.
That's
not
that's
not
going
to
work
because
threads,
don't
match
execution
contacts
very
well.
F
F
F
In
other
words,
so
whenever
someone
is
grabbing
like
a
provider
like
a
you
know
a
tracer
provider
or
a
metrics
provider,
you
know
any
of
those
things
that
give
them
the
objects
for
for
making
all
of
their
telemetry
stuff.
Those
providers
are
all
attached
to
a
specific
sdk
and
that
that
seems
to
be
the
the
way
we've
seen
so
far
that
we
would
want
to
have
multiple
sessions.
F
The
reasons
why
you
have
multiple
sdks
running
in
a
system
is
because
you
have
multiple
independent
subsystems
running
at
the
same
time
that
are
like
independent
to
the
point
that
they're
actually
sending
their
telemetry
data
off
to
to
different
places,
which
is
something
dev
has
brought
up
as
a
reality.
E
Yeah,
so
so
another
way
to
describe
that
is
effect
you
have
like
in
a
web
page,
you
have
individual
components.
Those
components
are
owned
by
different
teams
that
might
have
their
own
telemetry
system
like
sharepoint.
You
know,
sharepoint
is
one
team,
but
individual
con.
Your
apps
on
a
within
sharepoint
go
elsewhere
or
microsoft
teams.
You
know,
yeah
individual
sub
components
go
get
reports
at
different
places.
F
Yeah
and
so
so
that
that
rules
out
having
just
like
a
global
which
is
good,
we
we
want
to
be
a
little
suspicious
of
of
true
globals,
but
but
it
does
mean
that
it
can
be
specific
to
to
an
sdk.
And
if
it's
specific
to
an
sdk,
then
sending
that
information
as
a
resource
is
a
lot
cheaper
than
attaching
it.
As
an
attribute
on
on
every
single
object.
Yeah.
C
F
I
don't
I
mean
I
think
you
have
to
have
a
valid
reason
and
I
think
something
like
a
session
id
might
be
a
valid
reason
for
for
making
it
mutable.
F
F
You
want
to
have
a
look
at.
How
do
you
ensure
that
that
the
the
right
resources
are
attached
to
the
the
right
batches
of
data?
So
I
think
there's
just
some
trickiness
there.
F
And
so,
if
you
want
to
say
that
it's,
you
also
have
an
issue
with,
like
you,
change
the
resource
and
any
span
that
that
ends
after
you've
changed
that
resource
basically
is
going
to
get
that
resource
attached
to
it.
F
A
Essentially
so
there's
one
more
option
that
was
recommended.
Somebody
recommended
recently
was
to
look
at
the
scope
and
the
scope
today
doesn't
have
attributes,
but
I
think
tigran
had
a
ticket
to
add
attributes
at
the
scope
level
and
if
and
that's
still
being
worked
out.
So
if
that
is
not
immutable,
could
we
could
that
be
appropriate
here?.
F
Well,
what
do
you
mean
by
a
scope?
Instrumentation
score
right,
so
that
would
mean
that's
a
static
scope,
though
that's
not
not
dynamic.
As
far
if
you're
talking
about
instrumentation
scope,
you're
saying
like
when
you
create
a
new
tracer
object
right
yeah,
like
a
new
reference
to
a
tracer
and
a
piece
of
information
instrumentation,
you
could
attach
a
bunch
of
information
to
that
tracer
like
what
is
the
library
it's
reporting
on.
What
is
the
version
of
that
library?
F
Maybe
a
bunch
of
other
attributes
that
are
going
to
be
constant
with
like
every
piece
of
data
that
tracer
admits.
So
then,
when
you
say
start
span
on
that
tracer,
it's
that's
going
to
like
get
all
of
those
attributes
automatically
yeah
same
thing
with
metrics
objects,
but
I
think
that's
that's
like
more
like
a
static
scope
which
would
be.
F
Yeah
yeah,
it's
more
like,
I
think
the
way
they
look
at
it
is
is
kind
of
like
a
scope
of
a
scoping
right.
Resources
are
are
just
like
all
of
the
static
context,
like
the
global
static
context
that
everything
gets
and
then
you
want
to
say
like
okay,
but
then
you
have
these
like
sub
components,
and
you
want
to
attach
basically
like
additional
resources,
but
just
to
those
components.
So
you
want
to
scoped.
F
That's
so
that's
how
that
that
thing
works,
but
I
think
the
thing
you're
talking
about
I
mean,
I
think,
if
you
start
with
resources
you're,
but
that
seems
to
be
the
closest
thing
we
have.
Basically
anything
you
come
up
with
that
doesn't
involve
attaching
this
as
an
attribute
to
everything
essentially
boils
down
to
being
a
resource.
You're
gonna
have
like
all
the
same
issues
as
making
resources
mutable,
which
is
what
I
was
saying,
because
that
approach.
We
should
just
look
at
extending
resources.
F
F
That
is
just
like
a
processor
that
you've
attached
to
everything
right
and
so
then,
when
you
update
the
session
id,
you
know,
that'll
still
be
like
sdk
scoped
right,
because
you
pass
that
processor
to
a
specific
sdk,
and
so
when
you
change
the
session
id
in
that
session
manager,
you
know
it'll
it'll
update
and
everything
will
will
get
the
new
attribute
stapled
onto
it.
So
that's
like
another
way
to
do
it.
I
think
that's.
F
F
A
F
Yeah
but
yeah
yeah,
it
does
seem
to
me
like
picking
a
crack
at
at
the
resource.
A
F
A
Efficiency
ted-
I
I
feel
very
strongly
about
you
know
talking
about
it
separately
because
that's
a
larger
topic,
it's
not
just.
C
A
A
Sorry,
what
I
mean
is
the
the
client
side
in
on
the
internet.
You
don't
want
to
send
big
payloads
right.
F
Yeah,
but
but
I
think
we
should
separate
out
different
kinds
of
efficiencies.
You
know
there's
one
kind
of
efficiency
you're
talking
about
which
is
like
a
compression
efficiency,
or
you
know
you
know
having
all
the
keys
loaded
up.
You
know
using
constants
for
all
the
keys
and
then
replacing
those
with
like
a
big
enum
list
and
having
a
lookup
table
on
the
other
side,
but
that's
like
a
little
bit
different
than
is
a
session
idea
resource
or
an
attribute,
because
de-duplicating
attributes
like
session
id
that
that's
like
that's
like
very
I
don't
know
I
personally.
F
A
Of
course,
I
think
the
problem
is
for
us
to
make
progress.
We
either
stick
with
what's
easy
or
or
if
it
has
to
be
in
the
resource,
then
I
think
who
should
we?
You
know
talk
to
to
to
get
some.
A
F
F
A
But
we
could
make
it
work
right.
I
think
it.
You
know
we
could,
you
know
hack
away
and
then
you
know
make
it
work.
But
then
our
client
instrumentation
is
is
a
lot
many
languages.
I
think
tomorrow.
A
I
think
somebody
recently
brought
up
that
they
even
want
to
instrument
the
desktop
applications
which
could
be
written
in
any
language
which
is
in
dotnet
right.
So
there
would.
This
would
need
to
work
in
multiple
languages,
not
just
javascript,
so
I
think
it
would
be
good
to
handle
it
at
the
spec
level.
I
thought.
F
Well,
but
you
to
make
to
make
a
change
of
that
magnitude,
you
need
to
include
prototypes
a
couple
languages
as
part
of
your
part
of
your
o-type.
No,
we.
A
Like
you
know,
do
we
want
to
demonstrate
that
hey
you
know?
Maybe
we
could.
We
could
demonstrate
that
you
know
having
mutable
resources
is
not
a
problem
and
does
not.
You
know,
need
synchronization.
Maybe
last
time.
A
Out
that
it
could,
you
know,
be
a
bottleneck.
F
I
think
the
the
main
thing
that
the
proposal
would
need
beyond
just
saying:
hey,
we
have
a
mutable
resource.
Now,
would
just
be
explaining
more
specifically
when
you
change
this
resource,
what's
going
to
get
the
old
resource
and
what's
going
to
get
the
new
resource
like
having
like
because
that's
what
has
to
be
in
the
spec
right,
you
have
to
describe
like
how
that
change
is
going
to
be
propagated,
and
you
know
like
there
are
some
options.
One
is
like
it's
just
sloppy.
F
The
next
batch
of
data
that
goes
out
gets
the
new
resources.
The
other
option
is
like
when
you
change
the
resource.
It
ends
the
current
batch
and
starts
a
new
batch,
and
your
pipeline
needs
to
to
just
be
able
to
to
do
something
like
that.
You
know.
F
It
but
one
thing:
yeah.
E
One
thing
to
keep
in
mind
in
terms
of
the
session
is:
you
may
have
effectively
multiple
apps,
you
know
which
have
their
own
session
ids,
but
they
potentially
want
to
share
the
same
batching
mechanism
so
because
they
all
go
to
the
same
back
end.
E
F
But
does
that
do
you
currently?
Are
you
currently
able
to
separate
out
the
resources
for
those
in
that
pipeline
today?.
E
Because
the
the
data
is
actually
effectively
duplicated
in
each
event,
yes,
there
is
no
global
level
dispatch
and
here's
a
bunch
of
shared
data
that
you
should
apply
to
everything
it's
a
case
of
his
event.
A
his
event
b
is
event
c
and
they've
all
got
if,
if
they're
all
the
same
session
id
the
session
id
is
in
there
three
times.
F
Okay,
yeah,
I
guess
I'm
a
little
confused
as
to
how
resources
work
in
that
situation
yeah.
But
you
know,
like
that's.
E
That's
the
way
you
you
know
in
terms
of
configuring
and
having
a
single
export
mechanism,
that's
global
resources
that
wouldn't
work
for
that
scenario.
Yeah.
That's
probably
what
I'm
saying.
So.
That's
the
only
way
that
we
can
get
sessions
out.
The
door
won't
work
for
everyone
and
like
even
when
you
talk
about
client
apps.
E
If
you've
got
like
a
you
know,
a
csharp.net
app,
you
could
have
different
nougat
packages
that
get
dragged
in
that
all
want
to
use
open,
telemetry
because
they've
been
instrumented,
but
they
they
just
want
the
data
to
be
different,
so
they
may
want
different
resources
or
a
different
session
id.
So
I
don't
think
resources
would
work
for
that
particular
case.
I
like
the
idea
of
processor,
but
that
does
mean
the
outbound
payload
will
have
duplicate
data
because
there's
no.
F
Shared
yeah
yeah
I
mean
I
don't
I
personally,
I
don't
the
this.
The
pipeline
you're
describing
sounds
crazy
to
me,
and
I
don't
I
don't
understand
it.
So
I
don't
even
understand
how
that
works
today,
unless
everything's
going
out
of
that,
even
though
they're
all
different
sdks,
they
all
have
the
same
resource,
but,
however,
that
works
today
I
don't
see
how
making
allowing
those
sdks
to
individual
sdks
people
have
initialized
to
to
update
the
resources
they
have
set
on
them.
F
I
mean
it
seems
to
me
like
it
would
it
would
work
out
the
same
way
like
whether
those
resources
are
mutable
or
static.
It
doesn't
seem
like
it.
It
changes
how
that
pipeline
works.
If
you're
able
to
to
make
it
work
today
then
have
a
shade
pipeline,
yep
yeah,
then
it'll
it'll
work
tomorrow.
When
you
add
sessions
to
that
thing,.
E
Yeah,
it's
really
what
I'm
saying
is
where
that
session
is
specified.
If
we
want
to
support
having
team
level
session,
ids
then
having
it
at
the
sdk
level
and
saying
this
is
the
only
one
that
that
may
not
work
or
may
not
work
for
everyone
pretty
work
in
general,
but.
A
I
think
if
you
look
at
my
document,
I
have
mentioned
the
concept
of
named
sessions
where
you
can
have
simultaneously
multiple
sessions
with
you
know
with
different
names.
So
I
think
that
might
apply
to
you
know
your
situation.
F
That's
why
we
need
to
that's
why
we
need
to
do
a
prototype
of
this.
In
I
mean
I
think,
starting
in
javascript,
but
then
yes,
java
or
net
or
some
other
language
in
order
to
make
a
full
proposal.
We
need
to
to
to
do
that
stuff
and
yeah.
I
also
agree
that,
like
bringing
it
up
in
like
the
main
spec
meeting
ahead
of
time
too
and
being
like
hey
just
so
you
all
know,
this
is
like
the
direction
we're
heading.
F
This
is
why
I've
been
been
asking
for,
like
a
tc
member
to
start
start
attending
the
the
rum
meetings
right
so
that
we're
not
totally
surprising
people
but,
but
I
feel
like
it
either
has
to
be
this
or
we
have
to
get
some
suggestion
from
the
rest
of
the
spec
group
about
where
else
to
put
it,
but
I
don't
to
me
it
all
devolves
if
it's
like
sdk
scoped
attributes
that
can
change,
then
that's
resources
like
I
don't.
F
E
Yeah
yeah
and
it's
specifically
for
optimizing
resources
so
effectively.
We
only
have
one
set
of
timers
one
set
of
batching
and
stuff
like
that,
so
so
to
convert
that
to
open
telemetry,
open
gentlemen
who
need
to
support
that
which
is
where
I'm
coming
from.
F
Yeah,
I
think
I
think
that
actually
well
I'd
have
to
see
what
you
guys
are
doing,
but
I
think
I
mean
the
way
that
works
in
open
telemetry
is
actually
all
those
things
would
be
getting
the
same.
Sdk,
that's
sort
of
like
how
the
way
we
have
the
provider
model
right
where
every
package,
a
piece
of
instrumentation,
starts
by
saying
like
it
gets
handed
a
provider
and
it
generates
all
of
its
stuff
out
of
that
provider.
E
You're
in
context
and
then
the
the
app
is
then
keep
you
know,
it's
effective
becomes
a
a
single
container.
So
you
can
say
give
me
my
contacts
for
my
id.
F
E
F
F
Yeah
yeah,
but
that's
kind
of
how
like
open
telemetry
is
designed.
Is
you
can
pass
you?
Don't
you
could
go
grab
a
global
provider,
but
the
idea,
generally,
is
it's
dependency.
Injection
right.
You
know
each
library
or
package
gets
loaded
up
with
its
providers
if
it
cares,
or
it
has
some
mechanism
for
getting
loaded
up
with
those.
F
If
you
pass
it
and
if
you
don't,
then
it
falls
back
to
the
global
one,
but
that's
also
where
the
the
concept
of
scopes
show
up
as
well,
because
they're
saying
like
everyone's
going
to
have
like
the
resources
that
are
loaded
up
on
the
sdk
but
like
each
package
or
library,
can
then
decorate
their
stuff
with
like
additional
resources
that
are
only
going
to
apply
to
the
data
sent
out
of
that
library,
for
example,
yep
it's
just
it's
all
static
right
now.
F
The
presumption
there
is
that
stuff
is
like
static,
though
I
should
mention
it's
like
static
ish,
because
in
some
cases
these
resources
can
have
an
asynchronous
loading
pattern,
but
yeah
they're
still
a
little
bit
different
than
making
them
making
immutable
the
way
we
want
yeah,
but
I
don't
know
so.
F
F
I
just
you
know
the
more
we
we
swirl
around
this,
the
more
it's
like
these
are
resources,
but
resources
can
actually
change,
and
you
know
I
think
this
is
even
we've
identified
this
as
being
like
even
worse,
an
environment
like
a
mobile
client
like
swift
or
android,
where
you
know
it's
not
that
like
there's
a
page
reload
and
everything
reloads,
you
know
it's
like
you,
have
this
long
running
app
that
might
be
running
for
days.
F
That,
like
goes
to
sleep
and
wakes
up
and
and
when
it
wakes
up,
there's
potentially
like
a
variety
of
resources
that
might
have
changed
right
like
what
time
zone
or
location
the
thing
is
at
might
be
different
like
there,
I
could
imagine
mobile
clients
having
potentially
having
like
a
number
of
different
kinds
of
resources-
change.
F
I
don't
really
know,
but
I
I
suspect
that
this
isn't
just
sessions,
basically
that
and-
and
maybe
it's
also
true
for
long-running
servers-
that
that
some
aspect
of
how
they're
running
changes
again,
I
don't
really
know
sessions
the
one
we've
seen
so
far,
yeah.
E
Probably
an
another
example
would
be
some
sort
of
user
id
like
if
you've
got
a
long
running
app
the
user,
a
signs
in
you've
got
some
sort
of
aliased
id
for
them.
They
sign
out
another
one
signs
in
you
want
a
different
id
so
yeah,
and
that
would
also
be
where
you
you
would
want
the
session
id
to
change
so
you're,
not
linking
the
same.
F
Deal
yeah
yeah,
and
I
think
that
that
that's
like
a
clear
you
know
clear
example
of
like
why
figuring
out
the
the
definition
of
like
when
you
change
this
stuff
when
you
have
like
things
in
flight
and
you
change
update
one
of
these
resources.
What
what
happens
to
the
data
that
the
stuff
that
was
in
flight,
which
I
think
are
basically
just
spans.
F
I
don't
know
if
metrics
have
have
some
views
and
other
stuff
they're
doing,
but
but
certainly
you
could
have
a
situation
where
you
start
a
span.
You
change
the
resources
and
then
you
end
the
span
and
that's
like
a
little.
F
F
E
F
Yeah
and
that's
that's
the
there's
and
it's
actually
problematic
to
to
change
this
stuff
based
on
when
the
spans
start.
Potentially
I
mean
you
could
use
something
like
a
time
stamp,
but
the
the
reason
I
say
that
is
like
to
avoid
any
kind
of
like
locking
situation
and
a
lot
of
languages
like
that
sdk
doesn't
like.
F
F
The
the
general
pattern
for
multi-threaded
systems
is
like
the
span
lives
in
the
context,
object
right,
so
you
don't
need
any
locking
to
access
it,
and
then
you
know
if,
if
it
hops
threads,
it's
because,
like
that
context,
object
has
moved
across
a
thread
and
then,
when
you
end
a
span,
that's
when
the
span
is
handed
off
to
the
export
pipeline.
So
again,
the
export
pipeline
can
now
interact
with
that
span
without
any
locks,
because
it's
now
been
like
cut
off
from
the
user
code
being
able
to
to
call
it
and
do
something
to
it.
F
That's
just
like
an
implementation
detail
like
an
optimization.
We
already
have
around
avoiding
locks
that,
I
suspect
would
say
if
we
want
these
things
to
be
tied
to
like
span
starts,
might
might
be
a
little
complex
to
to
implement.
Potentially,
I
don't
really
know,
but
that's
my
I'm
just
a
little
suspicious
that
it's
that's
that's
trickier
to
do.
E
F
I
think
it's
all
doable,
it's
just
a
question
of
like
you
know
when
you,
when
you
ask
every
team
to
like
go,
implement
this
right
in
their
language,
how
much
of
their
existing
architecture?
Are
you
effectively
uprooting
and
rewriting?
And
and
if
it's
significant,
I
think
it's
just
part
of
not
you
know
making
everyone's
life
life
a
headache
is
we
have
to
like
do
enough
research
that
we're
able
to
like
propose
solutions
to
those
teams
yeah,
so
everyone's
not
stuck
like
resolving
the
same
same
puzzle,
yeah.
E
Or
potentially,
breaking
the
way
they've
introducing
breaking
changes
because
of
how
they
implemented
this
breaking.
A
F
Like
how
how
it
plays
out
that's
that's
sort
of
why
I'm
saying
like
we
need
to
like
prototype
this
stuff
and
kind
of
have
have
that
architectural
proposal
is
like
part
of
part
of
the
otep,
because
that's
it's
very
easy
to
just
say:
resources
are
beautiful
and
and
we're
going
to
stick
it
there.
That's.
C
F
F
Yes,
that's
that's
that
survived.
That
was
because
the
yeah,
the
one
thing
we
found
so
far,
was
just
that
resources
could
be
late.
Binding,
like
you
have
to
make
a
series
of
api
calls
in
order
to
get
the
resource,
but
once
you've
got
it,
then
it
doesn't
change
and
that
has
been
implemented
because
that
that's
a
reality,
but
I
suspect
how
how
sdks
have
implemented.
That
is
like
not
actually
gonna
work
necessarily
for
what
we
want,
but
we
could
have
a
look
at
what's
what's
already
there.
F
You
know
what
I
suspect
they
do.
Is
they
just
have
kind
of
like
a
promise
and
they
just
delay
sending
any
they
delay
exporting
any
data
until
all
of
those
like
promises
have
resolved.
Essentially
something
like
that.
F
But,
but
that
that's
the
thing
you
know
again
talking
to
the
the
javascripts
maintainers
you
know,
daniel
daila
was
heavily
involved
in
like
all
of
that
stuff.
F
So
that
could
be
helpful
if
we're
gonna
look
at
doing
this
in
c
sharp,
you
know
like
dot,
net
or
or
java.
You
know
we
could
reach
out.
You
know
reach
out
to
the
maintainers
there.
You
know
and
get
some
advice
from
them.
It's,
okay,
to
start
like
engaging
the
broader
community
around
this.
In
fact,
it's
like
a
good
thing
again,
so
we're
not
totally
just
surprising
everybody,
but,
but
I
think
it's
like
on
this
group
to
to
solve
those
problems.
F
Yeah,
I
I
think,
that's
like
a
js
specific
thing
like
another
big
project,
I
think
yeah
is
to
to
propose
like
separate
from
solving.
This
problem
is
propose
like
once,
metrics
and
logs
are
stable
in
the
spec
building
a
new
web
sdk
like
like
just
building
a
new
one
from
scratch,
that's
decoupled
from
the
node
one,
and
you
know,
but
yeah
you'll
need
to
resource
that
nev
like
we'll,
have
to
find
web
people
to.
E
Do
that
yeah
martin,
I
don't
know
if
you
were
there
last
week,
there's
a
presentation
by
ikea.
E
Yeah,
it's
so
effective,
they've
created
a
little
wrapper.
It
doesn't
use
open,
telemetry
apis,
but
it
exports
open
telemetry
as
I
think
how
it
works,
and
then
they
just
monkey
patch
stuff
too,
so
that
that's
one
possible
technique.
But
ideally
we
probably
want
to
like
you
know,
have
something
that
implements
the
api,
but
I
think
that's
probably
everything
else.
We
want
to.
F
Yeah
yeah
I
mean
the
api
is,
should
be
very
lightweight
like
I
don't
like
something
has
gotten
terribly
wrong
if
the
api
packages
are,
are
really
bloating.
Everything
because
like
what's
what's
in
there
they're
just
interface
packages,
but
but
I'm
sure,
there's
ways
to
get
the
sdk
size
down
by
writing,
like
replacing
all
of
the
like
library
based
code,
node
base
code
with
something
built
fit
for
purpose,
and
I
don't
know
how
much
the.
F
The
sdk
plug-in
processor
model
creates
bloat
and
problems,
but,
like
that's
the
other
thing
to
to
look
at,
it
might
be
feasible
to
offer
fewer
hooks
in
the
javascript
version.
If
that
helps.
E
F
F
F
I
think
we
can
make
it
happen,
I
mean
well,
you
know
I
mean
the
the
thing.
Is
you
bounce
it
back
to
the
tc,
where
it's
like?
Look
like
this
we've
looked
at
all
the
different
ways
to
do
it
like
you're,
either
like
creating
this
massive
duplication
by
stapling
it
as
an
attribute
everywhere
or
which
doesn't
work
for
us
or
it's
a
resource
like
there.
F
There
like,
isn't
really
an
option
c
you
know,
or
if
there
is
like,
then
the
the
the
tc
can
can
tell
us,
but
I
I
think
we
can
make
it
work
at
any
rate
like
next
next
spec
sig.
I
think
we
need
to
start
start,
bringing
it
up
with
the
main
spec
sig
and
say,
like
hey
everyone.
This
is
the
direction
we're
going
here.
F
Yeah,
I
think,
creating
a
spec
issue
also
yeah
would
be
helpful
describing
describing
the
approach
we're
taking.
Maybe
that's
like
a
good
short
next
step
is
saying
this
is
this:
is
the
direction
we're
going?
This
is
why
these
are
the
the
problems
we
want
to
work
out.
Yeah
yep.
B
I
had
a
bunch
of
other
topics
that
I've
tried
wanted
to
discuss.
I
we
have
in
that
session
doc.
That
santosh
has
there's
a
section
at
the
bottom
for
open
questions
and
concerns.
So
I
added
a
bunch.
B
We
probably
don't
have
time
for
all
of
them,
but
one
thing
that
I
wanted
to
kind
of
circle
back
to
because
we
already
talked
about
it.
A
little
bit
today
is
the
idea
of
having
multiple
supporting
multiple
sessions,
and
I
just
wanted
to
before.
B
Like
we
like
head
down
that
direction,
I
wanted
to
make
sure
make
sure
that
that's
really
there
really
needed
like
that's
because
like
in
like
in
the
past,
like
I
have
to
be
honest,
like
in
the
past,
like
most
of
the
use
cases
that
I
have
seen
or
when
people
talk
about
sessions,
it's
usually
like
a
single
session
id
so
like.
If,
but
I
hear
that
there
might
be
use
cases
with
like
complex
applications
where
you
might
need
multiple
sessions.
E
Yeah,
spas
definitely
do
like
a
couple
months
ago.
I
would
have
said
no,
we
manage
it
all,
it's
all
just
one.
It's
it's
a
cookie.
So
therefore
it's
across
tabs,
but
we
have
an
internal
team
who
affected
our
decorating,
the
the
page
printing,
the
page
like
a
spa.
E
They
throw
up
a
div
put
their
their
stuff
on
it,
set
up
their
own
session
id
and
when
they're
finished
they
tear
it
all
down,
but
the
page
is
still
there
and
they
could
drop
another
one
and
they'll
have
a
brand
new
session
id
for
that,
or
in
some
cases
they
may
have
multiple
divs
on
the
page,
with
multiple
session
ids,
so
yeah,
there
is
definitely
a
use
case
where
we
need
to
have
multiple
session
ids.
E
Sdk
in
this
particular
case,
no
that
they
they
are
actually
loading
up
a
completely
different
sdk
and
then
effectively
tearing
it
down,
which
is
one
of
the
big
things
I'm
working
on
at
the
moment,
is
supporting
complete
unloading
which
open
telemetry
doesn't
have.
At
this
point,
that's
one
of
the
things
we
will
need
to
do
with
a
web
sdk
getting
rid
of
all
the
all
the.
E
The
yeah
so
simplistically,
you
can
say
that
there's
a
page
here
when
they
click
on
a
on
a
link,
a
button
that
effectively
starts
a
new
session
that
they
want
to
track,
because
that,
for
that
team,
that
is
their
entire
float
and
when
it's
finished,
they
want
to
tear
it
on
there,
which
is
also
why
they
load
the
sdk
ability
separately.
So.
E
F
E
Yeah,
that's
still
it's
different
from
the.
F
Idea
that
over
the
course
of
in
sdk
existing
would
the
sessions
have
to
mutate,
and
it
is
kind
of
true
that,
like
it
does
seem
to
me,
like
that's
a
thing
that
doesn't
fully
mutate,
I
mean
there
are
other
examples
of
things
like
user
id
and
stuff.
Where
you
know
I
can
see,
see
that
changing
and
then
there's
the
mobile
situation,
long-running
mobile,
apps
and
desktop
apps,
where
you
do
have
to
have
a
concept
of
refreshing.
This
session.
A
E
If
you've
got,
you
know
a
client,
app
or
a
spa,
you
know
the
act
of
logging
out
should
reset
the
session
id.
Maybe
you
just
reboot.
F
E
Yeah,
if
a
web
page
is
easy
in
that
scenario,
you
can
reload
the
page.
But
if
you've
got
a
true
spa,
then
you
don't
have
that
luxury.
You
do
have
to
tear
the
whole
thing
down
and
start
again
or
change
it.
F
But
maybe
this
gets
back
to
specifying
it
where
I
think
our
job
is
to
describe
like
if
you
implement
this
feature
of
it
being
mutable
like
these
are
the
qualities
it
has
to
have.
This
is
how
it
has
to
affect
your
export
pipeline
or
whatever,
but
it
might
be
the
case
that,
like
this
just
doesn't
get
implemented
immediately
in
every
sdk.
F
You
know
it's
like
not
clear
that
the
go
sdk
or
the
ruby
sdk
needs
needs
to
implement
mutable
resources
at
this
time
right.
So
you
know
it
could
be
that
it's
just
that,
like
we
we,
this
is
an
optional
feature.
We
figure
out
how
it's
supposed
to
work.
We
get
it
implemented
in
the
handful
of
sdks.
That.
C
Sorry
can't
we
have
like
both
like
keep
like
the
inefficient
one
that
keeps
the
session
id
in
the
in
attributes
and
the
next
one
that
keeps
them
in
resource,
because
the
back
ends
can,
if
it's
not
in
research,
take
it
from
the
attribute.
F
F
The
short
answer
is
you
can,
if,
if
you
are
fine
with
just
not
having
your
session,
be
mutable,
you
can
have
this
today
right
like
that's
the
reality,
if,
like
you,
have
like
javascript
clients
today
that
want
to
have
one
session
per
page
per
sdk
load
like
that's.
That
requires
zero
changes
like
you.
Just
have
that
right
now,
like
just
session
id,
is
a
resource.
F
We
just
define
what
the
key
is,
and
you
know
how
you
generate
the
value
and
you're
done
so.
E
Do
we
have
anywhere
in
the
semantic
conventions
where
we
can
have
overrides
so
effectively?
We
have
that
as
a
resource,
but
then
you
can
have
an
attribute
to
override
a
resource
or
something
like
that.
F
Not
not
really
like
they're
describing
two
different
things
you
it
would
be.
That
would
be
more
where,
like
scopes,
I
think,
come
in
yeah,
but
again
those
are
static.
But
but
at
any
rate,
like
you
know,
martin,
like
you're,
saying
like
the
reality,
is
that,
like
maybe
for
like
90
of
rum
session
implementations
like
you,
you
aren't,
you
aren't
changing
this.
F
You
aren't
changing
this
session
id
after
the
page
is
loaded
like
that's
just
not
necessary,
and
so
we
actually
have
a
thing
today,
just
just
defining
how
like
how
you
should
go
about
initially
extracting
that
session
id
from
a
cookie
or
whatever
or
generating
one.
If
there
isn't,
you
know
whatever
we
have
to
describe
that
bit.
F
C
F
I
mean
zip
cord
doesn't
get
used
in
like
the
browser
and
like
that,
like
I
was
saying
frozen,
it
kind
of
yeah.
I
don't
the
adoption.
There
is
like
not
not
crazy,
big
but
yeah.
It's
true
like
they
just
staple
everything
to
everything
you
know
that's
like,
but
you
hit
a
wall
and
we're
we're
at
time
today.
So.
B
I
was
gonna
ask
just
one
one
request:
nav.
Would
it
be
possible
to
add
a
description
of
the
use
case
for
multiple
sessions
like
in
that
in
that
sessions
document
that
that
santosh
has.