►
From YouTube: GraphQL Working Group - April 2, 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
B
A
C
C
F
B
It
was
the
final
destination
and
actually
I
had
the
temperature
I
catch.
Some
food
poisoning,
so
I
was
flying
with
temperature
and
we're
going
to
a
plane
actually
as
them.
What
should
I
do
because
I
have
a
temperature.
There
is
quite
a
virus
stuff
and
I
stuff,
and
they
say
if
you
can
fly
when
fly
so
and
justify
to
agree.
It
was.
G
F
C
C
G
B
H
J
J
A
C
As
a
reminder,
we
all
by
joining
here,
agreed
to
the
spec
membership
agreement,
just
basic
guidelines
and
code
of
conduct
links
are
there
in
the
agenda
if
you
need
a
refresher,
otherwise
just
a
reminder,
and
also
I
added
the
template
this
time
around
in
the
big
bold
text
on
attendees,
saying
that
you
all
consent
to
being
recorded
by
joining
so
we
started
recording
by
default
when
this
thing
booted
up.
So
hopefully
that
makes
things
easier.
C
Although
I,
we
still
need
to
go
dig
out
where
all
these
videos
end
up
on
the
cloud,
a
quick
review
of
the
agenda.
So
we
know
what
we're
talking
about
today.
We're
gonna
do
a
quick
dive
into
the
annual
report.
I'll
check
up
on
custom,
scalers
input,
unions,
the
application
graph,
QL
mime
type,
and
that's
our
tight
addenda.
Anything
else.
People
want
to
dive
into.
C
C
This
looks
like
it
was
done
by
me,
but
the
vast
majority
of
the
credit
here
goes
to
Brian
and
Chris,
who
put
this
whole
thing
together
and
basically
just
asked
me
to
write
look-ahead
schnapps
this
for
the
ends.
That's
really
my
only
contribution
if
you
haven't
checked
this
thing
out,
yet
you
absolutely
should
it's
really
really
good?
C
G
I
was
I
was
actually
gonna
ask
about
the
membership.
I
know
things
have
been
evolving
on
that
front,
particularly
for
smaller
people.
I
know,
you've
got
a
thing
like
pre-approved
I
read
the
report
earlier.
Pretty
open
source
projects
and
such
I
know
that
I
think
anyway,
that
to
become
a
graphical
foundation
member
you
need
to
be
a
Linux
Foundation
member.
C
No,
the
graphical
foundation
is
is
backed
by
the
Linux
Foundation
and
so
most
of
our
paperwork
mirrors
theirs,
but
but
they're.
The
Linux
Foundation
is
a
little
bit
confusing
because
there's
the
like
the
Linux
Foundation,
which
is
the
foundation
that
operates
Linux
and
then
there's
the
Linux
Foundation,
which
is
this
overarching
thing
that
has
dozens,
if
not
hundreds,
of
projects
and
we're
part
of
that
like
overall
set.
C
I
mean
we
paid
the
Linux
Foundation
for
some
services,
but
there
should
be
like
a
1
you're,
paying
the
graphical
foundation
but
like
we
use
them
as
the
like
they're,
the
ones
who
operate
all
like
the
funding
pathways,
which
is
maybe
why
that's
confusing
cuz
like
technically
the
money
goes
to
them.
I,
don't
know
kind
of
like
you
know
you
check
out
in
a
Shopify
flow
you're
paying
Shopify,
but
like
that
money
goes
to
the
vendor
kind
of
similar.
It
is
a
little
bit
confusing.
F
Yeah
Robert
I
have
one
thought
on
the
AWS
side.
This
is
just
the
tip
of
the
iceberg.
There
are
so
many
graphical
use
cases
across
Amazon
and
unfortunately,
what
we
did
this
time
was
only
highlight
the
cases
related
to
amplify
and
well
I'll,
be
working
on
over
the
next
few
months
is
gathering
some
of
the
cases
that
were
using
graphic
yield
for
across
Amazon
that
it's
some
really
really.
B
F
C
C
All
right,
well
I'm,
happy
to
to
see
that
come
together.
Pretty
exciting
at
the
foundation
is
one
years
old,
doesn't
need
a
whole
ton
to
this
group
since
we
operate
as
an
open
group,
but
it
has
given
us
some
solid
backing
and
helped
out
a
little
bit
of
process
like
having
those
new
membership
is
pretty
great.
That's
one
way
we
benefit.
A
We've
largely
the
same
place.
We
were
at
the
last
meeting
we're
waiting
on
the
implementation
to
land
in
back
you
ljs.
That
was
no
positive,
well
I've
been
having
some
things,
but
I
saw
some
comments
on
that
about
an
hour
ago,
so
I
think
we're
moving
forward
again
on
that
yeah.
Otherwise,
I
don't
think
there's
as
much
to
do
there
once
the
implementation
lands
and
we
can
start
moving
again.
B
In
in
a
week,
I
wanted
this
new
new
feature
release
just
wait
if
somebody
discovers
some
breaking
change
or
something
because
there
is
a
lot
of
a
lot
of
changes
in
this
release
so
and
I
will
try
to
finish
review
today.
I
worked
comments.
Most
of
them
was
not
principal
one
thing
I
want
to
discuss.
If
we
have
time
for
it,
it's
not
an
aspect,
but
we
have
least
of
breaking
changes.
What's
considered
a
breaking
change
in
graph
gauges,
we
have
a
function
called
find
breaking
changes,
so
I
mean.
B
Yes,
no
breaking
so
I
have
a
question
if
we
change
URL
on
the
scour
specified
by
URL
on
ask
our
technically
it's
like
a
breaking
change,
because
it's
in
India
fire
on
on
the
coincide.
One
can
do
something
use
it
like
type
mapping
or
something
like
that.
Should
we
treat
it
like
a
breaking
change
or
not.
D
B
If
we
treat
URLs
machine-readable
any
change
to
Euro
change,
how
its
interpreted
on
the
court,
so,
for
example,
you
have
you
mapping
URL
to
to
type
in
Java,
you
meup
date/time
euro
for
daytime
RFC
to
Java
data
type.
So
if
we
change
URL,
even
if
its
reference,
the
same
document
like
quiet
and
fermentation
for
current
implementations,
breakage,
even
if
it's
change
for
the
world.
C
We
also
have
to
unpack
what
we
mean
by
breaking
I
think
this
is
probably
a
mistake
on
my
part
and
Matt
and
I
have
worked
together
on
the
breaking
change
stuff
for
for
a
long,
long
time
or
a
long
time
ago.
I
guess
and
we
mixed
them
all
into
one
pot,
but
really
there's
very
different
categories
of
breaking
changes.
There's
the
idea
of,
if
you
take
the
same
query
like
the
same
text
of
a
query
and
then
sent
it
to
the
server
after
this
change
had
been
applied.
C
Will
you
will
you
get
back
something
meaningfully
different
or
will
that
query
no
longer
be
valid
or
not
execute
anymore
and,
and
those
are
like
truly
a
schema
breaking
change,
because
you've
made
a
past
query
present
a
result.
That's
no
longer
the
same,
so
this
idea
of
like
backwards
compatibility,
breaking
change
that
one
is
not
like.
None
of
these
are
represented
in
the
spec
I
think
that
one
is
the
highest
value
to
be
like
clearly
defined
of
what
is
and
is
not
schema
backwards
backwards.
C
Breaking
change,
because
this,
the
breaking
change
tool
in
graphic
ljs,
also
includes
this
other
category
of
things.
Just
called
dangerous
change,
which
is
not
breaking
but
is
not
really
super
clear
on
what
it
means
by
dangerous,
because
there's
the
second
bucket
of
things,
which
is
there's
this
whole
ecosystem
of
client-side
tooling,
which
relies
on
introspection
to
do
stuff,
and
if
you
change
those
things
in
some
way,
then
the
client-side
tooling
could
cause
someone
headache
in
a
serious
way.
You
know
it
could
generate
a
new
artifact
in
a
way
that
requires
some
manual
intervention.
C
C
Those
dangerous
change
rules
came
out
of
what
would
or
wouldn't
break
those
so
those
I.
It's
not
perfect.
You
can
kind
of
think
of
them.
It's
like
forward
breaking
changes,
because
your
your
clients
are
gonna
eventually
pick
up
those
schema
changes
and
try
to
do
stuff
with
new
queries.
It's
not
a
perfect
way
to
think
about
it,
but
that's
how
I
thought
about
in
the
past.
It's
like
those
two
buckets
of
things:
I,
don't
know.
If
that
helps
answer
this
particular
question.
I
think.
I
This
particularly
helpful,
but
I
think
this
particular
one
is,
is
both
in
the
first
kind
of
more
extreme
category
and
and
that
doesn't
matter
at
all
right.
The
the
new
URL
could
really
mean
the
exact
same
type,
but
it's
just
a
better
documentation
source
for
that
same
time
for
whatever
or
it
could
be,
a
one
of
them
is
positive,
integer,
one
of
them's
negative
integer
and
everything
used
to
be
no,
it's
not
valid
anymore
I.
G
A
G
I
think
from
what
we
said
so
far,
the
we
were
going
to
treat
the
identifiers
as
opaque.
So
in
my
mind,
if
the
identifier
changes,
then
we
never
actually
go
and
fetch
that
we
never
look
at
the
thing
we
can't
tell.
So
we
just
have
to
assume
it's
a
breaking
change.
If,
if
the
client
is
using
a
map
to
look
up
behavior
based
on
the
value,
the
value
has
changed
and
thus
the
behavior
would
change
it
may
mean
something
completely
different.
It
may
not.
We
don't
know.
B
H
B
Up
so
for
for
most
cases
here
and
I
previously,
it's
not
like
first
category
of
breaking
changes
so
erratically.
I
just
want
to
raise
this
issue
and
not
to
give
a
discussion
Oh,
since
we
awake
would
not
have
unified
opinion,
I
think
I.
Could
we
can
just
keep
this
issue
for
now
and
if
somebody
writes
this
issue
ater,
we
can
have
a
separate
discussion
so
based
on
practice.
If
somebody
yes
will.
H
C
Yeah
I
think
it
said
that
it's
a
gap
that
this
is
not
covered
by
the
spec,
because
it
means
that
anyone
trying
to
build
a
tool
that
detects
schema,
breaking
changes
needs
to
go
like
surf
around
and
find
existing
tools
and
port
them
and
then
like
got
check
if
they
are
correct
or
not,
which
is
not
a
great
process.
Matt
you
raise
your
hand
what's
up
yeah.
H
So
with
this,
even
even
some
of
our
breaking
changes
are
that
are
currently
categorized
in
the
first
category
are
not
necessarily
always
breaking
changes,
for
instance,
changing
a
type
to
be
an
interface
that
is
right
now,
like
based
on
our
validation
rules,
I,
believe
that
that's
in
category
one,
it's
considered
a
breaking
change,
but
almost
all
clients
like
the
query
that
you've
run
against
the
server.
Oh,
you
on
the
client
treat
the
interface
that
you
got
as
a
type,
but
you'll
be
able
to
deal
with
it.
H
C
H
C
I
think,
what's
missing
is
a
definitional
rigor
to
what
it
means
to
be
a
breaking
change
and
there's
a
bunch
of
open
questions
and
we
haven't.
We
haven't
been
very
rigorous
about
how
we
categorize
those
things
so
I
think
it's
a
huge
opportunity
if
anyone's
interested
in
taking
a
stab
at
this,
even
just
kind
of
like
framing
up
the
problem,
I
think
that's
a
valuable
step
forward
for
the
spec
and
I
do
think
this
is
like
one
of
the
biggest
missing
parts.
C
C
Circling
back
to
the
agenda
item
specifically
for
the
custom
scaler
spec
this
so
as
I
understand,
this
is
purely
just
waiting
on
getting
merged
and
released
and
and
that's
the
final
thing
to
kind
of
got
checked
at
the
implementation,
not
just
the
spec
as
written
for
us
to
move
it
to
its
final
stage:
cool
Yvonne!
Do
you?
What
do
you
recommend
for
for
code
review
in
the
future?
I
feel
like
this
has
been
a
bit
of
a
pain
point.
C
B
If
somebody
discuss
something
for
me
and
also
right
now,
I
we
can
add,
custom
custom
is
lindros,
so
I
will
try
to
put
like,
for
example,
we
hit
hundred
percent
coverage.
So
right
now
I
don't
need
to
say
to
people
like
you
not
covering
this
wine,
this
wine,
because
it's
like
code
coverage,
gives
them
report.
So
it's
twofold
issue,
one
hole
this
would
would
be
really
nice
if
somebody
reviews
and
second
thing,
I
think
when
I
need
to
invest
more
into
link,
you
know
it
github
actions
and
other
stuff.
C
C
Just
kind
of
candidly
I
feel
like
I
I.
Don't
have
enough
of
my
own
time
and
attention
to
give
to
this
to
help
push
it
along.
So,
if
I
could
make
a
request,
it's
that
either
you
were
or
Vince
sue.
Whoever
wants
to
kind
of
pick
up
as
champion
I.
Think
the
most
important
next
phase
is
scheduling
those
things
and
like
having
people
to
show
up.
You
know
people
want
to
champion
individual
proposals
and
aren't
showing
up
to
meetings
that
are
scheduled
and,
like
that's
a
different
problem
that
we
can
address.
A
C
A
C
C
Yeah
I
think
I
made
the
channel
and
then
didn't
do
anything
so
could
I
do
that
before
the
watch
me
I
feel
like
I,
must
must
have
mentioned
that
anyhow
I'm
hoping
actually
to
to
get
more
kind
of
like
chatting
that's
happening
on
the
slack
there's
a
very
healthy
amount
of
chatting
happening
amongst
a
handful
of
the
graphical
folks
or
two
in
particular.
A
cow
so
like
those
folks
are,
are
chatting
back
and
forth
about
the
Summer
of
Code
and
how
to
get
graphical
involved.
So
there's
there's
some
decent
discussion
happening.
C
C
C
B
Feel
like
one
foot,
so
we
discuss
at
multiple
times
and
what
I
saw
during
previous
discussions.
It's
like
even
even
Winston
said
he
thinks
like.
There
is
a
bunch
of
solution
to
this
problem,
but
he
feel
like
one
also
be,
should
be
added
anyway,
so
actually
I.
Think
more
and
more
people
agreeing
that
one
of
its
useful
mechanism
on
its
own,
even
if
it's
not
so
in
the
entire
issue,
so
I
think
like
another.
Another
direction
we
can
take
in
which
channel
or
in
special
meeting
is
to
discuss.
B
Yeah
go
ahead,
yeah.
One
thing
that
people
discussed
also
and
I
think
it
was
part
of
venery
original
idea-
is
to
have
like
a
variant
type
and
start
from
input
types,
but
also
think
about
output
types.
So
I
think
Warren
types
are
useful
on
its
own
or
in
some
one,
which
is
called
the
new
types
like
I
think
in
rust,
the
code,
the
new
is,
they
have
different
type
of
new
types
and
they
have
can
cover
new
values
can
have
values
on
that
song.
C
C
G
G
It
is
referring
to
sending
the
actual
graph
QL
query
text
itself
to
the
server
as
part
of
the
graphical
over
HTTP
working
group
we're
trying
to
discuss
what
actually
we
need
to
do
with
regard
to
actually
turning
that
serving
over
HTTP
mini
article
into
an
actual
specification,
and
as
part
of
that,
we
want
to
make
sure
that
things
like
this
and
nailed
down
and,
of
course,
we're
using
application.
Slash
graph
to
oh,
but
it's
not
actually
registered
in
the
I
naa
I
am
a
media
type
library
where
I
think
it
should
be
I
know.
G
It's
also
been
discussed
quite
a
lot,
there's
also
derivative
types.
So,
for
example,
you
could
the
response
type
for
a
graph.
Your
request
over
HTTP
is
typically
not
always
but
typically
JSON,
but
it
is
also
JSON
with
constraints
right.
It's
constraints
that
it
adheres
to
the
spec.
It
has
the
data
and
errors,
we've
even
specified
that
it
has
the
extensions
field
and
shouldn't
have
any
other
further
fields.
So
it's
not
just
generic
JSON.
G
It
is
a
specific
thing
and
there
is
the
ability
in
the
I
n
I
am
a
media
type
to
be
able
to
say
things
like
application,
slash
graph
to
a
Plus
JSON.
So
it's
effectively
saying
this
is
a
JSON
form
of
graph
QL
application
type
or
something
like
that.
Now,
I'm
not
super
familiar
with
these
things,
so
really
I'm
just
starting
to
explore
these
a
little
bit.
But
what
I'm
keen
to
know
is
a
does.
Anyone
else
here
know
a
lot
more
about
this
stuff
than
I
do,
which
is
very
little
and
B.
G
What
is
the
status
of
the
various
things
that
we've
done
about
application?
Slash
graph
QL
anywhere,
like
I,
struggled
using
Google
to
track
down
any
particular
specification
that
we've
got
for
this
I
can
find
it
in
the
graph
key
Oh
Jess
tests,
for
example,
and
Express
graph
qo
and,
in
fact,
in
graphical
Java
and
a
whole
bunch
of
other
libraries,
but
there's
no
like
concrete
single
place
that
defines
it
yet
as
far
as
I'm
aware,
so
is
anywhere
else
aware
of
that
kind
of
thing.
C
Otherwise,
my
my
biggest
gripe
about
mime
types
is
that
there's
like
freaking
million
of
them,
and
if
you
have
anything
that
needs
to
deal
with
mime
types,
you
have
to
like
figure
out
how
to
parse
those
that
thing,
and
you
don't
know
how
to
address
99.99%
of
them
anyway,
and
so
it
ends.
She
liked
not
being
a
particularly
useful
thing,
and
my
my
hope
is
that
we
could
build
out
the
Groff
kill
over
HTTP
spec
completely
on
top
of
existing
HTTP
and
JSON
types
and
I'm.
C
Actually,
I,
don't
know
enough
to
have
like
a
strong
opinion,
but
I
question
whether
the
Plus
JSON
style,
mime
type
is
valuable
or
not,
that
might
kind
of
like
we
could
make
its
way
down
all
the
way
to
server-side
tools
and
anything.
That's
actually
dealing
with
mime
types
like
did
they
just
do
they
handle
that
Plus
JSON
and
then
just
like
throw
away
the
thing
that
comes
before
the
plus
and
treated
as
JSON.
What
are
they
doing
with
it?
Or
is
it
actually
a
headache
for
them?
C
G
So,
basically,
what
we're
saying
so
far
in
the
graph
go
over
HTTP
spec
working
group
is
a
an
API
that
responds
just
entirely
with
graph
killed,
200
errors,
no
matter
what
the
hell
happens
is
a
perfectly
valid
graph,
your
API,
that
is
fine.
However,
some
graph,
QL
api's,
do
respond
with
other
status
codes,
and
that
is
also
fine
in
certain
circumstances,
and
what
we're
trying
to
do
is
to
nail
down
what
those
circumstances
are.
So
what
we've
basically
said
so
far
is
if
you
get
to
the
execution
step
of
graph,
you
are
so
you've
done.
G
The
validation
you've
done
all
the
rest
of
that,
and
you
know
everything's
good
and
you
can
start
executing
it,
but,
like
one
of
your
resolvers
throws
an
error
or
something
like
that.
That
should
absolutely
be
a
200
status
code
that
is
like.
We
have
successfully
failed
to
execute
this
thing
for
you,
I,
like.
G
The
problem
that
we
have
is
what
happens
before
then.
So,
for
example,
if
you
send
a
request
where
the
Graf
kill
query
itself
is
not
valid,
maybe
it's
syntactically
not
valid.
Maybe
it
purely
just
doesn't
valid
a
against
the
schema.
Some
servers
will
respond
with
a
400
during
that
and
I
believe
that
that's
a
perfectly
valid
thing
to
do.
The
problem
then
comes.
Of
course
there
are
other
things
that
happen
in
the
HTTP
layers
that
also
give
non
200
status
codes,
so
you
might
have
rate
limiting.
G
You
might
have
permission
denied
to
even
talk
to
this
API.
When
you
have
those
things
they
may
well
respond
with
HTML
or
forbidden
page,
they
may
respond
with
JSON
that
JSON
may
not
be
in
graph
QL
compatible
format,
so
it
might
be
a
JSON
object.
That's
coming
from
an
intermediary
server,
some
kind
of
proxy
that
does
protections
for
against
your
API,
and
we
can't
know
whether
to
treat
that
response
as
a
valid
graph.
Your
response
with
the
errors
object
or
not.
We
can
do
it
by
sort
of
sniffing
and
going
well.
G
It
looks
like
it's
the
right
shape,
so
yeah,
maybe,
but
this
is
where
something
like
application,
slash
graph,
QL
plus
JSON,
would
say.
This
is
concretely
a
graph.
Your
response
to
your
query,
even
though
it
has
a
non
200
status
code-
and
you
can
rely
on
this
and
what
we're
potentially
saying
at
the
moment
is:
if
we
get
a
non
200
status
code,
then
we
just
assume
that
it's
an
error
and
we
don't.
We
basically
say
the
client
shouldn't
treat
this
as
a
valid
graph
kill
response.
B
B
To
resurrect
even
use
cases
without
a
stitch
be
involved
because
in
mind
at
appreciate
extension,
so
in
my
operation
system
you
can
associate
program
with
this
extension
and
like
there
is
bunch
of
other,
even
known
as
TTP
cases,
depending
on
mind
types.
Also,
it's
like
if
you
open
dev
tools,
is
really
cool
to
sort
and
see
graph.
Clearly,
graph
key
require
a
separate
list
sorted
as
a
group.
B
I
have
some
context
on
how
to
because
I
was
involved
in
of
this
open
Ipsy
here
previously,
and
they
tried
to
at
least
they
discussed
document
in
my
tribe.
It's
not
a
simple,
but
at
the
same
time,
not
as
hard
technically,
you
need
to
publish
her
if
she
official
RFC,
an
official
format
to
be
able
to
claim
my
type
outside
of
London
also
have
special
wonder
zone,
but
outside
offenders
on
a
bicycle
into
a
taxi
and
can
be
separately
philosopher.
B
The
recent
example:
some
person
wrote
that
she
would
be
D
type
and
it
doesn't
contain
description
of
beam
before
Mata
just
say
wait.
This
is
a
receipt,
might
might
die
for
being
P
format,
but
they
asked
also
for
some
required
sections.
For
example,
security
consideration,
so
it's
required,
so
we
need
to
write
a
security
consideration
section
for
graph
key.
So
there
is
a
bunch
of
like
small
details,
it's
not
as
simple
as
writing,
email
to
somebody.
B
It's
like
entire
process
of
claiming
there
is
like
group
who
actually
you
can
publish
informally,
because
we
have
different
statuses
and
formal
one.
Basically,
this
organization
just
review
your
crime
of
a
new
English.
They
don't
review
content
of
a
document,
but
Co
you
possible
to
claim
my
taxes
inform
RFC,
so
it's
possible,
but
somebody
need
to
invest
or
pick
number
of
hours
in
doing
that
and
learn
with
six
month
for
Matt
fall
for
doing
RFC
properly
because
they
it's
a
lot
of
bureaucracy.
B
C
B
I
would
first
like
figure
out
graphically
or
CDP
and,
as
we
read,
first
version
would
be
like
everybody
is
compatible
and
when
do
I
gather
all
the
vendors
figure
out,
what
we
can
change
and
my
type
can
be
good
feature
for
so
we
can
can
actually
do
some,
some
always
breaking
changes.
Saying
if
you,
for
example,
like
when
Joe
I,
remember
you,
you
proposal
was
to
add
extension
field,
to
request
and
for
response
we
forbid
any
other
field
except
or
extension
errors
and
data.
B
So
ever
if
you
should
go
into
extensions
for
requests,
we
don't
have
extensions
and
vendors
right
now
could
bunch
of
fields
directly
on
top
level.
So
if
we
claim
my
type
right
now,
we
basically
wouldn't
possibility
to
force
everybody
to
use
extension,
subfield
and
put
or
ex
extension
inside
it.
I,
don't
say
it's
like
nice
start
with
one,
but
I
think
it's
very
viable
what
we
do
command
under
with
mime
type.
So
you
need
to
really
be
sure
before
before,
like
pulling
the
trigger.
G
Separately,
if
I
can
just
change
the
subject
slightly
and
talk
about
the
graphic
HTTP
working
group,
one
other
thing:
we've
stated,
which
I
just
wanted
to
run
by
the
working
group
here,
is
that
basically
any
other
200
status
code
to
xxxx
status
code,
that
is
not
200
is
invalid.
Just
straight
off
the
bat
so
like
201
created,
doesn't
make
sense
to
use,
because
that's
a
field
concern
within
the
graph
now
schema.
You
may
run
more
than
one
mutation.
It
shouldn't
make
sense.
G
B
H
C
To
your
point
about
it,
sometimes
it's
hard
to
know
what's
before
that
you
know
if
you're
putting
layers
in
front
of
your
graphical
server,
those
might
have
their
own
codes.
Does
that
make
it
not
a
graphical
server
anymore
like
there's,
there's
some
complication
there,
but
your
general
guideline,
I
think,
is
sound.
Maybe
another
way
you
can
frame.
It
is
any
like
basically
like
describe
each
HTTP
code.
That
does
make
sense
and
then
say
any
HTTP
code
not
referenced
here
has
undefined
behavior
according
to
the
spec?
C
D
Mean
I
heard
I
might
have
misheard
this,
but
it
sounded
like
you
were
gonna,
be
able
to
be
able
to
send
off
an
application,
got
ql,
but
also
get
back
application
in
graphical
push
json.
I
think
you
actually
need
two
different
non
types
there
right,
because
one
is
a
subset
of
json
and
the
other
one
is
a
string
of
text
right.
G
There
absolutely
is,
and
potentially
also
a
third
mime
type
as
well,
because
there's
also
the
JSON
format
that
you
sent
to
the
server
as
opposed
to
the
one
that
you
get
back
the
query
variables
operation
name,
so
I
don't
know
whether
those
would
potentially
be
the
same
mime
type
and
you
just
know
which
direction
you're
talking
or
whether
they
would
need
separate
ones.
But
the
application
starts
craft
UO
is,
is
the
textual
format,
which
is
definitely
different
from
the
JSON
one.
C
Looking
I'm
also
question
whether
the
application
graph
QL
mime
type,
just
as
like
a
text
string
of
graph
kill,
is
the
thing
that
we
should
include
in
the
HTTP
spec,
because
it
doesn't
have
a
place
for
you
to
include
variables
and
that
transition
seems
kind
of
confusing
like
if
later
you
decide.
Oh
right,
I
need
a
variable
here,
and
now
you
realize
you
have
to
completely
change
your
request
format.
We.
G
G
Yeah
yeah
yeah,
the
query
string
gets
the
variables
in
in
JSON
format
in
query.
You
know
variables.
Equals
parameters
is
certainly
an
interesting
communication
method
and
there
are
people
that
are
using
that
so
yeah
I'm
actually
quite
open
to
just
not
standardizing
that
at
all
and
just
only
standardizing
the
JSON
communication
methods.
It
would
certainly
make
the
specs
simpler
and
saying
there
is
this
other
way,
but
that's
kind
of
you
know
vendor-specific
or
whatever.
What
do
you
think
on
that?
Lee.
A
Though
we
we
do
the
same
thing,
we
provide
public
graphically,
yeah
I
accepts
variables
as
a
pram,
I,
say
the
query,
string,
cram
or,
and
the
graph
QL
applications
graphical
online
type
and
that's
what
we
accepting
so
I
think
it
from
from
what
I've
seen
in
the
wild
that's
pretty
standard
already,
even
if
it's
not
actually
formalized
anywhere.
Okay,
you.
C
A
F
I
wonder
if
this
is
something
that
is
worth
resurrecting
when
my
old
ideas
about
supporting
some
sort
of
capabilities,
query
at
the
HTTP
layer,
I,
don't
think
this
belongs
in
official
graphical
spec,
but
something
that
says
like
you
know,
it's
clear
that
what
we're
talking
about
any
one
of
the
combinations
of
these
things
could
work
right.
I
could
say
all
graphical
operations
have
to
happen
on
which
to
be
post.
F
Errors
of
the
graphical
level
will
result
in
HTTP
status
code
200,
because
the
request
successfully
managed
to
graph
kill
and
we're
treating
HTTP
merely
as
a
transport
right.
So
we
could
do
that
I'm
hi.
This
is
hypothetical
I'm,
not
saying
this
is
a
good
solution.
I'm
just
using,
but
that
example
forms.
F
Let's
call
it
a
profile
and
any
other
combination
of
behaviors,
of
HTTP
verbs
and
status
codes,
and
what
have
you
for
another
profile
and
which
one
of
these
you
use
could
be
defined
within
it
just
like
what
we
do
with
that
specified
by
it
right.
If
we
imagine
that
at
the
HTTP
spec
level,
you
have
the
ability
to
issue
a
standard
query,
a
particular
well-known
route,
and
it
just
tells
you
which
profile
you're
using
that
way,
we're
on
ambiguous.
G
Yeah
I
think
that's
a
great
point.
Rubber.
We've
we've
been
discussing
this
a
fair
amount
in
the
HTTP
working
group
as
well,
indicating
like
all
sorts
of
like
have
you
implemented
persistent
queries
and
imps,
if
so,
in
which
flavor
and
so
on,
and
so
forth,
and
saying
what
things
are
supported
and
potentially
even
including
what
things
you're
using.
But
this
is
all
post
1.0,
because
the
the
1.0
for
the
HTTP
spec
is
intended
to
basically
nail
down
what
is
the
current
status?
What
what
the
you
know?
G
99%
of
graph,
your
own
communications
over
HTTP,
are
doing
so
that
we
can
have
a
standard
base
that
everyone
can
build
clients
off
of
in
order
to
then
move
forwards,
and
we
absolutely
want
to
indicate
things
like
you
know:
optional
support
for
particular
yeah.
You
know
other
extensions
to
the
protocol,
but
that
is
a
later
concern.
We
just
want
to
cover
the
the
most
common,
the
lowest
common
denominator
stuff,
currently.
B
I
have
suggestion.
Can
we
can
some
wonder
scoured
statistics
if
you
know
like,
because
usually
people
implement
stuff
because
other
implemented
stuff,
so
we've
simplified
format
way
so
I
post
with
query
parameters?
Other
vendors
here
like
they
need
implemented,
but
for
me
the
most
important
question:
if
what
what
way
of
sending
virus
developers
are
using,
who
and
developers
so
I
would
be
interested
to
have
statistics
if
nobody,
using
with
with
method
of
post
with
query
parameters.
Oh
it's
like
couple
percentage
of
traffic,
so
I
don't
think
we
need
to
standardize
it.
B
C
Cool
idea,
I,
like
it
you
mean,
even
if
there's
that
Stata
is
relatively
low,
I
agree
that
it's
still
worth
documenting
it,
so
that
people
who
are
using
it.
Maybe
it's
just
a
question
of
what's
required
or
optional
in
the
spec
like
if
you
say,
I,
am
a
graphical
HTTP
server
which
of
these
modes
are
you
required
to
support
and
which
ones
are
optionally
supported,
I,
like
Rob's
idea
of
having
some
way
to
document
these
things
at
like
an
options,
query
or
something
like
that?
G
We
we
have.
One
of
the
people
on
the
spectrum
is
Jayden
CEREC
who's
behind
the
graphical
upload
features
for
uploading
through
graphical
fields,
so
that
of
course,
needs
a
whole
like
doing
things
in
a
different
way
than
most
of
the
server's
work.
Currently,
so
we
def
like,
we
would
like
to
indicate
that
this
server
supports
that
and
things
like
that
as
well.
C
G
G
There
was
an
error
and
we
stopped
there
from
a
client
perspective
and
it's
up
to
the
client
then
to
do
a
vendor,
specific
agreement
to
say
when
it's
from
this
server,
then
we
can
process
it
more
whatever,
because
the
specs
meant
to
be
generic
I
think
we
can
just
basically
say
if
it's
a
400
500,
we
don't
know
unless
something
else,
and
we
don't
know
what
that
is
yeah.
Maybe
a
header.
B
3
H
is
4,
so
usually,
if
quarry
start
executing,
we
always
Richard
200
except
one
H
case
it's
in
express
craft
here,
I,
don't
true
bottom
server,
but
an
Express
graph
here
if
error
propagation
heat
topo.
So
it's
like
everything
is
not
knowable
anything
and
let's
hit
like
data.
So
you
cannot
provide
any
data
at
all
and
you
break
in
contract
and
with
mean
we
return.
I
think
like
500
I
need
to
check,
but
I
think
it's
500
and
it's
a
tricky
question.
B
People
constantly
open
issue
about
it,
but
it's
also
easy
because
when
you
have
a
query
and
you
use
my
cogent
or
other
tools,
huge
was
that
data
will
always
conform
certain
shape.
So
if
certain
field,
so
that
a
is
always
like
present
and
it's
always
like
an
object
and
let's
have
all
no
Nobu
fields.
If
error
propagation
hit
topple,
it's
mean
like
you,
cannot
provide
any
data
at
all
and
I.
B
A
G
But
that
match
should
still
result
in
null
data,
though
right
so
you're
saying
a
field
on
the
query.
Object,
for
example,
were
to
be
not
nullable
and
were
to
throw
then
effectively.
The
query
object
itself
would
be
the
catch
for
that
and
the
schema
gets
given
the
query
type.
It
doesn't
get
given
an
honorable
query
type,
for
example,
so
I
think
the
the
query
type
itself
is
null
Abul.
So
then
data
would
be
null
because
that
represents
the
the
query
type
I
think,
but
I'm
not
sure
that
was.
C
Know
but
yeah
no
you're
right,
I'm,
looking
it
up
in
the
spec
now,
if
an
error
was
encountered
during
the
execution
that
prevented
a
valid
response,
the
data
entry
in
the
response
should
be
null
if
an
error
is
encountered
before
execution
begins.
The
data
entry
should
not
be
present
in
the
results,
so
the
data
eki
not
being
present
means
that
you
encountered
an
error
during
like
it.
Either
was
not
syntactically
valid
or
it
didn't,
or
it
failed
validation
and
the
data
entry
being
null
means
that
execution
was
attempted
but
failed,
but
to
Allen's
point.
C
Then
the
question
is:
what
is
the
correct,
HTTP
status
code?
For
such
a
result?
The
Express
graph
QL
is
non
200
for
this.
My
opinion
is
that
that
that
is
the
correct
response.
My
mental
model
for
how
this
works
is
like
try-catch,
so
you
have
fields
that
are
able
to
catch
errors
and
convert
them
into
a
valid
null
result.
But
the
data
level
is
like
that's
not
a
graphical
field.
Right,
that's
a
top
level,
that's
just
like
formatting
the
result
of
the
entire
payload,
and
so
what
does
it
mean
for
your
entire
top
level?
C
G
Because
we're
because
we're
trying
to
specify
everything,
one
of
the
things
we've
said
is,
if
you
just
always
return
with
the
200,
you
are
valid
and
I
want
to
make
sure
that
that
is
okay,
so
like
if
it's
a
validation,
error
and
you've
got
an
errors
object.
You
know,
you've
not
got
data,
you've
only
got
errors,
and
you
give
that
back
to
the
client
over
200.
Is
that
something
that
we
should
allow
in
the
graph
QL
HTTP
spec?
G
C
Sense
is
no
I
think
we
should
have.
We
shouldn't
have
pretty
firm
rules
about
what
what
which
code
means,
what
in
which
scenarios
I
think
we
should
reserve
a
200
only
for
the
scenario
where
the
Cray
was
saying
tactically
valid.
It
passed,
validation,
it
executed
and
some
data
was
appropriately
returned
as
a
result
like
at
least
the
top
level
query
object
was
returned,
so
the
data
field
is
nominal.
That's
that
entire
pipe
results
in
a
200.
K
C
G
G
What
we've
discussed
so
far,
the
four
batching
assuming
the
batch
itself,
was
able
to
execute
you
get
200
for
the
batch
and
then
each
individual
entry
would
get
its
own
status
codes
just
as
you
described,
but
batching
is
not
something
that
we're
gonna
do
in
our
version
once
back.
That
would
be
an
extension
in
a
later
version,
so
in
I.
So
what
you're
suggesting
at
the
moment
Lee
is
a
much
stronger
form
of
the
status
codes
than
what
we
were
currently
proposing
in
the
HTTP
spec,
which
is
perfectly
fine.
G
G
One
of
the
aims
of
the
or
one
of
the
we
haven't
really
got
a
mission
statement
yeah,
but
one
of
the
things
that
we've
saw
hinted
at
being.
The
mission
statement
is
to
rather
than
saying
what
should
be
the
case
saying
what
is
the
case
so
basically,
is
that
the
right
direction,
or
should
we
be
writing
a
spec
about
what
should
be
the
case?
We'll
say
them:
what
is
the
case.
C
My
sense
is
that,
if
it's
a
speck,
it
should
be
all
about
what
should
be
the
case
now.
Obviously
you
need
to
pin
that
in
reality,
so
one
way
to
think
about
this
is
there
exists
some
unwritten
spec
out
there.
That
is
what
you're
talking
about
that
just
describes
what
everyone
is
doing
and
then
by
migrating
from
that
to
a
thing.
That
is
what
we
want
you're
introducing
breaking
changes,
so
maybe
it's
still
worthwhile
to
write
something
you
don't
have
to
necessarily
call
it
a
spec.
C
You
can
just
call
it
research,
something
like
that,
like
here's,
a
documentation
of
the
various
ways
graphical
is
being
used
over
HTTP
the
nice
thing
about
being
honest
about
being
documentation
and
describing
what
is
what
is
happening
rather
than
what
we
want
to
be
happening.
Is
that
you
can
like
write.
You
know
when
it
says
here's
one
potential
way
to
use
graphical.
You
can
say:
that's
the
Shopify
way,
chocolate
fine!
Does
it
that
way?
Oh
and
Facebook.
C
Does
it
this
slightly
different
way,
and
you
can
make
it
clear
so,
when
you're
looking
back
at
that
research,
you
know
exactly
okay.
If
we
broke
that
who
are
the
people,
we
should
go
talk
to
you
first
to
figure
out
how
to
do
a
migration
that
way
when
we're
writing
out
a
spec.
That's
like
here's,
your
writing!
A
brand
new
graphical
server,
here's
the
spec
that
you
should
try
to
abide
by!
C
That
gives
the
most
value
to
clients
what
we
do
that
we'll
start
to
see
a
delta
between
the
two
and
then
we'll
need
to
resolve
all
those
deltas.
We'll
need
to
be
able
to
say:
okay,
that's
a
private
API
who
cares
as
long
as
your
clients
are
happy
with
their
private
API
like
what
like
what
value
you're
getting
ascribing
to
the
spec
anyway.
C
If
it's
public
API
is
you'll
either
have
to
say,
like
those
are
vendor
specific
oddities
for
historical
reasons,
we'll
stick
around
or
here's
a
migration
path
or
actually
this
one
is
not
possible
because
the
way
that
you
expect
it
is
completely
counter
to
the
way
it
works
in
practice.
So
having
that
research
will
still
be
valuable
to
inform
that,
but
I
do
think
that
it
like
at
some
point
we're
gonna
want
to
do
that
right,
like
if
it's
not
now
it
might
be
next
year,
where
we're
like.
C
Okay,
we've
had
this
graphical
HTTP
spec
for
a
while,
but
it,
but
it
documented
what
was
it
doesn't
document
what
we
want
so
now
we
want
to
do
what
we
want,
and
now
we
realize
like.
Oh
crap,
we
got
to
do
all
these
breaking
changes
and
all
these
new
people
have
built
on
top
of
this
spec
I.
Think
the
earlier
you
address
the
breaking
changes
for
this
minimal
set
the
easier
it's
going
to
be
to
iterate
on
top
of
that
in
the
future.
G
C
A
great
question
once
I
hit
stop.
It
goes
into
some
netherworld
where
it
spins
and
says
waiting
and
I
believe
at
some
point.
It
stops
and
then
I
get
a
link,
so
I'll
figure
that
out
originally
what
we
were
trying
to
do
was
we
just
get
like
a
movie
file,
and
so
it's
hard
to
put
it
in
a
place
we
can
get
to
it.
The
goal
was
to
put
that
on
YouTube,
but
YouTube
requires
a
lot
of
verification
to
upload
anything
longer
than
a
couple
of
minutes,
and
these
are
usually
more
Verne's
than
an
hour.
C
K
Actually
pretty
easy
but
assume
we're
not
sent
you
an
email.
You
have
to
go
to
zoom
website
because
we're
doing
we're
recording
our
stand-ups
for
hot
chocolate,
so
you're
going
to
zoom
website,
there's
a
recording
section
and
after
2
or
3
days,
usually
you
can
download
the
recordings.
But
because
now
everybody
is
using
zoom
for
online
meetings
in
the
corona
classes
it
takes
sometimes
a
week
or
1
and
a
half,
but
then
you
can
download
it
and
this
file
you
can
pretty
easily
upload
directly
to
YouTube.
K
K
K
C
A
A
You've
got
a
throttle
error
and
in
this
case
we
gave
you
a
load
of
429,
because
that
was
a
throttle
that
happened
outside
of
query
execution
and
in
this
case
we
gave
you
a
throttle
there,
but
we
didn't
give
you
a
429,
because
it
happened
inside
client,
it's
query,
execution
and,
and
then
the
second
half
of
that
is
that
if
there
are
things
that
happen
inside
a
query
execution,
obviously
you
can
have
multiple
errors.
They
can
have
multiple
status
codes,
which
one
do
you
picked.
G
Yeah
the
whole
multiple
errors
thing
is
why
we
basically
said
as
soon
as
you
get
as
far
as
actually
executing
the
query.
Then
it's
a
200
even
if
you've
got
all
those
errors
dies,
are
200,
it's
more
the
if
I
can't
even
attempt
to
execute
the
query
rate,
limiting,
for
example,
or
forbidden
errors,
or
things
like
that.
That's
where
we're
thinking
that
there
are
status
codes
but
you're,
effectively
saying
for
Shopify
you're
like
nope,
that's
fine!
It
still
is
still
a
graph
QL
issue,
we're
just
gonna.
A
There
are,
there
are
actually
there
was
a
bunch
of
places
in
our
code
right
now,
where
we
rescue
exceptions
outside
of
the
graft,
well
execution
engine
and
then
hard
code
return
200
with
this
JSON
body.
That
looks
like
graph
UL,
because
that
is
the
kind
of
the
most
convenient
for
the
client.
In
terms
of
at
a
later
point,
we
could
move
that
check
into
the
graph
to
execution
engine.
If
we
wanted
to
be
more
fine-grained
about
it
and
the
payload
response
wouldn't
change.
C
C
K
A
graphical
error
and
that's
why
we
also
always
use
200,
because
you
still
have
always
the
same
shape
and
if
you
get
a
status
code,
or
at
least
it's
like
that
now,
if
you
get
the
status
code
like
400,
that's
something
out
of
the
graph
context.
So
you
don't
get
a
guaranteed
graphical
response
or
that's
how
I
saw
yeah.
That's.
L
B
L
And
in
these
cases
we
aren't
returning
graph
QL
error
at
all
we're
just
returning
an
HTTP
status
code,
and
we
figured
that
that
not
only
helps
our
our
monitoring
of
errors
because
looking
into
the
graph
QL
errors
is
costly.
But
it
also
helps
in
those
more
obvious
cases
where
it's
not
even
related
to
graph
QL
and
what
Lee
brought
up
with
respect
to
the
syntax
problems.
That,
in
itself
is
not
really
a
graph
QL
error
either
that's
a
problem
with
the
request,
and
so
that
would
be
a
4x
X,
yeah
and.
A
And
I
think
I'm
actively
shocked
by
it
might
actually,
at
this
point,
not
return
a
200
graphical
error
for
index
errors.
They
might
just
return
a
4x
X,
as
we
do
like
for
authentication
and
stuff
that
happens
outside
of
like
at
the
nginx
layer
or
even
higher
in
the
stack,
but
we
can
return
to
hundreds
and
backfields
for
that.
We
just
it's
a
bad
request
and
we
could
get
out
at
the
before
anybody
gets
to
the
server.
That
knows
what
graph
UL
means:
I.
K
Agree
with
the
POSIX
and
pausing
errors,
but
validations
or
I
think
about
validation
is
already
a
part
of
the
graphical
execution
so
validating
a
query
for
something
I
think
a
400
is
too
strong
because
then
we
wouldn't
look
into
the
graphical
errors,
because
you're
building
up
all
those
validation,
results
and
validation
is
not
only
the
spec
validation.
Actually,
people
can
write
their
own
validation
was
on
top
of
that
and
so
I'm
a
bit
concerned
about
that.
We
draw.
L
K
G
So
so
this,
basically
all
harkens
back
to
what
I
was
saying
before,
with
the
whole
issue
of,
if
it's
a
non
200,
then
we
can't
trust
the
response,
because
we
don't
know
it's
definitely
a
graph
QL
error.
Hence
why
we're
discussing
the
whole
media
types
in
the
first
place,
yeah
and
I
I-
think
that
responding
with
a
200
with
errors
is
perfectly
a
valid
thing
to
do,
which
is
why
we
basically
stated
that
a
graphical
server
that
only
returns
two
hundreds
is
valid.
G
That
said,
some
clients,
many
people,
would
prefer
that
we
used
non
200
status
codes
to
represent
things
like
you
know,
invalid
queries,
validation,
failed.
That
is,
as
as
one
of
you
said,
sir
I
forget,
who
that
is
a
client
error
right.
The
client
has
submitted
something
to
the
server,
that's
just
literally
not
valid,
and
so
it
shouldn't
even
reach
the
graphic
you
execution
engine,
but
what
Michael
says
about
this
is
also
valid,
which
is
well
the
response
to.
G
G
C
Now
understand
why
you've
arrived
at
the
mime
type
being
the
critical
thing
to
discuss
I'm
100%
on
board,
with
with
what
you
originally
pitched
now,
which
is
my
my
desire
would
be
if
you
get
a
200.
That
means
that
you,
you
got
to
query
execution
and,
like
some
amount
of
that
succeeded,
there
could
still
be
an
errors
field
in
the
payload.
C
But,
like
you
have
a
non
null
data
field,
we
have
enough
all
data
field,
you
get
a
200
everything
else
that
indicates
that
either
there
is
a
problem
with
the
query
itself
or
it
indicates
the
server
failed
to
fulfill
your
query
completely,
in
which
case
it
shouldn't
be
200
anymore.
That
last
bit
I
can
I
can
see
more
debate
on,
but
the
previous
bits,
I
think,
are
pretty
clear-cut
like
if
you
have
a
syntax
error,
I
can't
see
why
that
would
be
a
200.
C
If
you
have
an
invalid
query,
that's
like
technically
it
doesn't
have
a
syntax
error,
but
it
it's
nonsensical.
It
can't
be
executed.
I
also
can't
see
why
we
should
be
returning
200
for
that,
but
I
I
completely
agree
that,
like
especially
when
to
start
layering
other
HTTP
services
on
these
things
you
have
to
you
have
to
know
how
to
interpret
these
non
200s
and
seems
like
mine
type,
is
exactly
the
right
way
to
do
that
and
like
don't
try
to
parse
HTML
as
JavaScript
or
JSON
or
graph
QL
JSON
you're
gonna
have
a
bad
time.
C
C
That
was
the
original
impetus
for
this
discussion
was
introducing
like
what
the
status
of
these
various
mind
types
that
we've
suggested
in
the
past,
and
if
we
would
need
something
for
the
response.
Specifically,
that
includes
that
lets.
You
know
whether
the
payload
is
the
data
errors,
extensions
response
that
you
would
expect
so
I
think
that
this
is
where
the
tricky
bit
has
come
in
the
past
is
you
want
to
know,
should
I
be
interpreting
this
response
as
a
JSON
payload?
C
That
has
a
data
field
in
errors,
field
in
extensions
field
and
the
only
way
that
we've
been
able
to
interpret
that
so
far
is
if
it's
a
200,
then
yes,
and
if
it's
not
200,
then
probably
no
and
I.
Think
what
we're
learning
here
is
that,
but
that's
probably
conflated
and
not
quite
right,
and
so
if,
if
we're
gonna
say
that
that's
not
the
right
thing,
then
what
is
and
Benji
suggestion
was
a
mime
type.
L
C
C
B
To
mention
that
it's
actually
a
good
idea
to
study
prior
art
because,
for
example,
swap
mimetype
as
far
as
I
remember
to
have
my
and
they
didn't
bother
to
add
it
to
my
database,
but
it's
like
in
so
ops
back
and
it's
like
application.
So
up
for
six
miles,
I
think
similar,
don't
remember
exactly
and
I.
B
Also,
if
I
remember
correctly,
GOP
I
was
on
my
type
and
they
also
as
far
as
I
know,
don't
put
it
in
mine
database
so
putting
something
inside
the
official
database
is
kind
of
secondary,
go
it's
not
preventing
us
from
using
mine
types
and
this
private
for
for
PC,
Mac,
Mahon
isthmus
for
so
open
jar,
PC,
so
I,
don't
see
why
we
cannot
use
it
was
might
have
to
give
you
some
additional
benefits.
Like
content
negotiation,
you
can
ask
server
and
do
support
craft
yield
and
service
area.
Super
crafty
mum
types
also
have
like
parameters.
B
So,
for
example,
you
can
specify
that
I
like
very
not
the
version
graph
here
but
like
maybe
you
can
pass
away
coercion.
Someone
gives
argument
for
system
for
most
people
using
it
for
encoding.
It
just
pacifies
it
to
like
type
of
encoding
of
a
pie
wall,
so
I
think,
like
mine
types,
are
actually
the
right
choice,
because
it's
already
existing
like
a
system
even
for
like
Express
server
or
servers
and
other
one,
which
is
there
is
like
body
parcels
and
people
will
comment
body
parser
for
graph
key.
Instead
of
like
doing.
C
C
Negotiation
is
also
an
interesting
way
to
handle
the
thing
that
Rob
was
talking
about,
of
knowing
what
a
server
can
and
can't
support
not
doesn't
completely
contain
everything
that
that
that
could
entail,
but
certainly
just
knowing
like
does
it
support
the
get
mode
or
the
post
mode
or
accepting
application
graph
field
directly
or
this
like
mixed
JSON
payload
content
negotiation
is
like
a
tried
and
true
way
to
handle
that.
So
it's
I
think
that's
pretty
interesting
too.
Doesn't.
L
B
B
We
cannot
use
mime
types
to
to
content
initiative,
server,
support
gear
to
post,
because
what
way
we
limited
to
HTTP
because
mytabs
universe,
so
they
can
be
used
over
other
transports,
so
I
think
it's
excellent,
so
solution
for
described
and
by
Wars,
but
not
a
way
how
he
sent
by
world.
So
it's
good.
C
C
C
G
B
Yes,
some
hope,
so
what
so
I
kind
of
point
it
was,
as
I
said
before
it
was
crazy
month.
So
I'm
like
I'm
mist,
was
two
working
groups,
graph
killers,
TTP
working
groups
and
before
I
was
in
it.
So
some
did
a
great
job
of
stepping
it
up
and
not
evolving
working
group
today,
I,
give
him
admit
rights
on
the
repo.
So
he's
able
to
do
all
my
stretchy
work
and
continue
eight
people
and
create
agendas.
So
yeah
he's
basically
responding
and
I.
B
C
C
M
Yeah
I
think
the
first
one
was
covered
already
like
about
like
upload
into
YouTube
meetings
and
the
second
one
is
just
about.
We
just
saw
that
graphic,
a
gs-15
got
released
and
I
wonder
if
I
don't
know.
Maybe
you've
talked
about
it
already
in
the
beginning
of
the
meeting
about
what's
next
and
also
in
terms
of
the
types
with
migration
and
if
we
can
help
somehow
and
if
it's
also
the
right
place
to
talk
about
it
like,
maybe
we
can
just
take
it
over
later.
We.
B
Have
a
stable
version,
we
actually
mean
I
think
we
need
to
coordinate
because
you're
responsible
the
guilt
responsible
for
a
bunch
of
models,
including
graphical
tools
recently,
and
we
need
to
coordinate
the
release
point
what
what
version
with
support
for
how
long
and
what
guarantees
we
provide
so
like,
especially
since
now
people
are
discovering
security
vulnerabilities
in
kind
of
killed,
Jesus,
mostly
like
denial,
service
attack,
attacks,
bad
cos.
We
need
to
coordinate
what
we
support
and
marilla
spawn,
but
I
think
yeah.
B
B
B
B
A
C
That
I
see
that
it
was
a
good
thing.
It
means
that
we
have
a
good
cadence
of
work,
we're
still
slightly
under
sometimes
I.
Think
more
often,
we
go
a
little
bit
over
two
hours
this
time
we're
good
under
okay.
Well,
then,
they
can
wrap
up
the
meeting
thanks
everybody,
this
healthy
discussion,
if
you
like,
we
made
pretty
good
progress
on
a
lot
of
stuff,
as
always
come
back
to
this
graph,
no
slack
to
continue
ongoing
discussion.