►
From YouTube: 2022-04-13 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).
B
A
A
I'm
kind
of
I'm
leaning
towards
I
mean
from
all
that,
so
I've
listed
a
few
different
options
in
that
issue.
If
you
haven't
seen
it,
please
take
a
look,
and
I
know
that
we've
had
this
discussion
for
a
long
time,
but
I
would
like
to
kind
of
just
drive
it
to
some
kind
of
conclusion.
A
A
A
The
process
runtime
it's
already
in
the
spec
for
javascript.
It
already
says
that
the
process,
runtime
name-
should
be
browser
if
it's
coming
comes
from
browser,
so
I
think.
A
A
I
guess
we
could
so
we
had
other
thing
that
other
thing
that
we're
working
on
currently
is
we're
working
on
the
sessions
proposal
for
sessions.
We
had
a
working
group
yesterday
also
like
if
you,
if
you're
interested
in
that
discussion,
we'll
continue
probably
working
on
that
on
tuesdays.
A
E
Okay,
so
in
microsoft,
we're
not
using
open
telemetry
at
this
point
for
the
for
the
web.
So
internally
we
have
what
I
call
the
the
shared
manager
sdk.
So
it's
a
it's
an
sdk
which
partially
acts
like
a
single
single
singleton
container,
where
you
would
effectively
initialize
it
and
all
of
the
batching
and
timers
waiting
to
send
it
off
is
controlled
by
the
the
manager
and
then
from
the
manager.
E
You
can
say:
hey
give
me
my
instance
based
on
my
id
and
that
will
give
you
give
each
team
effectively
a
an
api
surface
where
they
can
start
recording
events,
and
those
events
are
then
effectively
funneled
down
into
that
that
single
batching
mechanism
with
their
own
set
of
attributes
and
then
send
off
as
a
single
blob.
E
This
is
currently
primarily
used
in
teams
to
minimize
the
number
of
timers
and
the
amount
of
you
know
stuff.
That's
matched
the
amount
of
memory.
That's
that's
used
by
default
teams
has
effectively
five
different
sets
of
teams
that
are
relating
the
team's
word.
So
microsoft
teams
has
multiple
teams
involved
in
creating
their
own
individual
components.
So
each
component
has
its
own.
E
D
So
what
what
is
different
among
those
five
instances.
E
E
So,
if
you've
got
team
a
get,
get
all
their
their
events
and
send
it
off
they'll
that
will
land
in
in
team
a's
back
end
team
b's
will
go
to
team
b's
back
end,
but
all
the
events
are
actually
sent
to
the
same
ingestion
point.
D
Right
right,
okay,
so
they're,
essentially
independent
apps.
It's
just
that
since
they're
running.
In
the
same,
you
know
application
instance,
you're
you're
for
the
purpose
of
efficiency,
you're,
you're,
batching
them
and
sending
them
together
to.
D
Yeah
so
correct
me
if
I'm
wrong,
but
the
way
you
know
that
would
translate
in
open
telemetry
would
be
that
each
of
those
five
instances
would
need
to
be
represented
as
five
different
resources.
D
So
there
would
be
some
resource
attribute
to
identify
each
of
those
five
instances
separately.
So
there
is
something
called
the
service
dot
instance
dot
id
that
you
know
that
is
recommended
to
identify
the
instance.
So
would
that
be
appropriate.
D
And
and
then
use
separate,
sdks
instances,
the
tracer
instances
or
whatever
sdk
instances.
E
Yeah
right
right
now
for
open
telemetry,
there
would
actually
be
separate
sdk
instances.
So,
therefore,
that
you
have
your
own
separate
batching
mechanisms,
okay,.
E
Currently,
it
is
just
this
instrumentation
key,
the
id
that
identifies
the
team.
It's
it's
effectively,
just
a
good.
D
E
D
E
Okay,
yeah
and
it's
it
was
for
the
purpose
of
efficiency
to
reduce
the
you
know,
the
the
cpu
load
and
the
memory
load.
D
And
and
the
the
frequency
of
how
how
the
events
are
generated,
is
it
vastly
different
between
each
of
them,
okay,
yep.
E
Yep,
it
depends
like
you
know.
Some
of
them
might
be
every
minute
because
they're
just
collecting,
like
you,
know,
memory
usage,
others
might
be.
You
know
if
you're
chatting,
it
might
be
you're
happening
often,
but
if
you're
not
chatting
and
nothing's
happening,
we
do
have
cases
where
there's
other.
If
you
have
other
apps
that
get
loaded
into
teams,
they
will
load
up
their
own
sdk
instance,
but
so
in
the
case,
when
you're
doing
a
video
call,
they
can
be
very
chatty
and
very
large
events.
D
Sure
so
a
common
batch
processor
may
not
be
feasible
right
in
in
in
this
case,.
E
Yeah,
when
they're
using
separate
sdks
that
don't
the
way
the
the
shared
instance
has
been
built,
is
teams
will
eventually
well
yeah,
I'm
working
with
them
so
that
they
will
eventually
expose
that,
so
any
applications
that
run
in
teams
can
effectively
instead
of
loading,
the
sdk
themselves
can
just
say
I'm
going
to
use
the
shared
one.
E
And
the
way
our
sdk
works
is
we
effectively
have
plugins
for
a
pipeline
so
which
is
probably
the
equivalent
of
a
processor,
so
each
team
can
configure
their
own
set
of
processes
for
how
they
want
to.
You
know,
decorate
the
events
as
they
go
through
the
system.
A
So
santosh
one
if
there
are
other
topics,
the
only
thing
that
I
can
think
about
to
talk
about
today
is
we
could
continue
talking
about
the
sessions
there
is.
There
is
a
list
of
questions
in
that
drug
that
you
have
oh
sure,.
E
E
Well,
in
the
case
of
the
shared
instance,
they
said,
but
that
was
actually
sent
by
the
same
one.
So
that's
where
we
got
into
the
discussion
yesterday
about
if
we're
using
a
resource
id,
if
it's
a
common
resource
id,
then
that
wouldn't
work,
but
if
there's
an
override
or
something
then
it
could
or
if
it's
just
included
in
the
event
which
is
effectively
how
so
our
internal
version
is
actually
built
on
top
of
application
insights.
So
it's
all
effectively
the
same
where
my
team
owns
both.
D
Okay,
so
I
I
mentioned
about
this
named
sessions,
I'm
I'm
not
like
super
strong
about
it,
because
I
think
it
seems
to
be
confusing
and
probably
unnecessary.
So
it's
the
depending
on
the
implementation.
You
know
how
it
works
out.
You
know.
I
was
thinking
that
if
it
is,
if
the
implementation
is
straightforward,
then
you
know
we
could
take
it
or
people
can
always
do
it
themselves.
D
But
if
the
implementation
becomes
tricky,
then
you
know
it
it,
and
I,
I
think
it
makes
sense
to
keep
it
in
the
in
the
default
sdk
so
that
you
know
people
can
use
it
rather
than
re-implementing
it
themselves.
D
Naming
sessions
allows
you
know,
handling
your
use
case
as
well,
where
you
know
each
in
the
shared
instance.
You
know
you
could
each
team
could
use.
You
know
a
different
name
for
for
their
sessions,
so
so
that
serves
for
that
purpose
as
well.
E
Yes,
I
haven't
had
a
chance
to
process
this
dock
yet,
but
essentially
that
could
work
at
the
discussion
yesterday.
I
have
a
to
do,
which
is
which
isn't
here
to
effectively
describe
what
I've
just
said
in
the
in
the
dock,
so
that
would
then
be
linked,
which
I
put
it
here,
because
I
thought
it
was
going
to
be
linked
with
the
name
sessions
as
the
potential
way
to
do
it
so
yeah
the
reason
I've
I've
got.
E
This
delay
is
effectively
I'm
working
with
another
internal
team,
and
I
have
been
for
like
the
last
six
weeks.
They
have
a
hot
deadline
coming
up
next
week
that
I'm
I've
gotta,
like
finish
writing
code
for
and
do
several
releases.
So
that's
my
focus
is
primarily
there
at
the
moment.
E
A
So
santosh,
I
have
a
question
about
this
naming
of
sessions,
so
that
means
that
we
would
be
sending
multiple
sessions
like
an
array
of
sessions
with
each
resource
right
under
on
the
resource
and
each
each
like
session
would
be
named.
A
But
then
then
the
implication
is
that
the
back
end
would
need
to
know.
How
would
you
know
like
which
session
to
associate
with
which
signal.
D
A
D
D
So
so,
let's
say
there
are
two
sessions
once
the
default
is
in
this
document.
I
chose
zero
as
the
default
session's
name
and
let's
say
you
have
another
session
foo.
So
on
the
same
signal,
if
let's
say
you
know,
or
let's
say
you
know,
you're
doing
a
checkout
right
and
during
the
process
of
checkout
you
know
some
event
occurs,
then
you
would
associate
that
event
with
both
the
sessions
so
the
session
id
of
you
know
both
the
sessions
would
be
included
in.
In
that
event,.
E
E
Why
wouldn't
we
just
resolve
the
name
sessions
locally?
So
therefore,
on
the
outbound,
it's
still
just
the
session
id,
so
the
back
end
hasn't
got
to
worry
about
doing
anything.
E
So
I
think
the
sdk
would
you
know
before
emitting
it
down
into
the
collector
or
batching
whatever
mechanism
it
would
resolve
the
named
session
id
to
the
actual
value,
because
that
would
because,
by
sending
it
this
way
here,
it
means
the
back
end
would
need
to
have
logic
to
pull
that
apart,
and
it
may
not
be
like
the
immediate
collector
it
might
be.
You
know
when
this
eventually
gets
down
to
the
the
user's
back
end
they're
going
to
play
with
it.
E
D
Yeah
I
mean
the
yeah.
The
use
cases
like
I
mentioned
earlier
are
are
simply
to
allow
for
additional
workflows.
Like
let's
say
you
know,
quite
often,
you
see
a
need
for
you
know
how
many
users
are
are
logged
in.
You
know
how
long
are
the
logged
in
sessions,
whereas
by
default
you
know
you
would
only
be
able
to
have
sessions
that
are
that
start
when
your
application
loads
and
ends
you
know
either
until
a
time
out
or
when
the
browser
closes,
rather
when
you
close
the
application.
D
So
if,
let's
say
somebody
wants
to
track
specifically
the
amount
of
time
they
are
locked
in
and
how
many
logged
in
sessions
are
there,
in
addition
to,
you
know
the
overall
currently
sessions,
so
so
that
use
case
you
know,
could
be
implemented.
You
know,
through
this
concept
and
and
and
often
there
are
also
like.
D
Dialogue
screens
right
where
you
walk
the
user
through
a
few
screens
and
for
like
like
check
out,
for
example,
card
checkout,
so
you
know
it
could
be
used
for
that
situation
as
well,
so
there
it
it
allows
for
some
additional
use
cases.
D
D
Yeah
yeah
so
span,
I
I
have
seen
very
often
people
use
spans
to
represent
expression.
You
know,
while
in
the
discussions,
but
it's
very
confusing
right
spans
are,
are
supposed
to
be
for
a
different
purpose
and.
A
So
nav
you
mentioned
that
you
you
have
like
each
when
you
have
multiple
applications
within
the
within
the
team's
site
and
each
of
those
individual
applications
can
have
its
own
session
id.
E
Yep
yeah:
that's
that's
different
to
this
name
session
concept.
It's
a
case.
There
is
just
a
session
id
and
so
so
the
attribute
would
just
be
session
id
for
every
single
team,
but
they
just
have
different
values.
E
In
in
the
kit,
so
in
the
case
of
the
the
shared
instance
effectively,
it
acts
like
five
different
sdks.
It's
just
the
common
part
is
shared
so
which
is
the
batching
mechanism,
so
each
each
instance
that
you
create
is
completely
isolated
from
each
other,
except
for
the
common
parts
which
decorate
the
event.
So
what
I
mean
by
the
common
parts
is
in
the
case
of
equivalent
to
the
resources
so
effectively
when
the
thing
starts
up.
It
says:
okay,
I'm
running
in
you
know
this
version
of
react.
E
I've
got
you
know,
you
know
this
device
name
or
whatever,
so
every
team
who's
using
it
would
actually
inherit
those
concepts,
those
con
that
context,
but
they
also
have
this
override
level.
So,
even
if
the
shared
one
defines
okay,
you
know
this
attribute
is
going
to
be
this
value.
They
can
say
well,
actually
I
want
that
attribute
to
be
this
completely
different.
One.
E
But
in
terms
of
the
session
id
the
session
ids
are
unique
to
the
instance
level,
not
to
the
shared
level,
so
it's
actually
managed
by
the
instance.
E
Don't
want
to
because
these
teams
are
completely
separate
if,
if,
if
the
teams
happen
to
be
sort
of
sister
teams
or
or
parent
child
teams,
effectively,
they'll
join
the
data
in
the
back
end.
C
E
Yeah,
in
terms
of
if
they're
like
got
a
bunch
of
extra
cpu,
then
yeah
that
will
impact
everyone
else
running
in
that
same
environment.
E
I
I
don't
know
how
teams
actually
made
it.
I
think
they
just
have
the
standard
metrics
that
they
just
send
back
in
a
regular
basis
and
report
which
objects
are
loaded
completely
separately
of
of
the
telemetry
pipeline.
E
So
they
know
which
apps
are
loaded
in
the
in
the
system
and
would
report
it
as
part
of
so
I
think
you'd
have.
The
environment
team
is
collecting
their
own
set
of
events,
and
they
would
be
reporting
that
it's
not
part
of
the
telemetry
system
to
track
all
the
different
components.
F
Yeah
we
have
a
similar
use
case
for
authorization
where
we
want
to
record
kind
of
two
different
sessions
depending
on
the
author
authentication
authenticated
state
of
the
user.
So,
for
example,
if
I
reach
the
log
login
page,
I'm
not
currently
authenticated
and
that
traffic
is
less
trusted
than
the
traffic
of
users
that
have
logged
into
my
application,
because
I
have
more
control
over
you
know
what
should
those
users
log
in
log
in
so
yeah?
A
A
F
So
yeah
we're
kind
of
doing
it
simultaneously.
You
could
also
just
track
it,
though
you
know,
with
one
the
whole
way
and
kind
of
labeled
it,
but
that's
not
really
how
our
back
end
works,
there's
different
ways
of
handling
that,
but
yeah
I
just
wanted
a
plus
one.
On
kind
of
you
know
that
that
ability
and
throw
in
another
use
case
which
I've
discussed
in
the
dock
as
well
yeah.
F
D
Okay,
so
in
in
this
case,
you
know
the
customer
would
be
implementing
this
session
manager
class,
where
you
know
they
would
be
calling
the
start
session
end
session
on
on
their
session,
because
they
would
know
and
and
then
our
implementation
should
change
the
session.
That's
present
in
the
context,
so
that
the
processors
can't
silently
behind
the
scenes,
attach
that
session
to
the
events.
So
so
I
think
the
api
supports
that
use
case.
A
D
That's
for
the
default
one
right,
so
so
the
the
session,
that's
part
of
the
default
instrumentation
and-
and
that
is
where
I
separated
in
this
table.
D
Like
you
know,
the
simple
session
manager
is,
it
starts,
but
it
never
ends
right.
You
know
you,
you
don't
know
how
to
markets
end,
whereas
the
inactivity
based
one,
you
know
you
would
have
to
implement
yourselves
in
both
the
cases
yeah.
I
think
we
would
have
to
expose
a
mechanism
to
retrieve
this
session
manager.
That's
currently
active
and
then
call
end
on
it.
E
Okay,
there's
probably
another
one
which
you
could
roll
with
the
start.
In
terms
of
when
you
say
start
session,
you
want
to
specify
whether
you
want
to
create
a
new
one
or
try
and
resume
any
previously
active
one
I
hydrate
from
a
copy
or
the
session
storage.
E
D
So,
on
the
the
semantics
of
this
session
manager
is
that
when
you
start
session,
you
know
it
is
supposed
to
reinitialize
the
session
context
and
and
then
start
using
a
new
session
id
and
in
the
purpose
of
that
is
to
have
a
clear
begin
and
end
boundaries.
So
you
you
would
be
able
to
get
the
length
of
your
session.
E
So
if
you're
a
simple
web
app
that
uses
postback
so
multiple
page
refreshes,
but
you
want
to
actually
track
the
same
session
id
across
multiple
pages
effectively.
The
sdk
is
going
to
get
re-initialized
on
every
page
load.
So
in
that
case
you
wouldn't
be
starting
a
new
session.
You'd
want
to
be
resuming
the
previous
one,
like
that's
really
the
simplistic
version.
D
But
that
we
we
are
going
to
we
are
talking
about
you
know
session
context,
persistence,
correct,
yeah,
so
that
your
your
session
context,
you
know,
will
come
back
when
you
navigate
to
the
next
page.
Are
you
supposed
to.
E
E
A
good
example
of
that
is,
I
used
to
be
on
the
identity
team
so
for
both
microsoft
account
and
office,
365
doing
all
the
ui
specific,
the
telemetry
stuff,
and
then,
when
a
user
logs
out,
you
actually
want
to
effectively
flush
any
session
that
you've
got.
So
in
those
cases
any
persistent
value
you
want
to
kill.
I
I
guess
you
could
say
in
the
case
of
a
persistent
session
manager,
you
the
end.
D
E
D
Statement
does
this:
is
this
what
you're
saying
too.
E
Before
calling
n
or
starting
calling
start
again
before
calling
end
will
end
the
previous
note
now,
what
I'm
saying
is,
if
you
call
start
and
then
sometime
then
you'll,
the
page
will
load.
You
call
start
again.
You
would
actually
get
the
same
session.
E
E
E
D
Okay,
to
avoid
confusion,
would
it
help
if
we
introduce
something
like
a
pause
session
and
resume
session.
E
A
Yeah
I
had
a
similar
question
on
on
that,
whether
like,
when
exactly
the
start
session
would
be
called
like,
would
be
called
every
time
or
only
like
when
you
explicitly
want
to
start
a
new
session.
D
Id
yeah
I
mean
those
are
the
things
that
are
abstracted
out
right.
I
think
each
of
these
different
session
manager,
implementations
will
have
you
know
a
different.
You
know,
behavior
of
when
they
start
to
stop
things.
E
Maybe
the
question
is
better:
idealized
of
this
sounds
like
a
difference
between
initialization
versus
starting.
So
are
we
saying
the
the
simple
act
of
getting
the
provider
effectively
automatically
creates
a
new
session,
or
so
it's
like
if
you're
brand,
new
fresh
and
you
get
the
session
manager,
do
you
have
the
session
id
or
not?
E
And
if
you
do,
then
why
would
you
even
bother
calling
without
start
session?
I,
I
guess,
is
a
better
way
of
phrasing
it
versus
do
you
have
to
call
it
call
start
session
to
ensure
that
you've
got
a
session,
but
then,
if
you
come,
if
you're
coming
back,
how
do
you
know
whether
you
need
to
call
start
session
because
you
may
have
already
may
already
have
an
active
session?
Does
that
make
sense.
D
Other
than
that
yeah
you,
you
could
call
it
in
the
constructor
of
that
session
manager.
In
this
beginning
too,.
E
Yeah,
so
to
avoid
confusion,
maybe
renaming
it
to
like
create
or
new
session
or
start
new
session,
or
you
know
something
that's
a
bit
more
explicit
than
just
start
yeah,
but
you
can
also
be
done
with
documentation.
So
it's
really
a
semantic
thing.
Is
that
you're,
depending
where
a
person's
coming
from
when
they
see
the
api
for
the
first
time,
what
what
their
assumption
is?
What
start
means?
So
that's
really
cool.
D
D
A
A
Yeah,
I
think
it
it
kind
of
goes
along,
like
with
some
of
my
other
questions
in
that
doc,
which
is
like
when
how
would
the
the
application
know
when
to
start
a
session,
or
how
would
it
because,
like
it,
cannot
know
when
a
session
ended.
D
You
will
have
some,
you
know,
set
timeout
or
something
to
you
know,
detect
whether
you
know
it
needs
to
be
ended
now,
and
you
know
so.
The
the
last
event
or
the
last
signal
you
know
that
went
to
in
that
session
is
probably
the
the
time
when
it
ended.
D
You
know,
but
let's
say
at
two
o'clock
was
the
last
time
you
used
that
application,
but
let's
say
one
hour
later:
three
o'clock:
you
start
using
it
again
and
then
you
notice
that
hey,
you
know
it's
been
a
while
and
therefore
I
need
to
start
a
new
session.
D
So
at
that
point
you
would
you
would
call
that
create
session
again,
which
will
which
will
start
using
a
new
session
id
so
yeah
and
and
then,
since
there
was
no
explicit
end
session,
you
know
on
the
back
end
you
would
you
would
only
look
at
hey.
When
was
the
last
time
I
received
an
event
with
on
on
this
particular
session,
and
that
would
be
at
two
o'clock,
so
you
still
have
to
have
some
back
end
logic
to
you
know.
Put
that
end
mark
on
your
session
object.
E
D
Actually,
I'm
I'm
sorry,
I
I
still,
you
know
not
able
to
process.
You
know
your
point
about
starting
or
resuming
the
session
starting
the
session
with
the
same
session
idea
as
the
previous
one.
D
So
you
mentioned
that
when
you
move
to
a
new
page,
when
you
navigate
to
a
new
page,
you
know
we
will
have
to
load
the
session
context
from
the
storage,
from
the
persistence
and-
and
you
know
that
would
resume
the
same
session
right
and
what?
What
is
the
use
case
where
you
would
end
the
session
but
want
to
resume
using
the
same
one.
E
Just
general
page
load,
so
I'm
I'm
about
to
drop
the
link
to
the
application
insights.
That's
my
manager
right
source
code
so
effectively.
This
manages
it
by
a
cookie.
The
cookie
has
a
a
session
timeout,
so
effective.
The
the
cookie
gets
given
a
time
so
effectively.
E
If
the
user
keeps
using
the
value,
then
we
can
keep
updating
the
the
session.
If
they
don't,
then
the
the
cookie
will
eventually
disappear.
So
the
next
page
load,
the
the
session
is
automatically
lost,
so
the
session
manager
then
goes
and
creates
a
new
id.
E
So
it
really
is
a
case
of
with
multiple
page
loads.
This
just
happens
automatically
under
the
covers.
The
same
session.
Id
is
resumed
as
long
as
the
user
has
enabled
cookies,
and
it's
persisted
up
until
I
think
it's
like
30
minutes
is
the
default
time
and
then
24
hours
for
the
you
know,
we
don't
try
and
create
a
new
one
for
a
day.
D
Yeah,
but
if
and
and
if
your
requirement
is
to
use
this,
you
know
continue
the
same
session.
How
do
you
even
get
that
id
that
was
previously
used.
E
D
So
so
that
is,
that
is
part
of
the
default
implementation
in
anyways
right,
I
think
it
will.
It
is
invariably
needed
all
the
time
with
the
behavior
that
you
are
describing.
E
D
Yeah
yeah,
so
so
I
that's
where
I
felt
that
you
know
you
don't
need
to.
Oh,
I
see
so
you're
saying
that
it
will.
There
will
be
an
initialize
method
on
the
session
manager,
which
would.
E
And
then
there's
an
optional,
which
is
the
like,
because
the
internal
version
is
built
on
top
of
this.
It
actually
looks
very
similar
where
the
user
can
can
turn
around
and
have
their
own
mechanism
and
say
actually
no.
I
want
the
session
id
this,
so
it's
that
the
code's
a
little
bit
messy
because
of
that.
E
E
D
D
C
D
D
We
we
can
use
a
like,
in
addition
to
service
dot
name.
You
know
we
can
use
the
service
dot
instance
dot
id
to
to
name
individual
tab
instance,
so
in
in
that
case,.
E
Yeah,
so
so,
internally,
microsoft,
we
actually
have
both
so
the
the
code
that
I
just
dropped
effectively
because
it's
using
a
cookie
or
the
session
storage.
It's
a
shared
case.
So,
regardless
of
how
many
tabs,
how
many
browsers
you've
got
if
you're
on
the
same
domain,
you
end
up
with
the
same
session
our
internal
version.
We
we
do
separate
or
have
the
option
to
separate
based
on
tabs
and
effectively.
E
We
do
that
by
having
a
prefix
that
we
add
so
instead
of
the
cookie
name
just
being
ai
session,
they
can
have
a
prefix.
They
add
to
that
and
we
have
a
version
where
you
can
actually
that's
a
good
based
on
when
the
thing
loads,
it's
initialized
with
a
new
session
id.
So
it's
perfectly
random
every
single
time,
so
that
every
session
is
completely
separate.
E
And
then
we
have
a
really
complicated
mechanism
to
rehydrate
those
from
any
previously
lost
sessions
that
were
stored
in
session
storage,
to
bring
them
back
into
the
current
one
and
still
flush
the
events.
It
gets
really
messy,
but
there
are
both
cases.
So
I
think
if
you
say
the
default
is
the
shared,
and
then
we
have
some
mechanism
to
identify
whether
you
don't
want
them
shared.
D
E
And
that's
purely
because
the
yeah,
you
know
at
least
in
the
browser
environment.
So
I'm
not
that
familiar
with
mobile.
I
believe,
though,
I
started
with
on
windows
phone.
When
I
first
joined
microsoft,
it's
a
case
of
in
the
browser
by
default,
you
tend
to
share
across
things
for
an
app
if
you're
using
storage,
you
probably
have
it,
you
know,
being
persistent
to
json
to
storage
based
on
your
app
id,
probably
not
your
current
runtime
id.
It
may
be
something
equivalent
for
for
there
but
yeah.
D
So
the
next
question-
I
I
I
don't
know
I
think
ted
strongly-
feels
that
the
session
details
should
be
sent
in
the
resource.
I
don't
have
any
strong
opinion,
either
ways.
E
Yeah
we
got
into
this
yesterday
if
it's
a
resource,
then
having
the
the
shared
case,
which
is
how
my
to
do
came
about,
gets
messy
because
the
resources
are
currently
immutable
but
yeah.
B
D
Yeah,
I
think
ted
thinks
that
we
should
try
it
out
and
then
suggest
a
change
to
the
spec.
D
I
think
the
underlying
issue
is
that
it
it's
repeated
in
every
signal-
and
you
know
for
for
the
purpose
of
deduplication,
he's
suggesting
that
we
keep
it
in
the
resource,
and
I
feel
that
you
know
there
are
anyway.
Our
data
model
is
kind
of
bloated
for
for
the
purpose
of
using
usage
in
the
mobile
and
browser
situations,
so
it
so
the
compression
technique
are,
you
know
something
to
address
that
you
know
should
be
should
be.
You
know
taken
up
separately
because
it's
it's
a
general
issue,
not
just
specific
to
this
session.
D
A
C
E
Maybe
yeah,
I
I
think
the
the
thing
I
brought
up
yesterday
was
potentially
introducing
an
override
capability
so
effectively.
There's
you
can
say
this
is
the
resource,
but
then
each
individual
signal
can
say
yeah
that
that
was
the
same.
But
this
is
what
I
want
to
use
might
be
easier
than
trying
to
change
resources
to
be
mutable
in
the
entire
thing
back.
D
Actually,
in
the
yesterday's
meeting
notes,
I
noticed
one
issue
that
was
mentioned
where.
D
Where
it
was
recommended
towards
the
end
to
have
two
types
of
attributes
identifying
and
descriptive
in
the
resource,
so
the
identifying
attributes
of
will
be
immutable,
whereas
the
descriptive
non-identifying
attributes,
you
know,
may
be
changed,
but
how
that
would
be.
D
D
So
yeah,
I
think
we
can
revisit
this
after
the
you
know,
end
of
our
prototyping.