►
From YouTube: Diagnostics WG meeting - Feb 26 2020
Description
A
So
welcome
to
the
Diagnostics
working
group
meeting
for
February
26
2020
I'm
gonna,
chair
in
place
of
Peter
this
week,
because
he's
I
think
in
in
travel
mode
will
follow
the
standard
agenda.
I'm
gonna
paste
the
link
to
that
in
the
chat
so
that
everybody
who's
here
can
add
themselves
to
the
list
of
attendees.
A
A
A
Okay,
so
the
next
one
on
the
tracker
is
report
version
semantics
are
not
defined,
so
this
is
number
349.
This
has
to
do
with
the
version
number
in
diagnostic
reports.
I
think
there's
been
some
more
discussion
tarisha.
Can
you
sort
of
bring
us
up
to
speed
and
and
see
if
there's
any
questions,
and
maybe
we
can
figure
out
what
we
need
to
close
on
this
yeah.
D
But
that's
where
we
stand
at
this
point.
We
don't
see
any
huge
opposition
on
that
particular
proposal.
So
my
idea
would
be
to
just
wait
for
few
more
days
to
see
if
there
is
anything
other
than
what
is
there
in
the
issue
tracker
if
nothing
comes
as
an
opposition.
Take
this
as
the
input
from
the
diagnostic
working
group
and
give
that
as
the
recommendation.
D
A
D
A
That's
close
that
one
out:
okay,
the
next
one,
is
proposal
to
drive
diagnostic
work,
openness
through
user
journeys.
I
think
we
were
gonna
have
a
deep
dive
this
week,
but
we've
agreed
since
we
couldn't
get
everybody
here
today
to
defer
that
to
next
time.
So
I
don't
know
if
there's
anything
else,
to
talk
about.
C
A
A
D
A
Yeah,
no
I
think
that
that
is
ceasing
storage
and
then
there
was
also
the
Conte
yeah
I
forget.
If
that's,
there
was
a
couple
one
which
was
like
a
sink
resource
and
then
a
sink
storage.
But
it's
good.
It's
good
to
see
that
land,
because
I
think
that's
an
important
thing
in
terms
of
having
that
functionality
and
it's
good
that
we're
now
like
people
are
tweaking
it
there's
something
concrete
there
that
you
know
the
follow-on
PRS
are
then
addressing
the
tweaks
and
stuff.
So
it
seems
quite
healthy,
yeah.
D
I'm
just
wondering
that
we
do
have
quite
many
unit
test
cases
and
most
of
them,
or
at
least
a
good
subset
of
them,
follow
the
pattern
of
a
client-server
model,
and
we
deal
with
the
request
and
response
object
around
various
closures
and
other
functions.
So
probably
is
a
worthwhile
to
see
how
do
we
make
use
of
this
storage
API
to
player
on
with
the
request
and
response
objects,
without
really
passing
those
through
the
functions
and
see?
D
D
Yeah
we
do
have
a
huge
huge
coverage
for
the
HTTP
test
cases
and
yeah.
They
might
need
to
see.
Is
it
worthwhile
to
toot
them
from
the
traditional
closure
based
approaches
to
the
CLS
based
approach?
We
have
done
that
in
the
past,
like
changing
the
callbacks
into
the
arrow
function,
types
wrapping
callbacks
into
a
coin,
dogmas
calls
and
all
those
things
so
as
and
when
we
the
API,
is
evolved.
We
also
have
evolved
the
unit
of
cases
right.
A
D
D
It
would
be
either
way
right,
I
mean
some
of
the
HTTP
test
cases
which
require
the
the
route
objects,
like
the
question
response
to
be
played
around
passed
around
for
into
various
functions,
could
be
just
stored
into
this
storage
and
retrieve
wherever
is
required.
It
would
become
a
kind
of
programming
pattern
which
most
of
the
HDP
and
net
objects
and
the
test
cases
can't
follow,
and
in
that
process
we
will
or
will
also
be
evolving.
The
test
cases
at
the
same
time
will
also
be
able
to
provide
subtle
feedback
to
the
API
itself.