►
From YouTube: GraphQL Over HTTP - February 25, 2020
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
C
So
I'm
pretty
excited
to
share
a
link
to
this
repo
for
the
agenda
item
wish
rush.
This
wind
zoom
not
very
used
to
zoom
yeah.
C
A
B
B
D
C
A
B
B
Great,
so
let's
look
through
the
agenda
yeah,
so
pretty
much.
The
only
thing
that
we've
got
here
is
a
test
runner
for
kind
of
proof
of
concept.
Progress
that
Jaden
you
hit
added,
so
I
think
we'll
kind
of
well
start
with
that.
Is
there
anything
else
to
add
to
the
agenda
that
people
want
to
talk
about.
C
Awesome
I'll
just
tap
out
is
there
bring
up
my
own
read
me
yeah.
So
pretty
much
I've
tried
a
whole
bunch
of
stuff
earlier
in
the
month.
C
So
this
is
like
pretty
useful
for
people
to
use
in
seei,
so
I've
I
was
halfway
through
just
before
I
joined.
This
call
creating
like
an
example
repo
with
it
working
so
I
guess
you
can
see
what
it
looks
like
in
the
console
when
it's
doing
its
thing,
because
I
realized
at
the
last
minute
that
just
looking
at
all
of
the
tests,
as
probably
doesn't
spark
the
imagination,
because
at
all
the
tests
like
run,
is
child
process
and
get
snapshotted
and
stuff.
C
C
C
You
yep,
so
these
are
the
two
tests
that
I
had
added
I
just
tested
a
query
field
resolves
okay
and
we're
pretty
much
just
checking
this
to
the
JSON
structure
that
is
returned
and
the
HTV
status
and
I
test
a
query
that
results
in
error
and
we're
checking
that
the
status
is
actually
still
at
300.
Even
though
there
was
an
error
and
just
details
about
the
like
graphic
there,
graphical
payload
and
the
response.
C
So
we
can
build
these
these
tests
out,
just
by
sort
of
replicating
how
that
works
and
just
keep
pasting
in
more
tests,
and
we
can
update
the
schema
accordingly.
One
of
the
cool
things
about
this
is
it's
actually
like
a
lot
easier
than
I
thought
to
test
arbitrary
servers
as
if
they're
a
JavaScript
server.
That
is
because
the
schemer
is
exported
see,
so
you
can
just
import
that
schema
and
then
just
right
start
the
server
and
then
off
you
go.
C
In
the
index
here
yeah,
so
I'm
here's
a
compliant
color
app,
it's
just
using
graphical
api's,
color
execution
with
the
schema
which
is
coming
straight
from
you
know
what
what
the
public
could
import
as
well.
That's
the
test
schema
that
we're
exporting
from
this
package
and
yeah
we're
just
running
so
yeah.
This
is
awesome.
This
is
snapshotting
they're,
like
CLI
output
of
the
test
itself,
so
it's
not
very
exciting
to
look
at.
C
So
this
snapshot
so
I've
previously
published
a
standalone
package
that
just
does
a
snapshot
assertion
it.
You
know
it's
very
similar
to
other
snapshotting
approaches
where
you
just
have
like
an
update.
Snapshot
equals
one
environment
variable
and
it
updates
the
snapshot
files.
But
this
is
sort
of
very
isolated
and
lightweight
approach
and.
A
C
D
Think
it
would
be
a
good
idea
to
make
a
decision
on
that,
but
I
I'm,
a
little
bit
like
I,
feel
like
it
should
only
test
the
HTTP
part,
but
equally
there
are
things
that
we
are
potentially
adding
to
graph
go
imminently
like
like
defer
and
stream,
and
things
like
that
actually
relate
to
the
transport
layer.
So
those
things
you
know,
maybe
we
do
need
to
reach
a
little
further,
so
yeah
I'm
just
interested
to
hear
what
have
you
found
so
far.
C
Well,
we
control
a
graph
QL
schema,
so
we
can
and
that's
just
using
graph,
QL
j/s
and
all
of
their
javascript
based
graph
QL
servers.
You
can
pretty
much
just
dump
a
graph
kihl-jae
a
scheme,
or
instance
in
it.
It
goes
so
we
can
do
whatever
throw
areas
or
do
any
tricky
things
and
resolve
functions
of
that
schema.
We're
exporting.
C
So
the
having
that
schema
exported
that
way
kind
of
you
know,
creates
a
public
contract
as
well,
so
we
could
generate
like
an
STL
and
people
could
see
I
guess
what
the
resolve
is
a
meant
to
be
doing
so
that
if
they
were
to,
then
you
know
do
it
in
a
totally
different
language.
They
know
at
least
what
schema
they
need
to
be
creating,
for
you
know,
for
the
tested
of
the
able
to
run
I
haven't
bothered
to
do
an
STL
dump
out.
I've
just
got
the
graphic
else.
C
A
C
A
C
Yeah,
because
we
we
have
to
have
some
some
scheme
or
some
structure,
I
guess
I
mean
just
looking
at
this
query,
a
field
that
resolves
our
okay.
You
know
our
tester
needs
to
send
request,
and
so
we
have
to
hard
code
in
there.
What
that
query
is
when
we're
sending
that
request.
So
this
server
on
the
other
end
has
to
match
that
request.
A
D
A
great
way
of
doing
that,
potentially,
for
example,
would
be
to
query
things
like
the
introspection
fields.
We
can't
do
that
necessarily
for
the
error
field,
but
for
other
ones,
like
underscore
type
name,
for
example,
could
be
a
replacement
for
okay
and
then
any
graphical
schema
would
should
support
that.
C
C
B
D
I
think
one
of
the
values
that
we
get
from
this
project
is
going
to
be
testing
the
other
ones
that
won't
like
basically
originally
based
on
Express
graph
qo,
so
the
various
other
programming
languages
so
I
think
if
we
can
try
and
minimize
the
amount
of
work
that
those
folks
need
to
do
in
order
to
use
the
test
suite.
That
would
be
great.
D
So
if
we
can
do
things
like
using
the
introspection
fields,
that
should
always
be
present,
because
the
graphical
specs
Association
says
they
should
be
instead
of
using
a
new
okay
field,
for
example,
that
would
be
beneficial,
but
the
errors,
one
is
actually
a
really
interesting.
One
I
think
quite
a
lot
of
these
servers,
even
in
the
nodejs
ecosystem,
have
a
way
of
effectively
taking
the
errors
and
augmenting
them
or
pulling
extra
information
or
removing
information
from
them.
But
I
believe
that
the
is
it
the
groucho
spec.
D
Well,
the
I
think
is
the
graphical
spec
says
what
the
errors
should
have
like
things
like
path
and
things
like
that,
but
it
is
possible
that
the
server's
may
actually
break
these
promises
by
by
manipulating
those
errors,
so
it
might
be
worth
pulling
that
part,
even
though
it's
part
of
the
graph
girl's
back,
it
might
be
worth
pulling
that
part
also
into
the
HTTP
test.
Suite.
C
Yeah,
so
I
had
accounted
for
that
consideration
in
this
example
test.
So
because
the
message
itself
can
be
obviously
obscure,
cated
the
test
just
checks
that
there
is
a
string
of
a
message,
but
not
what's
in
it,
and
it
also
doesn't
deeply
strict
equal
the
entire
error
sort
of
object,
because
there
could
be
extra
fields
that
servers
put
in
there.
So
it
just
checks
specifically
for
the
fields
by
specs.
Should
that
need
to
be
there.
D
Awesome
yeah
this
this
looks
quite
good.
Sorry,
I
wasn't
reading
it
and
full
before.
But
this
looks
great
I
have
another
question.
So
in
the
most
recent
graph,
QL
specs
we've
we've
specified
the
errors
a
bit
more
strictly
and
we've
talked
about
this
extensions
property.
I
think
where
you
can
add
extra
stuff.
D
So
for
things
like
that,
I
don't
think
a
server
is
non-compliant
or
like
should
error,
necessarily
if
it's
still
putting
fields
at
the
root
level
of
the
error,
because
that
was
historically
what
would
happen
and
the
extensions
thing
is
like
how
you
do
modern.
Do
we
have
a
way
of
effectively
may
be
raising
a
warning
as
opposed
to
an
error,
or
maybe
it
is
just
a
different
test
case
and
you're
like
97
percent
compliant
rather
than
a
hundred
yeah.
C
So
if
you
do
a
console
log
or
a
console
one
or
something
in
any
of
these
tests,
that
will
be
printed
out
in
the
in
the
report.
Indented
underneath
the
heading
of
that
test.
So
it
won't
create
a
nonzero
exit
status,
which
is
what
you
want,
but
you
can't
put
messages
in
there
conditionally
during
the
test
running.
A
C
C
B
C
The
JavaScript
API
that
this
package
exports
it
reports
to
the
console,
but
what
would
have
probably
been
better
is
that
JavaScript
API
will
return
like
an
object
that
has
sort
of
the
results
of
all
and
the
individual
tests.
So
that
way
you
could
potentially
use
all
sorts
of
different
reporters
on
top
of
that
result.
C
Now
that
gets
quite
nuanced
and
complicated
and
I
had
some
great
ideas
for
doing
that,
because
when
you're
running
the
tests
you
want
to
be
able
to
do
console.log
warnings
and
things
in
there
and
if
there's
an
if
there
is
an
error
or
the
test
is
just
broken
and
there's
you
know
or
console
logs
from
third-party
cart
code.
You
know
you
it.
The
way
it
currently
works
is
quite
nice
and
that
it's
all
properly
nested
and
indented
in
in
the
console.
C
So
at
the
moment,
there's
a
very
similar
behavior
like
between
the
JavaScript
function
and
the
CLI
they've
worked
quite
similar.
The
only
difference
is,
of
course
the
CLI.
You
know
it
just
exits
with
a
zero
status,
but
the
the
JavaScript
function.
It
sets
a
non
zero
status
if
there's
a
failure,
but
it
also
throws
an
error
so
which
is
configurable.
A
D
I
think
maybe,
if
you
return
an
object,
that
then
has
a
status
on
it
like
status,
pass
or
status,
fails.
Something
like
that.
Maybe
that
would
be
better
I'd,
also
caution
against
setting
the
exit
status
code
in
the
library
where
you
are
not
actually
controlling
the
exit.
I
wouldn't
do
that
particular
one
single
line
of
code
I
would
comment
that
out
and
only
use
it
on
the
CLI
personally
yeah.
C
This
actually
came
up
today,
I
had
some
uses
of
some
of
my
other
packages
asking
about
WebSocket
support
and
stuff
and
I
was
saying:
I
don't
want
to
build
a
bunch
of
stuff
without
a
proper.
You
know
graphical
foundation,
stamp
of
approval,
sockets
protocol,
but
then
I
couldn't
actually
find
a
very
obvious
place
to
link
to
the
public
to
track
progress
for
that
I
like
people
into
it
that
maybe
this
working
group
is
responsible
for
it,
but
the
HDP
in
the
name.
It
does
sort
of
ward
off.
That
idea.
D
Again,
I,
don't
think
so.
Websockets
are
an
HTTP
protocol,
they're
they're
an
upgrade
existing
HTTP
I
think
this
is
actually
a
common
issue.
This
is
why
Express
graph
doesn't
have
WebSockets
support
is
because
there
is
no
official
graphical
project
that
has
it
I
think
a
lot
of
people
just
use
Apollo's
WebSocket
solution
and
they
do
have
their
WebSocket
protocol
quite
well
documented,
so
it
might
be
worth
speaking
with
Apollo
and
basically
seeing
if
that
can
become,
perhaps
the
official
one,
maybe
through
this
working
group
or
maybe
another
I,
think
it's
appropriate
for
this
personally
may.
C
D
C
I
would
very
much
love
to
see
this
working
group
or
another
definitely
put
something
out
there
as
well
I.
Just
from
my
own
experience,
because
I
went
into
a
real
deep
dive
around
the
Apollo
protocol.
I
wanted
to
publish
my
own
implementation
on
their
protocol.
There's
problems
in
that
just
in
its
design
as
well.
That
haven't
been
solved
for
a
few
years,
so
I
don't
think
we
can
just
drop
it
in
and
use
it.
C
D
C
Apollo's
already
broken
their
own
protocol
on
a
at
least
one
occasion,
so
they're
up
so
I
think
that
second
major
iteration,
but
they
sort
of
just
didn't
because
they
didn't
really
document
the
protocol
and
for
a
while.
The
olds
sort
of
github
readme
actually
had
its
the
way
the
old
protocol
worked,
but
they
had
actually
changed
it
in
the
source.
C
B
All
right
into
your
appointment,
Benjy
does
there's,
certainly
a
need
for
it
right.
It's
just
I
think
like
one
of
the
our
early
goals
with
the
working
group
is
to
get
a
1.0
version
of
the
spec
out
and
I.
Think
WebSockets.
Should
it
be
part
of
the
1.0
version,
because
I
I
think
it's
a
big
topic.
Yeah
I
think
will
give
me
some
time
and
it's
already
taking
us
like
we're
like
two
or
three
months
in
and
we
we
don't
have
like
the
basic
spec
published.
I.
B
D
100%
agree
with
that
with
that
said,
I
think
we
should
think
about
how
we
would
go
about
doing
that
at
this
stage,
because
it
will
help
us
to
not
build
the
HTTP
tests
in
a
way.
That
would
then
make
adding
WebSockets
support
later
more
challenging.
So
I
think
it's
worth
at
least
thinking
about
a
little,
but
I
absolutely
agree.
It
shouldn't
be
in
the
first
set,
and
we
will
be
looking
at
that
once
the
1.0
is
out
properly.
We
don't
need
a
solution.
D
A
I
guess
running
tests
on
WebSocket
support
is
going
to
have
to
be
a
separate
part
of
the
test
suit
anyways.
So
it's
not
gonna
be
a
feature
that
every
server
has
to
support.
So
that's
we
can
still
have
five
CLI
or
API
for
that,
but
it
can
live
in
a
totally
different
module
or
something
so
we're
not
technically.
D
Absolutely
I
think
one
of
the
things
to
keep
in
mind
is
that
WebSockets
can
also
be
used
for
the
same
queries
and
mutations
that
the
HTTP
on
its
own
can.
So
it
might
be
that
we
could
leverage
sharing
some
of
the
tests
and
really
it's
like
a
case
of
send
this
over
any
transport
and
check
that
the
result
is
this
and
then
the
way
that
we
check
that
for
HTTP
versus
WebSockets
could
be
different,
I
think
being
able
to
share
those
tests
and
just
use
this
one
schema
for
everything
could
be
beneficial.
D
B
C
A
Think,
speaking
to
what
Angie,
would
you
trust
that
about
the
sending
with
different
payloads
over
different
mechanisms?
I
think
we
should
really
try
to
keep
the
tests
really
shallow
in
that
regard,
so
we
don't
have
to
test
every
feature
of
graph
QL,
that's
within
the
scope
of
the
spec.
So
so
we
can
stop
at
a
certain
point
and
the
tests
don't
have
to
prove
that
the
server
is
100%,
correct
and
everybody,
but
just
that
the
the
basics
about
the
HTTP
hold
on.
C
So
I
want
to
just
polish
a
little
bit
to
do
with
on
a
massive
level
the
testing
of
the
tester
just
so
it's
a
little
bit
easier
to
iterate.
So
I've
noticed
in
github
actions
only
on
OS
X,
there's
flakiness
one
Everitt
one
in
every
four,
for
some
reason
isn't
happy
I,
don't
know
why
it's
fine
on
the
others,
it's
fine
and
Linux,
so
yeah.
If
the.
If
the
groups
interested
in
this
approach
I
can
continue
to
refine
it.
C
C
B
Okay,
that's
better
all
right!
That's
probably
more
normal
format,
so
yeah
I
think
that
that
is
a
POC
running
for
first
first
pass
at
that.
So
that's
great
one
thing
that
I
was
supposed
to
do
come
on
my
docket,
which
okay
for
it
is
kind
of
to
go
through
and
get
a
list
of
tests
kind
of
that
high-level
from
the
spec,
just
kind
of
in
a
way
like
abstract
and
ignoring
like
whatever
tests
bring
use.
What
are
the
sort
of
things
that
we
gonna
test
so
I
just
do
that.
So
I'll
still
do
that.
C
Glossed
over
it
a
bit
but
on
the
topic
of
the
graphical
integration,
I
looked
into
it
and
got
really
bogged
quickly,
so
I
couldn't
figure
out
how
to
do
it.
So
unless
I
I
get
some
very
close
collaboration
with
someone
that
is
that
what
the
new
graphical
setups
like
and
how
to
use
it
I
didn't
see.
Clarity
when
I
was
investigating.
D
Yeah,
it's
certainly
undergoing
a
lot
of
change
right
now,
I
mean,
as
I
mentioned,
taking
a
little
break
from
that
project
at
the
moment,
because
I
just
have
too
much
other
stuff
going
on,
but
I'm
sure
that
Ricky
would
be
more
than
happy
to
help
you
get
up
and
running
with
this.
He
will
be
extremely
passionate,
aye
I
think
so
let
me
know
if
you
want
me
to
do
any
introductional,
you
can
just
reach
out
it
to
him
directly
if
you're
comfortable
doing
so.
Thank
you.
C
D
C
Then,
sir,
potentially
in
a
future
version
of
that
testing
package,
once
I
get
the
JavaScript
function
to
be
like
not
reporting
straight
to
the
console,
we
could
totally
then
use
this
package
in
an
integration
into
graphical.
So
what
our
work
now?
It
doesn't
exclude
that
from
being
a
future
possibility.
B
C
C
D
D
That's
not
going
to
be
the
full
suite
though,
but
it's
enough
to
maybe
say:
oh,
it
doesn't
do
this
or
does
one
way
or
whatever,
but
then
in
order
to
do
things
like
the
error
testing
that
you've
added,
which
is
critical,
absolutely
critical,
I
think
that
will
I
think
need
adding
special
fields
because
I
don't
think
with
introspection.
You
can
necessarily
fire
custom
errors.
D
You
can
do
things
like
firing
errors
due
to
validation,
failures,
which
would
be
in
the
base
State,
and
you
can
just
do
by
requesting
things
on
the
introspection
schema
that
do
not
exist,
but
when
it
comes
to
actual
like
custom
user
errors,
I
think
we're
going
to
need
the
custom
schema
but
I'm
just
basically
saying
if
we
keep
that
schema
as
absolutely
tiny
as
we
possibly
can
that's
going
to
be
beneficial
because
it's
less
to
implement
in
all
the
different
languages.
Well,.
C
A
Not
actually
sure
that
we
need
any
special
fields
for
for
testing
errors,
since,
of
course,
there
are
different
error
conditions
which
you
might
have
because
of
the
contents
of
the
query.
But
I
don't
think
they
are
really
a
concern
of
the
HTTP
specification
so
because
the
HTTP
specification
is
more
concerned
with
errors
such
as
not
not
sending
proper
jason
or
at
all
or
not
sending
the
query
as
a
field
called
exactly
query.
Errors
like
that
I.
D
Challenge
that
specifically,
because
I've
seen
frameworks
that
do
give
you
the
ability
to
post
process
the
errors
that
you
get
through
graph,
QL
and
I
think
it
needs
to
be
enforced.
That
I
haven't
seen
anything
that
post
processes
the
data
other
than
things
like
graph
galo,
for
example,
which
you
know
this.
Actually,
I
think
yeah
I
caramel
there
that
works
out,
but
anyway
the
errors
are
commonly
like
filtered
or
augmented
or
replaced
at
the
server
level.
So
I
think
those
do
potentially
need
some
superficial
tests
and
yes,
you're
right.
D
Yeah
they
they
absolutely
are
and
I'm
not
disagreeing
with
that
at
all.
But
I
am
saying
that
some
servers
then
fiddle
with
the
results
of
that,
and
we
should
make
sure
that
they
fiddle
with
it
in
a
way
that
remains
graphical
compliant,
but
I'm
also
open
to
just
saying
that
this
is
beyond
the
scope
of
the
project.
So
I
personally
would
err
on
the
side
of
checking
those
things.
But
if,
if
everyone
agrees
that,
maybe
we
shouldn't
then
I'm
happy
I'm,
not
it's
not
strongly
held
I.
B
Think
if
that
was
the
only
thing
that
meant
that
we
couldn't
that
we
would
have
to
have
a
shared
schema
between
all
the
implementations.
That
could
be
an
argument
for
jettisoning
that
idea.
You
know
just
initial
everything,
but
I
have
a
suspicion
that
we
may
have
a
whole
class
of
tests
that
require
us
to
have
a
schema
and
therefore
we
might
module
eyes
into
like
here's,
the
generic
test
that
will
run
against
any
server
just
on
introspection
alone
and
here's
a
set
of
tests
that
we
use
to
further
evaluate
a
servant's
compliance.
C
Shared
schema
that
I've
got
there
has
got
field
descriptions
that
quite
detailed
explain
what
the
resolver
does.
So,
if
we
were
to,
you
know
export
an
STL
dump
of
that
JavaScript
schema
people
could
read
that
or
potentially
you
can
consume
and
use
it
when
they're
implementing
their
resolvers
and
their
chosen
framework.
But
though
they'll
sort
of
have
some
English
descriptions
to
sort
of
just
you
know
as
a
sort
of
a
template
or
instructional
on
how
they
should
be
setting
up
the
resolvers
in
the
descriptions.
A
I
think
we
might
also
just
want
to.
Lastly
testitude
on
that,
so
we
have
a
stuff
may
be
a
subset
of
the
tests
that
can
be
run
just
on
introspection
which
don't
require
any
particular
implementation,
because
one
reason
that's
that
can
be
really
useful
if
you,
as
if
you're,
if
you
want
to
test
the
conformance
of
a
server
which
you
don't
own
and/or,
which
you
maybe
don't
even
know
the
language
its
program
time.
So
you.
D
B
D
Was
basically
saying
much
like
how
Co,
for
example,
has
Prime
as
for
reducing
its
spidering,
and
things
like
that,
we
may
want
to
have
a
flag,
or
at
least
tell
users,
don't
run
this
against
an
API
that
you
don't
own,
because
it
does
send
X
number
of
requests
over
a
short
period
of
time,
and
you
don't
want
to
get
burned.
Basically,
just.
C
B
C
Could
eat
we
could
either
just
have
a
flag,
and
you
know,
have
an
if
statement
that
will
sort
of
skip,
adding
the
test
to
the
suite
in
the
code,
which
would
be
very
trivial,
but
if
people
are
importing
that
subset,
basically
with
tree
shaking
and
all
the
rest
of
it
and
Mike
Randall
size,
if
people
just
want
the
small
subset,
we
could
export
a
separate
export
that
that
would
only
pull
invite
all
of
them
modular
JavaScript
stuff,
just
the
ones
they
need.
So
we
could
export
a
different
function
at
the
top
level.
I.
D
C
C
C
D
B
D
C
D
B
C
B
C
A
D
C
C
C
C
C
D
Potentially,
adding
letters
and
things
like
that,
I
think
it
would
be
good
to
mimic
a
familiar
web
tool.
That's
used
for
this
purpose
so,
for
example,
curl
or
double
you
get
something
like
that,
so
that
we
have
the
same
kind
of
say.
Life
likes
as
those
it
would
just
make
it
very
convenient
also
means
we
don't
have
to
reinvent
the
wheel.
Yep.
C
Maybe
this
could
be
an
enhancement,
github
issue
on
that
repo
and
people
can
suggest
the
format
of
the
flags
I.
Think
that
whatever
the
CLI
design
of
the
flags
is,
we
would
then
replicate
the
naming
as
JavaScript
options
in
the
options
object
for
the
JavaScript,
API
and
they'll.
Just
get
passed
right
through
agreed,
so
I
guess
look
camel
cases
and
stuff
instead
of
just
for
convenience,.
C
D
C
D
C
C
C
D
Suggesting
it
earlier
also
like
don't
want
to
come
across
too
much
as
a
touch
prep
zealot,
but
also
it
does
help
a
lot,
particularly
for
people
who
are
not
familiar
with
the
library
being
able
to
see
all
the
autocompletes
in
line
with
the
types
and
other
such
things.
Some
of
that
can
be
inferred
from
the
the
JavaScript
for
things,
but
often
it's
very
loose
in
that
way.
It's
nice.
It
just
makes
the
echo
a
lot
easier
to
interact
with.
B
I'm
a
bit
agnostic
as
far
as
it
goes
because
I
feel
like.
If
someone
is
interested
in
it,
you
can
always
be
ported
to
type
script
by
a
typescript
zealot.
As
you
should
say,
it's
that's
not
a
hard
step,
so
we
can
always.
We
can
always
make
that
migration.
It's
an
easy
migration
going
to
typescript
from
JavaScript.
C
B
Cool,
so
we've
got
some
actions
for
our
next
month
down
here
below.
Does
that
look
good
or
anything
else?
We
should,
you
know,
kick
down
the
road
I
think
I'm,
pretty
I'm,
pretty
confident
about
the
list
of
tests
that
I
should
be
able
to
get
that
done.
I
think
that's
important
for
our
time.
Taking
the
next
steps.