►
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
There
we
go
so
it's
been
a
couple
of
months
since
we've
talked
about
this,
and
so
I
wanted
to
give
an
update
on
sort
of
what
we're
thinking
and
where
we're
going.
We
believe
that
we've
identified
a
few
I
mean
I,
guess,
privacy
issues
with
the
original
proposal
and
wanted
to
present
an
alternative
shape
for
the
API
that
will
hopefully
allow
embedded
frames
to
mitigate
that
and
get
some
opinions
on
this,
so
sorry
yeah.
A
So,
basically
the
idea
of
just
as
a
recap
is
that
we
want
to
have
a
way
of
sharing
performance,
entry
or
sorry
performance
timeline
entries
from
an
embedded
child
frame
up
to
its
parents
as
much
as
possible.
We'd
like
to
use
you
know
existing
code
paths
for
this
you
know,
have
performance
observers
be
able
to
intercept
them
and
just
work
with
performance
entries
as
they
are,
and
it's
critical
in
all
cases
that
the
child
frame
is
at
least
aware
of.
What's
going
on
and
is
is
consenting
to
having
its
performance
entries
shared.
A
So
let
me
just
go
over
the
the
original
proposal
that
we
had
basically
had
an
explicit
request
from
the
parent
frame
to
receive
timeline
events
from
its
children.
We
had
an
explicit
opt-in
from
the
child
frame
using
a
document
policy
to
say
where
those
entries
should
go
and
the
delivery
from
child
to
parent
was
implicit.
Basically
any
entries
that
sort
of
match
the
criteria
of
you
know
of
what
type
of
Entry
it
was
and
where
it
was
going,
would
just
be
delivered
from
the
child
stream
up
to
its
parents.
A
The
problems
with
this
are
mostly
centered
around
the
fact
that,
in
all
the
use
cases
that
we've
looked
at
the
child
frames
would
probably
need
to
restrict
this
data
more
than
that
they
need
a
bit
more
control
over
what
actually
gets
sent.
They
might
want
to
have
a
number
of
entries
emitted,
for
whatever
reason
they
may
want
to
restrict
entries
just
only
allowing
certain
ones
by
type
they
may
need
to
modify
the
entries
themselves.
A
A
So
the
the
new
approach
that
I
just
want
to
outline
here
still
has
the
same
explicit
request
from
the
parent
frame.
A
The
difference
is
that
the
opt-in
from
the
child
is
implicit
in
the
fact
that
it
just
calls
a
new
API
to
do
this
and
explicitly
controls
the
delivery
up
to
its
parents
right
so
so,
essentially,
the
this
is
unchanged
from
the
previous
proposal
in
the
parent
frame.
You
register
a
performance
Observer
we're
not
looking
at
the
synchronous
methods
anymore.
There
just
seem
to
be
no
no
way
of
making
those
performant
so
using
performance
Observer,
specifying
explicitly
that
you
want
to
include
data
from
Child
frames
and
on
the
parent
side.
A
That's
all
you
need
to
do
on
the
child
side.
We
are
thinking
about
a
new
API
and
completely
bike.
Sheddable
name
here
is
just
broadcast
entries,
probably
bound
to
the
performance
object
where
you
provided
a
list
of
entries,
whether
that
is
an
actual
performance,
entry
list
or
just
an
iterable
of
entries,
and
then
a
Target
specification
very
similar
to
what
post
message
does.
So
you
can
specify
star
to
say
this
can
go
to
all
Origins.
A
And
you
would
use
that
I
mean
it
could
be
as
simple
as
create
a
performance
Observer
and
in
your
callback
broadcast
what
you've
got
right.
This
is
obviously
more
JavaScript
than
the
original
proposal,
but
this
seems
to
be
the
sort
of
the
simplest
way
that
we
could
do
this
as
a
more
complicated
example
right.
We
could
do
this.
You
know
again
registering
your
performance
Observer
to
sort
of
get
access
to
the
entries
as
they
come
in.
A
You
could
do
things
like
if
there's
an
internal
URL
in
here
then
just
omit
this
from
the
list.
If
there's
some
sensitive
information
then
replace
that
URL
and
then
finally,
you
know
once
you've
actually
compiled
the
list
and
filtered
it
as
you
need
to
then
send
that
back
up
to
the
parents.