►
From YouTube: 2022-04-19 meeting
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
A
B
A
A
Well,
I
don't
know
if
it's
gonna
be
just
the
two
of
us.
I
know
that
santosh
can
can't
make
it
today
and
ted
is
out.
B
A
Today
I
mean
I
have
two
updates
from
last
week,
so
santosh
has
been
working
on
the
prototype
for
the
api
for
sessions
and
I
linked
it
in
the
agenda
of
the
document
yep.
So
I
don't
know
that
we
have
to
go
through
it
here.
It's
it's
basically,
you
know,
what's
what's
described
in
the
document
in
the
proposal
document
that
he
has
so
maybe
take
a
look
at
it
and.
A
Yeah
and
the
the
other
thing,
the
other
thing
that's,
I
opened
opened
an
issue
yesterday
about
updating
resources
like
putting
the
session
attributes
on
the
resources
yeah
and
there's
already
comment
from
from
yuri
he,
and
he
disagrees
with
that.
So.
A
B
Yeah
I've
got
that
to
do
that.
I
had
probably
in
version
one
of
the
otep,
which
I
can
add
to
version
two
about
the
different
types
of
scenarios
with
different
scenario
ids.
So
I
should
hopefully
get
to
that
later
this
week,.
A
Okay
sounds
good,
so
that's
that's
pretty
much
the
topics
that
I
can
think
of.
I
don't
since
it's
just
the
three
of
us.
Maybe
we
can.
We
can
just
end
this
meeting
or
quinn's
training
too.
A
C
I'm
I'm
gonna
meet
with
them
later
this
week
to
kind
of
give
them.
You
know
a
rundown
on
how
openly
works
and
stuff
and
they
can
figure
out
who,
in
their
team,
can
they
assign
to
join
the
the
sig,
but
definitely
there
is
interest
yeah.
Now
I
was
going
to
say
for
the
multiple
sessions
and
things
they
have
use
cases
they
can
bring
to
the
table.
I'm
going
to
talk
about
all
of
these
things
that
they're
doing
so.
That
would
be
true.
A
Yeah
one
one
thing
that
I
was
was
a
little
bit
concerned
about
is
the
way
the
way
right
now,
where
we
have
it
prototyped,
is
that
the
site,
the
name
of
the
attribute
procession,
has
the
name
of
the
session
in
it.
So
it
has
like
a
session
that
the
name
of
the
session
and
then
id
so
I
wanted
to
just
check
like
if
that's
the
right
thing
to
do
like
if
we
should
instead
have
like
an
array
array
field
for
sessions
where
you
would
have
like
an
id
and
name.
B
Yeah,
I
think
it
would
be
okay,
you
don't
really
want
to
have
the
name
as
part
of
the
well.
The
session
name
is
part
of
the
name.
I
don't
think
this.
This
comes
back
to
where
we
put
it
like
so
yeah,
because
you
could
have
a
bunch
of
events
or
logs
that
effectively
have
a
different
session
id.
How
do
we
identify
which
session
id
does
that
particular
event?
Slash
vlog
belong
to.
A
So
are
we?
Are
we
gonna
have
scenarios
where,
like
you
have
you
have
two
sessions,
two
sessions
running
at
the
same
time?
Yes,
but
diff
yeah,
but
then
different
events
would
get
just
one
and
different
events
would
get
the
other.
B
A
B
I
don't,
I
can't
think
of
any
scenario
where
an
event
would
have
more
than
one
session
it's
effectively.
The
individual
events
belong
to
different
sessions,
where
ie
different
teams,
different
components.
B
A
So
you
wouldn't
have
like
if,
if
there's
a
you
know,
if
there's
a
global
event
that
couldn't
apply
to
both
sessions,.
B
Technically,
yes,
we
handle
that
today,
by
effectively
spitting
out
multiple
events.
I
see.
C
And
yeah,
I
think
the
distinction
probably
is
at
an
event
level.
Every
event
belongs
to
a
single
session.
That's
that's
it.
You
know
a
unique
session
or
something,
but
the
sdk
is
supposed
to
be
able
to
handle
multiple
sessions
in
in
the
play.
That's
a
scenario
that
we
see
a
lot.
The
other
thing
that
what
you're
asking
about
is
you
know,
is
there
a
global
event
where
we
need
to
say?
C
C
A
A
A
Yeah
I
yeah
I've
been
thinking,
I
think.
Until
now
I've
been
thinking
about
it.
A
little
bit
differently.
I
was
thinking
like
there
was
gonna,
be
one
event,
no
matter
what
and
they're
like
whoever,
but
I
guess
I
guess
that
event
can
be
it's
going
to
be
generated,
but
by
that
particular
sdk.
A
D
Yeah,
I'm
just
a
little
confused
at
how
how
that
will
work.
Has
it
been
elicited
in
the
other
dock?
So,
for
example,
if
will
there
be
a
default
sdk?
That
does
things
like
record
errors
and,
as
you
said,
page
views
and
things
like
that,
and
if,
if
that
is
the
case,
it
will
only
like
what
session
does
that
go
to.
B
I
kind
of
think
how
we
do
I'm
pretty
sure
today
effectively
that
error
message
gets
sent
to
everyone
who's
registered
in
our
shared
sdk.
So,
just
to
reiterate,
our
shared
sdk
isn't
on
open
telemetry
today,
so
we're
just
looking
to
make
sure
that
we
could
move
it
to
the
to
open
telemetry.
That's
why
we're
pushing
for
this
yeah,
because
it's
javascript,
we
don't
know
well,
we
technically
could
figure
out
by
walking
the
stack
race,
but
we
don't
bother
spending
the
cpu
cycles
to
find
out
where
their
source
is
so.
D
Right,
like
I
assumed
the
hotel
distro
we
build,
will
have
a
set
of
default
events
in
it.
Will
those
default
events
be
associated
with
a
a
single
session,
or
will
multiple
sessions
somehow
subscribe
to
those.
B
B
When
a
user
registers
that
they're
that
they
want
a
factory
an
sdk
instance,
that's
when
they
would
go
or
go
off
and
effectively
fire,
though,
like
the
pageview
event,
is
another
good
example
there
so
yeah,
while
the
sdk
itself
would
have
a
set
of
shared
instances,
it
is
a
shared
defense.
B
Probably
ajax
requests
are
another
good
one.
Where
effectively
the
sdk
will
be
listening
and
has
oh
the
words
escaped
me
monkey
patched
the
you
know
xhr
or
fetch
effectively.
Everyone
is
listening
to
that
and
that
gets
the
event
for
that
gets
duplicated.
A
B
A
B
B
And
there's
a
lot
of
the
instrumentations
rely
on
the
global,
which
is
where
things
start
falling
apart,
yeah.
So
the
the
way
our
internal
one
works
effectively.
We
have
an
sdk
which
we
call
the
shared
manager
and
it
acts
as
a
single
singleton
container
for
individual
instances.
So
whenever
part
of
the
the
page
or
a
component
wants
to
do
something
either
they
can
keep
a
copy
of
their
own
reference,
or
they
can
say
manager.
Give
me
my
instance
and
then
start
firing
events
with
it.
B
You
know
whenever
they
say
you
know
get
instance.
They
get
given
back
the
same
instance
that
they've
previously
created,
so
they
don't
have
to
call
get
instance.
They
can.
They
could
create
it
and
then
just
keep
it
themselves
and
then
just
use
it
directly.
B
So
that
would
be
equivalent
of
yeah
effectively
creating
multiple
hotel
instances,
which
today
would
have
you
know
multiple
batching
mechanisms.
So
it's
really
you
know
you
could
if
we
could
have
some
way
of
having
that
common
batching.
That
would
achieve
the
same
thing
just
to
save
memory
in
the
browser
and
and
the
necessary
timers
that
you've
got
to
say.
Okay,
I've
got
this,
I'm
going
to
send
it
off
in
like
two
seconds.
A
For
different
sessions,
then
like
we
would
need,
we
would
need
to
have
something
like
that,
like,
like
the
different,
basically
different,
different
different
api,
different
sdk
for
for
web.
That
would
support
such
a
scenario.
B
B
Where
does
that
sit
so
that
it
is
then
technically
possible
to
have
a
shared
transport
mechanism
instead
of
each
sdk?
That's
having
its
own
transport
mechanism.
E
A
A
Okay,
so
quinn,
quinn
and
stefano,
you
you
a
little
bit
later,
so
I
was
saying:
there's
santosh
has
worked
on
a
prototype.
A
I
linked
it
in
the
in
the
agenda
and
there's
also
an
issue
open
now
for
updating
resources.
So
I
I
think,
there's
if
you
have
want
to
take
a
look
at
it,
see
that,
but
it
makes
sense
to
you.
F
D
I
haven't
been
following
the
resource
dialogue
super
closely.
The
resources
is
still
the
the
instance
of
the
application.
A
A
And
it's
like,
so
I
think
we
we
talked
about
it
last
week.
We
because
the
session
session
information
is
is
mostly
the
same
for
first
for
most
signals
most
of
the
time.
So,
in
order
to
you,
know
optimize
the
payload
like,
we
think
that
it
should
go
on
the
resource
level.
A
But
the
problem
is
that
that,
like
the
session
data
can
change
in
the
lifetime
of
the
you
know,
the
application
running
or
the
sdk
so
and
the
resource
by
spec
is
currently
immutable.
A
D
A
It
does
so,
I
think
if,
if
I've
been
thinking,
you
know
I
I
was
under
the
impression
until
now
that
we
would
have
multiple
of
the
same.
We
would
generate
like
one
event
and
then
the
event
would
have
multiple
session
ids
on
it.
A
C
I
was
chatting
with
nev,
I
didn't
joined
the
wednesday
last
week's
wednesday
call,
but
you
know,
if
I
understand
understood
correctly,
what
never
saying
was
there
was
a
proposal
to
use
a
collection
of
resources.
C
A
I
think
in
theory-
yes
yeah,
so
you
would
you
wouldn't
need
to
have
so
you
have
like
in
the
in
the
trace
provider
like
when
you
initialize
the
trace
provider
like
you,
you
currently
give
it.
You
have
to
create
the
resource
so
like
you
would
have
to.
I
guess,
every
time,
every
time
you
create
a
session,
you'd
have
to
create
a
new
resource
and
then
somehow
tied
to
only
this
certain
events.
B
It
already
has
its
own
resources
in
there,
but
I
think
that
there's
two
wrinkles
one
is:
is
that
the
fact
that
we
want
to
be
able
to
have
multiple
session
ids,
which,
with
what
we've
just
mentioned,
is
a
potential
workaround,
but
the
other
one
is
because
a
session
id
can
change,
because,
like
when
a
user
logs
out
and
logs
into
an
application,
you
may
want
to
effectively
roll
the
session
id
to
keep
them
separate
and
resources.
B
Being
immutable
is
the
big
one
so
which
I
think
is
that
what
the
the
issue
is
two
two
thousand
five
hundred
is
that
what
they
talked
about?
I
haven't
looked
at
the
detail
yet.
A
Oh,
that's!
That's
just
that's
just
where
I
was
asking
like.
If,
if
we
could,
what
would
it
take
to
make
resources
updateable
in
the
in
the
respect,
yeah.
B
Yeah,
I
think
making
them
updateable
is
going
to
be
problematic
with
the
idea
that
ted
had
of
effect.
We
have
our
own
set
of
resources.
It
then
becomes
also
problematic
of
okay.
Well,
what
is
the
base
set?
Do
we
have
to
keep
a
copy
before
we
set
any
session
id,
and
it's
thomas
analogist
of
the
context?
The
fact
that
you
you
get
the
context
and
you
set
something
on
it
and
you
get
given
back
the
new
context.
I
think
that's
the
sort
of
thing
that
we're
we
want
to
do
with
the
resources.
B
A
A
There
was
a
there's
like
I
linked
in
that
issue,
to
a
different
discussion
that
happened
like
a
year
ago,
where
they
were
talking
about
making
resources
updateable,
and
I
think
there
was
a
proposal
or
an
idea
that
certain
sets
of
attributes
would
be
like
identif
identifying,
so
they
would
they
they
could
not
change
essentially,
but
there
would
be
like
a
additional
set
of
attributes
would
be
just
the
supplemental
and
those
you
could
change
or
add,
add
to.
A
I
think
that
would
at
least
help
with
with,
like
the
use
case,
for
you
know,
starting
sessions
or
adding
additional
data
to
the
session.
B
It
gets
messy
because
how
do
you
identify
which
ones
you're
allowed
to
update
and
how?
How
the
ones
you're
not
allowed
to
update?
I
guess
unless
they're
two
different
lists,
but
I
wouldn't
want
to
get
into
the
from
a
browser
perspective
having
a
list
of
names
that
you're
allowed
to
change
versus
a
list
of
names.
You're
not
because
strength
just
can't
be
compressed
easily.
A
Yeah
yeah
cool,
so
I
think
it
seems
like
seems
like
we've
been
with
this.
With
this
prototype,
we
need.
We
need
them
to
updated
to
allow
for,
like
have
like
actually
holding
multiple
resources
in
in
place,
so
that
different
signals
can
be
associated
with
different
resources.
B
Because
yeah,
I
think
when
we
spoke
to
daniel
last
week,
it
really
was
a
case
of
I
think
they
currently
pick
it
up
from
the
context
which
is
messy,
but
if
we
could
have
some
other
mechanism
of
setting
the
resources
on
the
you
know
the
span
or
the
the
thing
we're
about
to
go
and
do
right.
My
words
are
failing
me
today.
A
Okay,
I'll
talk
to
santosh
and
we'll
see,
but
what
what
we
want
to
do
next.
A
Okay,
I
don't
have
anything
else
to
discuss.
Do
any
of
you
have
any
other
topics.
B
A
Yeah,
so
I
think
the
next
the
next
step
like
so
we
have
basically
two
proposals
in
in
draft
like
we
have.
We
have
the
data
model
proposal,
which
is
where
we're
proposing
you
know
using
events
logs
as
events
and
then
then
ted
that
thought
that
we
we
should
have
these
proposals
for
sessions
ready
at
the
same
time,
because
they're
linked
so
once
we
have
this
proposal,
then
I
think
we
should.
A
We
should
probably
open
an
otep
or
two
otaps
for
those
two
things
so
that
you
know
to
open
the
discussion
for
a
wider
discussion
and
then
then
I
think
once
once
there
is
an
agreement
on
that.
Then
we
can
start
working
on
on
yeah,
unlike
semantic
conventions
for
different
types
of
events.
Yeah.
B
How
we
can
make
sure
they're
all
shared
across
everyone,
yep,
okay?
Now,
because
that's,
I
think,
the
events
api
was
our
initial
cut
at
that
from
memory.
A
Yeah,
so
we
we
have
a
prototype
of
the
of
the
events
api,
but
we're
not
proposing
it
in
in
this.
On
the
in
the
data
model,
yeah
yeah.
D
Question
about
the
multiple
sessions
in
the
in
the
session
proposal,
I'd
be
interested
in
in
seeing
the
like
a
a
diagram
of
how
that
would
work,
or
I
I'm
just
not
clear
on
it's
not
clear
to
me
how
the
shared
dispatch
component
will
work.
Is
this
an
implementation
detail
or
is
it
kind
of
an
essential
part
of
the
the
session
model
that
we're
proposing.
B
I
think
it's
probably
more
driven
from
implementation
so
effectively.
This
comes
from
one
of
our
internal
teams,
which
is
your
microsoft
teams,
where
effectively
it's
a
platform
and
as
part
of
that
platform,
there
are
actually
multiple
teams
running
components
and
each
of
those
teams
have
their
own
back
end
their
own
set
of
monitoring
that
they
want
to
do,
but
so
like
at
any
point
in
time
there
is
at
least
five
different
components,
running
that
are
collecting
events
and
being
sent
to
their
own
different
backends.
B
B
We
have
this
shared
instance
so
that
effectively
all
the
batching
happens
in
one
component.
So
all
of
those
five
teams
just
ask
the
the
shed
manager
to
get
their
instance,
and
I
can
just
start
firing.
Events
at
it
and
they'll
get
batched
and
sent
collected
with
everyone
else.
D
Yeah
yeah,
I
kind
of
understand
the
use
case,
I'm
just
wondering
how
that
you
know
that
maps
to
to
the
hotel
implementation.
That's.
B
So
so,
when
we
spoke
to
to
daniel-
and
you
know
the
effect
of
the
javascript
stick
last
week
today,
the
otel
p
otlp
exporter
does
group
things
based
on
this
set
of
resources
so
that
if
a
span
is
created
because
they
don't
have
logs
yet
so
if
a
span
is
created
with
a
different
set
of
resources,
it
will
be
grouped
for
the
same
or
separately
the
zipkin.
I
think
it
was
martin.
Do
you
remember?
B
B
Yeah,
so
that
comes
down
to
implement
implementation
detail
at
the
back
end,
where
apparently
in
the
spec
there
in
the
original
spec,
when
I
got
created
the
reason
javascript
does
have.
The
set
of
resources
on
the
span
was
because
it
was
spec
that
way.
I
haven't
gone
back
to
look
at
the
discussion
as
to
why,
but
it's
to
our
advantage
to
have
it
there,
rather
than
just
have
the
global
set
gets
used
during
exporting.
B
Well,
the
otp
exporter.
So
the
thing
that
packages
it
up
and
then
sends
it
off
to
the
collector.
A
B
Actually
spoken
to
java
and
python,
yet,
okay.
B
B
I
thought
that's
going
to
be
another
big
one
that
we
want
to
find
out,
how
they've
done
it,
because
there
will
be
a
bunch
of
net
clients,
considering
hotels,
baked
into.net.
B
E
A
Okay,
to
be
honest,
I'll
have
to
think
some
more
about
yeah
this
multiple
sessions
topic
and
how
to
represent
it
like
with
with
open
telemetry.
D
A
Okay,
right,
you
can
end
them.