►
From YouTube: GraphQL Working Group - March 5, 2019
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
Yeah
another
suggestion:
can
we
add
the
into
agenda
upgrades
that
if
you
had
yourself,
you
agree
with
recording
and
to
be
recorded
in
what
case?
Yes,
we
can
set
up
after
recording
in
Zoo
I
also
heard
from
Roth
killed
over
CTP
and
is
working
whatever
going
through
it
intentioned
and
ten
point
and
about
agenda
I
had
another
items
as
a
spore
quest
about
duplicated
directive
on
arguments
and
put
values.
I
ask
original
after
to
join,
but
I
don't
see
human,
an
agenda
and
yes,
oh,
oh
I,.
B
B
B
D
D
But
one
place
I
could
see
it.
I
mean,
in
fact
is
if,
like
a
tool
like
graphical,
is
going
to
be
consuming
this
and
they
want
to
turn
that
into
a
clickable
URL
and
it's
not
a
valid
URL,
then
we're
pushing
that
work
on
to
the
multiple
clients
like
it
can
be
consuming
this
and
I.
Don't
know
if
that's
a
strong
enough
justification
to
do
it
or
not,
but
that's
the
one
case.
I
start
work.
E
C
That
that's
actually
very
recursive
thing.
What
we're
trying
to
do
here
because,
like
passing
your
Ellis
is
non-trivial,
and
you
would
expect
that
you
put
up
a
custom
scalar
which
references
the
spec
and
now
you
have
you
want
to
put
in
the
URL
passing
inside
the
spec
as
a
precursor
to
custom
scalar.
C
So,
like
the
custom
scale,
your
air
padding
is
non-trivial,
so
you
will
end
up
with
incompatible
implementations
across
boards
and
I'm.
Not
sure
the
value
is
really
there
to
be
honest
like
if
the
URL
is
not
writable
or
it
doesn't
open
in
a
tool,
then
then
be
it
but
like
in
form
of
and
in
general,
as
a
common
understanding,
I
think
it's
enough
to
say
it
should
be
new
air.
My
two
cents
I
think.
B
B
But
the
reason
why
I
brought
up
the
adding
value
is,
as
we've
discussed
it
so
far.
My
understanding
was
that
the
fact
that
it's
a
URL
actually
is
only
really
useful
that
you
can
like
a
human,
can
go
click
it
and
understand
what
it
means,
but
as
far
as
tools
matter
or
as
far
as
tools
care
about
this,
it's
really
just
an
opaque
string.
It's
a
it's
an
opaque
identifier
that
says
like.
If
you
see
this
particular
unique
string,
then
you
can
imbue
this
custom
scalar
with
these
known
types.
F
B
E
B
B
So
you
can
imagine
that
if
the
Apollo
client
decided
to
imbue
like
it
started
to
recognize
a
handful
of
date
types
then
it
would
start
to
imbue
those
properties,
and
you
know
if
it
saw
one
that
was
like
relative
URL
or
completely
opaque
garbled
up
straying
it'd,
be
like
what
to
put
the
house
that
we're
not
putting
that
in
front
of
our
our
consumers,
so
they're
there
does
has
to
be
some
like
social
agreement
on
picking
these
up
for
them
to
be
useful
by
tools.
So
I
do
think.
D
Think
I
agree
with
a
clear
picture.
This
should
just
be
a
I
think
that
we
say
it's
a
URL
and
we're
not
enforcing
it.
The
devil's
advocate
to
adding
it
later
is
that
I
think
adding
this
now
isn't
a
non-breaking
change,
but
adding
that
invalidation
later
would
be
so
that
would
be
the
one
benefit
for
doing
it.
Now.
It's
not
my
preference,
but.
B
B
Then
we
we
could
have
an
expansive
version
of
validation
and
we
can
maybe
also
kind
of
like
look
people
to
keep
a
tight
loop
on
this
like
if
anyone
spots
anything
that's
particularly
weird
happening
once
the
search
to
roll
out.
Maybe
we
can
be
reacted
quickly
with,
like
blog
posts
or
advice
or
something
beyond
technical
validation.
E
D
Released
it
earlier
this
week,
but
Iran
gave
me
feedback
on
that
last
night.
I
think
I
can
respond
to
that
later.
Today
it
was
all
pretty
minor
just
ordering
of
variables
and
things
like
that
and
so
I
think
that
will
be
pretty
much
ready
to
be
merged.
I
guess
you
know,
I'm
gonna
read
on
I
defer
that
decision
to
you
but
I
think
last
conversation
we
had
some
questions
just
about.
D
B
I'd
like
to
hold
a
firm
line
on,
what's
in
the
2020
firm
kind
of
the
spec,
also
kind
of
knowing
that,
from
a
practical
point
of
view,
people
really
track
the
draft
more
than
they
track.
The
version
cut
just
an
opportunity
for
us
to
publicize
it
so
we'll
let
this
be
the
the
first
major
piece
to
land
in
the
2021
cut:
okay,
cool
thanks
for
your
continued
focus
on
getting
this
right
and
for
Yvonne
for
continuing
to
review.
It
make
sure
it's
super
high
quality,
I
think
the
end
results
gonna
be
really
really
great.
G
So
this
is
maybe
out
of
the
blue,
but
this
is
basically
an
issue.
That's
kind
of
come
up
a
lot
for
the
past
over
the
past
like
couple
years
and
there's
like
some
links
there
to
sort
of
describe
like
what
the
issue
is.
But
basically,
if
you
have
union
fields
that
have
the
same
name
but
different
types,
and
you
can't
query
for
them-
that's
like
not
allowed.
Unless
you
alias
them
and
maybe,
as
you
can
imagine,
for
clients,
this
is
a
little
cumbersome
because
you
have.
G
If
you
have
like
a
lot
of
union
fields,
you
have
to
alias
every
single
one.
So
I
guess
I've
kind
of
done
a
little
research
there.
But
I
was
just
wondering
I
kind
of
wanted
to
get
like
a
clear
picture
of
like
why
the
change
was
made
to
make
it
stricter.
So
I
guess
this
used
to
be
allowed
and
then
it
there
was
a
change
that
was
made
which
is
linked
there.
G
B
H
G
And
I
and
they're
in
a
couple
of
the
issues
they're
sort
of
they
have
like
little
examples:
the
when
I
I
think
this
maybe
has
got
been
going
around
for
a
little
while,
but
I
originally
saw
this
and
an
issue
in
sangria.
So
that's
the
original
issue
in
sangria
is
the
one
where
I
originally
saw
it
and
then
I
have
an
issue.
That's
related
to
that.
G
Where
I
also
asked
the
same
question
and
then
the
main
issue
with
a
lot
of
discussion
is
like
the
graphic
you
ljs
version
of
all
of
this,
which
is
been
going
on
for
quite
a
long
time,
but
the
sangria
ones
have
like
pretty
good
examples
and
then
there's
even
a
more
recent
issue.
It
talks
about
this
all
again.
That
has
some
examples
too.
So
you
can
kind
of
see
like
what
exactly
we're
getting
that
there.
G
Yeah
Mike
I
heard
that
you
were
also
looking
into
this
and
we're
maybe
thinking
about
an
RFC
at
some
point.
Yeah
I
just
want
I've,
been
like
digging
around
and
I
just
wanted
to
get
like
more
of
an
understanding
if,
like
this,
is
something
that
we
could
actually
change
or
if
it's
like
off
the
table,
because
if
it
is
I
would
love
to
like
start
like
looking
into
like
making
an
RFC
for
it.
B
The
the
original
concern
which
we
can
talk
about,
whether
it's
still
a
concern
is
that
the
payload
so,
for
example,
Sasha
I'm,
looking
at
the
sangria
link
where
you
opened
it,
so
the
the
payload
of
that
object
is
gonna
have
like
an
object
with
a
single
reason
field
right.
If
one
of
those
two
types
apply
and
that
reason
field,
then
there's
a
question
of
what
is
the
type
of
you
know,
response
dot,
reason
mm-hmm
and
is
it
an
A
or
is
it
a
B?
B
And
you
you
don't
know
because
type
name
has
not
also
been
queried,
so
there's
no
way
to
differentiate
between
the
two,
which
means,
if
you're
a
strictly
parsing
client,
you
might
not
know
how
to
proceed
so.
Clearly,
that's
solvable
for
some
conflicts
between
you
know
any
type,
a
and
any
type
b,
but
it's
not
solvable
for
all
types,
a
and
tips
B.
B
So,
for
example,
if
the
reason
in
Taipei
I'm
this
is
like
not
gonna
fit
the
exact
example,
but
if
the
first
type
was
a
custom
scalar
of
the
date
and
then
the
second
one
was
a
string
or
a
custom
scalar
of
a
different
type
that
also
C
realized
a
string.
You
get
back
this
thing
and
then
the
reason
field
is
C
realized
as
a
string
and
the
JSON.
But
now
your
client
has
to
decide.
B
Do
I
interpret
that
as
a
date
and
try
to
parse
it
or
should
I
interpret
that
as
a
string
and
toss
someone
as
a
string
or
do
I
interpret
that
as
a
URL
yeah
they're
custom,
together
with
the
URL
and
parse
it
that
way,
and
if
it
chooses
incorrectly
like
it
could
crash
and
if
it
like
it
might
be
both
depending
on.
If
there's
like
a
list
of
these
and
have
to
go
through
the
list
and
decide
which
one
is,
which
you
know
these
communion
types.
B
I
It
could
surprise
the
client
with
that
scenario,
because
and
I
couldn't
find
any
that
doesn't
mean
there
aren't
any,
but
but
if
there
are
not
any,
that
means
that
a
client
requesting
things
that
are
ambiguous
is
just
you
know,
is
requesting
stuff
that
can't
handle
I.
Would
it
would
just
be
required
to
also
query
for
a
disambiguated
right
like
a
type
name
or
whatever,
and
so
I?
I
Don't
if,
if,
if
the
assumption
holds
true
that
there
are
no
scenarios
in
which
a
schema
change
could
surprise
to
make
a
query
that
somehow
becomes
ambiguous,
I
think,
at
least
in
my
mind,
that
probably
is
is
solved
just
by
the
by
telling
the
client.
If
you,
if
you
are
curious
about
this,
like
alias
them
separately,
they
do
everything
fall
back
to
the
current
way
of
querying
or
request
a
disambiguate.
J
J
G
Yeah
and
I
guess:
that's
sort
of
that's
sort
of
my
point
and
what
we've
been
running
into
is
that
clients,
at
least
from
our
side,
are
able
to
distinguish
between
these
things,
and
so
they
want
to
query
for
these
things
and
then
because
it
will
allow
you
to
they
have
to
alias
them
which
is
like
for
them.
They
don't.
They
could
just
not
in
these
cases,
but
they
have
to
so
it's
like
really
cumbersome,
I.
I
Mentioned
those
solving,
this
is
only
solving
a
very
small
portion
of
these
case
because
you
also
like
the
merge
rules,
also
to
do
with
arguments
that
are
passed
in
right
so
like
if
I
have,
like
you
know,
created
and
I
have
a
format
that,
like
is
safe,
so
that
states
passes
a
string
right.
It's
return
it
as
a
string
and
I
am
requesting
it
in
like
ISO
format
and
then,
like
some
other
format,
like
those
still
won't
merge,
even
though
they
are
scalars
being
returned
because
the
the
merge
rules
it's
difficult
to.
J
I
Yeah
I
totally
I
totally
agree.
This
is
a
separately
solvable
thing.
I
just
wanted
to
throw
that.
I
originally
encounter
this
following
like
relay
patterns
right
where,
where
your
components
are
specifying
the
fields
and
they
and
the
they're
composed
together
by
these,
like
like
higher-level
components,
and
so
it's
it's,
what
I
was
hoping
for
and
then
the
issue
that
I
open,
which
I
can
linked
it's
a
little
bit
more
like
stepping
back
further
and
say
like
how
do
like.
Is
there
a
mechanism
to
generically
avoid
conflicts?
I
K
Just
wanna
yeah
timing
here
and
provide
some
additional
context.
So
last
year,
in
the
graph
QL
accounts,
Matt
Mahoney
actually
had
to
talk
about
several
different
ways.
Like
clients,
side
can
parse
the
response,
and
one
of
the
ways
is
called
modular
fragment
models
which
is
aiming
at
solving
exactly
this
problem,
where
you
have
a
unions
that
have
names
that
a
few
names
that
are
in
conflict
as
well
as
interfaces
or
their
arguments.
So
in
fact,
at
Facebook.
We
just
group
all
of
these
problem,
like
that.
K
You
said
before,
like
not
only
the
specific
Union
want
one,
but
also
the
interface
one,
and
also
the
arguments
to
the
interface,
the
arguments
to
the
Union
field.
We
just
group
them
under
a
ugly
name
called
fat
interface.
It's
a
ridiculous
name,
and
it's
it's
definitely
like
being
creating
a
lot
of
problems
for
us
because
we
need
to
in
order
to
prevent
developers
ever
writing
any
conflicts.
K
We
need
to
do
a
whole
schema
validation,
which
is
like
looking
across
all
of
the
types,
whether
you
each
implements
any
shared
interface
or
whether
you
are
in
like
assured
unions
and
then
check
that
you
don't
have
any
conflicts
or
if
you
have
the
same
name,
you
have
to
be
exact
the
same
type
and
that
caused
a
like
ridiculous,
like
build
time
or
like
we
have
to
write
tests.
That,
like
takes
five
minutes
to
run
or
something
like
that.
I
G
I
guess
I
just
kind
of
want
to
know
like
like
what
a
path
forward
would
be
like
if
it
is
like
just
kind
of
looking
at,
like
all
of
this
as
a
whole
and
being
like.
Should
we
change
this
or,
if,
like
we
can
tackle
this
specific
issue.
If
this
is
something
we
could
change,
I
don't
know
but
yeah.
This
is.
This
is
definitely
something
that
we
have
run
into
a
lot
of
Twitter
and
I
did
see
Matt
Mahoney
stock.
G
So
if
this
particular
thing
changed
like
that
would
solve
a
lot
of
our
problems
that
maybe
like
eventually
we
can
change
it
wholesale,
but
yeah
I
guess
I
wanted
to
get
people's
thoughts
on
like
if
this
is
something
that
we
could
change
because
it
seems
like
it
wouldn't
affect
anything
else
like
this
is
something
we
maybe
could
change
and
then
maybe
we
could
talk
about
like
if
we
want
to
like
change
things
as
a
whole.
I,
don't
know
like
which
direction
to
go
the
other
people's
thoughts.
I.
J
C
C
Yeah
like
in
terms
of
allowing
this
one
edge
case
that
comes
to
my
mind,
is
like,
if
you
say
this
is
allowed
as
long
as
the
fields
cannot,
but
at
the
same
time
like
this
question
might
be
easily
answered
for
union.
But
if
you
have
like
a
hierarchy
of
fragments
bus
type
conditions,
this
condition
I
think
is
not
easily
answered
like
it's
it's
it's.
It
might
be
tricky
to
actually
force
this
into
the
spec
as
a
validation.
C
If
you
expanded
outside
of
unions,
or
even
maybe
inside
unions,
with
a
hierarchy
of
fragment
definitions,
it
might
be
tricky
like
we
had
some
edge
cases
around
us
in
the
past
where,
where
the
current
spec
doesn't
capture
all
conditions,
yeah
I
think
that
needs
to
be
explored.
If,
if
this
should
be
go
further,.
L
I
think
that
this
problem
has
a
different
has
another
root
to
the
problem,
say
the
spec
allows
to
specify
the
same
field
multiple
times
in
the
selection
set.
There
is
a
possibility
that
the
field
might
be
used
with
different
values,
for
the
arguments
of
the
arguments
are
defined
and
when
they
got
north
into
the
north
field,
the
only
one
that
takes
precedence
and
the
others
are
kept
unknown
or
ignored,
and
this
is
the
similar
thing
with
the
selection
sets
in
general,
because
in
case
the
selection
set
has
type
condition
on
it.
L
B
That's
definitely
right
and
just
to
back
up
a
bit
I
think
there's.
This
is
one
validation
rule
in
a
in
a
family
of
validation,
rules
about
how
selection
sets
and
fields
are
allowed
to
interact
an
overlap
that
solve
two
different
but
related
problems.
One
problem
is
something
that
we
certainly
can't
change,
which
is
a
server-side
problem
of.
Is
the
query
unambiguous
to
run,
which
specifically
is
about
arguments
right.
B
If
you
see
two
fields
with
different
arguments
in
the
same
selection
set
you
you
won't
know,
which
is
the
right
one
to
run
and
I
think
that
was
the
like.
The
the
first
link
sascha
that
you
put
in
there
of
the
like
five-year-old
issue,
mostly
talk
about
this.
You
know,
if
you
see
two
fields
that
say,
give
me
an
image
once
it's
size,
100
ones,
the
size
600,
you
get
your
image
back.
How
do
you
know
what
size
it
is
you
don't?
B
B
The
other
problem
which
is
related
but
different,
is
something
could
be
completely
unambiguous
to
run
on
the
server
but
ambiguous
to
the
client
right
and
that
that
I
think
is
what
we're
talking
about
here,
where
you
know
in
for
this
particular
example
of
the
two
different
Union
types
that
both
have
a
reason
field.
You
get
this
payload
back
and
that
reason
field
is
going
to
be
type
A
or
B.
The
the
server
had
all
the
information
it
needed
to
appropriately
execute
the
query,
but
the
payload
is
now
ambiguous
to
parse.
B
B
There's
one
thing:
that's
validation.
You
could
run
it
on
the
server
you
can
run
on
the
client,
but
it's
the
same
thing
and
if
we
start
to
tease
these
things
out,
we've
kind
of
discussed
this
a
little
bit
in
the
past.
We
call
it
like
graphical
linter
or
something
like
that
where
we
could
have
these
rules,
that
we
run
only
on
clients
but
not
on
servers.
Then
perhaps
this
rule
doesn't
necessarily
go
away,
but
it
becomes
an
optional
limb
rule
that
you
can
put
in
place.
If
your
particular
client
relies
on
that
behavior.
B
That's
kind
of
my
pops
I
hope
that
creates
enough
space
to
chart
a
path
forward.
The
one
last
thing
that
I'd
want
to
kind
of
highlight
if
you're
gonna
investigate
this
is
I,
think
the
the
validation
rules
are
not
always
perfect
in
isolation.
They
kind
of
assume
that
they're
gonna
be
run
as
part
of
this
group
and
in
particular
the
conflicting
argument.
Names
I,
don't
think
that
it
recurse
is
I,
think
those
it
just
checks
all
the
current
top-level
fields
to
see.
B
If
there's
a
problem
and
if
there's
no
topple
and
field
problems,
then
it
says
it's
fine,
because
it
assumes
that
if
there
are
two
fields
with
different
types
being
returned
that
that's
gonna
be
illegal
anyway,
and
so
there's
no
reason
to
recurse,
so
you
can
imagine
having
one
field:
that's
interphase,
a
one
field.
This
interface,
be,
there
are
different
types:
they
both
have
a
field,
that's
like
an
image
one
size,
100,
one
size,
500
and
now
like
at
runtime.
You
encounter
an
object.
B
That
is
applies
to
both
of
those
interfaces
now
you're
back
in
the
server
ambiguity
case,
so
we
just
have
to
make
sure
that
we've
had
unit
tests
in
place
that
checked
for
all
these,
like
squirrely
edge
cases
and
made
sure
that
if
we
just
like
blindly
pulled
this
rule
out
that
all
those
test
cases
would
still
do
the
thing
that
we
expect
them
to
do.
Yeah.
G
I
messed
around
a
little
bit
with
at
least
the
sangria
implementation
of
all
this
and
I
sort
of,
like
noticed
a
lot
of
well,
you
were
talking
about
just
now
so
yeah,
so
I
can
see
how
like
making
sure
that
we
kind
of
like
once
we
like,
pull
this
out.
We
kind
of
cover
the
whole
with
all
more
unit,
tennis
that
make
sense
I.
L
Have
a
question:
I
wonder
how
it
is
impacting
the
clients
in
general,
if
I
have
a
say,
method
or
I,
feel
that
produces
an
object,
type
interface
or
Union
and
in
the
annex
to
the
server
sends
the
completed
limitation
of
that
interface
or
some
you
know,
part,
and
then
the
client
is
fix,
that
by
specifying
the
fragments
fragment
on
one
type
condition
on
fragment
on
another
type
addition.
And
then,
when
that
guy
accounts
data
comes
to
the
client,
which
is
which
which
data
applies
to
which
kind
of
fragments
issue
file.
B
Is
quite
exactly
that's
exactly
the
problem
same
problem
yeah
these
are,
these
are
I
mean
the
the
specific
issues
here
talking
about
unions,
but
the
generic
problem
is
is
actually
fragment,
spreads,
so
fragment,
spreads
that
have
the
potential
to
conflict
or
not
conflict.
Can
they
have
fields
that
return
different
object,
types
and,
and
what
you
said
Gregg
is
exactly
right.
You
can
get
into
a
situation
where
the
payload
is
ambiguous
to
the
client.
It
was
clear
enough
that
the
server
knew
exactly
how
to
execute
it.
B
There
was
no
ambiguity
there,
but
the
payload
contained
ambiguities
and
the
client
can
be
in
a
position
where
it
doesn't
know
how
to
interpret
the
results.
I
think
the
question
here
is:
is
that
okay?
Is
it
okay
to
put
the
burden
of
that
on
the
client?
Knowing
that
the
client
could
just
like
assume
that
this
rule
is
in
place
and
aeleus
things
or
there's
many
ways
that
it
could
get
back
to
an
unambiguous
partial
result?
Are
we
okay
loosening
it,
knowing
that
different
clients
have
different
requirements
for
for
the
sand
acuity?
B
L
G
I
think
I
think.
That's
basically
like
the
main
question
here
is
like
that's
how
we
ran
into
this
it's
like
for
the
clients
it.
It
ends
up,
not
being
ambiguous,
because
they're
querying
for
type
name
as
well
and
they're
using
that
so
it's
like
is,
is
that
okay,
and
can
we
assume
that
that's
what
clients
are
doing
or
like?
If
they
don't
query
for
type
name,
then
they
don't
know
and
like
is
that
okay.
B
There
is
an
interesting
question
here,
which
is:
should
we
should
we
completely
remove
the
client
ambiguity,
sort
of
protection
from
the
speck
and
allow
this
wholesale,
or
should
we
should?
We
have
something
that
disambiguates
you
know
like
and
I,
don't
know
if
I
don't
know
what
the
right
answer
here
is,
but
right
now
we
we.
Basically
we
guarantee
that
the
results
will
always
be
disambiguated
and
like
in
a
really
strict
way
like
in
a
way.
That's
so
strict
that
clients
are
frustrated
by
how
strict
it
is.
We
could
say
that
you
have.
B
You
have
to
at
least
provide
a
response
that
is
theoretically
disambiguating
able,
like
the
information
exists
to
disambiguate
it,
but
that
also
kind
of
assumes
things
about
what
a
client
can
t
can't
do
and
that
might
also
be
burdensome
like.
Maybe
a
client
is
completely
fine
with
a
or
b
or
maybe
types,
a
and
b
are
themselves
disambiguate
able,
like
a
is
a
string
and
b,
is
an
INT,
and
you
can
just
kind
of
look
at
the
json
serialization
and
say
like
yeah.
B
I
can
tell
that
that
one
is
not
a
string,
so
I
know
how
to
parse
it
and
you
don't
need
type
name.
So
I
part
of
me
thinks
that
we
should
have
some
way
like
you
should
not
let
a
client
write
something
that's
completely
difficult
to
to
disambiguate,
but
part
of
me
thinks
like.
If
we're
gonna
take
this
out,
we
should
just
take
it
out
all
the
way
and
it's
like
if
the
thesis
here
is
you
know,
any
any
rule
that
we
put
in
place
is
gonna
be
frustrating
for
some
number
of
clients.
B
G
At
least
from
my
perspective,
I
think
that
would
be
okay
as
long
as
there
is
a
way
for
clients
to
disambiguate
on
their
own
so
like.
If
something
comes
back
and
is
ambiguous
and
like
they
need
to
disambiguate,
they
can
like
alias
it
or
something
there's
like
some
tool
available
that
they
can
still
like.
You
know,
make
it
like
non
ambiguous.
But
if
that's
not
true,
then
obviously
like
that
should
be
in
this
backin.
E
E
This
is
definitely
cases
worth
because
I
couldn't
see
where,
like
people
will
end
up,
writing
their
own
kind
of
not
quite
correct
descent
deviation
code
in
the
client
and
then
you
know
the
schema
changes
or
you
know
some
other
value
gets
returned
and
suddenly
they're
assuming
the
wrong
thing,
and
it
just
leads
to
a
bunch
of
bugs
not
necessarily
a
common
case,
but
it
is
something
that
we
avoid
by
being
like
very
clear
about
this.
In
this
way,
yeah.
B
That's
true,
there's
there's
a
whole
category
of
things
that
are
like.
We
protect
you
against
breaking
changes
in
various
ways.
So
we're
talking
before
about
like
what
kind
of
change
to
the
schema
could
result
in
a
surprise
to
a
client
and
change
a
previously
safe
query
that
could
be
disambiguate
on
the
client.
It's
the
one
that
could
not
be
I,
don't
think,
there's
any
valid,
schema
evolution.
That
would
do
that.
But
you
know
sometimes
we
have
to
think
beyond
that
and
what
are?
What
are
invalid
changes
to
the
schema?
Here's
why
we
so
to
go.
E
E
Maybe
this
train
used
to
always
be
something
that
was
clearly
not
a
date
and
then
some
user
inputs
a
date
into
that
field
and
suddenly
it's
a
string
that
happens
to
contain
a
date,
and
so
it
suddenly
becomes
ambiguous
right
and
I
can
I
can
see
a
client
just
like
not
the
client
author,
not
thinking
of
that
case
and
not
handling
it
and
parsing
it
incorrectly
and
making
bad
business
decisions
on
that.
On
that
case,
right.
B
So
you're
thinking
there
is
not
that
they
would
have
taken
some
well-written
disambiguation
code,
but
they
would
have
said,
like
oh
yeah,
sometimes
it's
a
date.
Sometimes
it's
not
I'll
like
try
to
parse
it
as
a
date
and
if
it
fails
and
clearly
it's
not
a
date
and
I'll
treat
it
as
the
other
case,
yeah.
E
B
That
for
sure,
if
we
give
them
the
opportunity
to
do
that,
I've
definitely
seen
people
code
write
code.
That
does
that
kind
of
thing
and
face
exactly
that
kind
of
issue.
Yeah
that
could
that
could
certainly
happen.
I
was
thinking
of
something
that
was
more
like,
well-written
disambiguation
code.
Like
someone
writes
a
query,
one
type
could
be
a
string,
one
type
could
be
an
int
and
it
says
like
cool,
that's
totally
disambiguate
able
I'll.
B
Yes,
that's
gonna
certainly
cause
some
havoc,
but
this
like
that,
could
be
an
example
where
the
amount
of
havoc
it
could
cause
is
increased
because
the
you
know
like
an
intelligent
disambiguation
in
disambiguating
client,
had
decided
previously
to
let
that
that
query
be
valid,
and
now
it's
in
a
position
where
it
like
cannot
tell
the
difference
between
them.
These
are
all
super
edge,
KC
and
they're,
like
in
the
realm
of
things
that
people
are
doing
that
are
bad
engineering,
but
I
do
think.
A
I'm
kind
of
worried
that
we
discuss
it,
it's
mostly
from
position
of
websites
or
no
mobile
coins.
As
I
understand,
I
can
phrasebook.
In
some
other
companies,
people
use
code
generation
and
write.
All
these
things
is
statically
typed
two
languages,
not
all
of
them
have
disjoint
unions.
So,
even
if
you
have
undergone
discord,
type
name
in
response
all
right,
we
you
need
to
generate
one
type
per
fragment,
so
wake
and
four
for
the
same
field
name.
You
cannot
create
Union,
who
is
like
in.
A
J
A
B
I
spend
a
lot
of
time
writing
code
generation
for
exactly
the
platforms
you're
talking
about,
and
that's
exactly
where
that,
like
five-year-old
issue
came
from.
That's
why
my
first
response
was
to
spit
out
like
Java
generated
code,
artifacts
cuz,
that's
what
I
was
working
on
at
the
time
and
exactly
the
kind
of
setup
that
you're
describing
is
kind
of
what
we
were
working
on.
The
original
fragment
models
for
Android,
where
Java
interfaces
where
there
was
no
ability
to
handle
this
joining
unions.
B
I
think
if
we
were
in
a
world
where
the
very
first
clients
that
we
were
tackling
were
like,
if
Swift
had
been
released
at
that
time-
and
that
was
the
first
thing
we're
doing-
we
were
to
looked
at
me
like
yeah.
Obviously,
disjoint
unions,
like
that's
how
the
clients
will
handle
this,
and
we
probably
wouldn't
have
even
put
this
rule
in
place
in
the
first
place.
B
The
reason
this
rule
got
put
in
place
is
because
both
our
objective-c
client
and
our
Java
client
didn't
have
a
way
to
do
these
disjoint
unions
and-
and
this
is
our
way
of
protecting
against
that.
But
I
think
that
the
question
here
that's
worth
asking
and
again
I,
don't
know
that
I
have
a
strong
opinion
on
the
answer
to
it
is.
B
So
you
know
it
would
say
like
hey,
you
can't
use
two
fields
without
aliasing
them
if
they
return
different
types,
because
I'll
generate
code
that
will
result
in
compiler
errors,
and
so
even
though
the
server
won't
restrict
that
for
you,
it
would.
The
I
think
part
of
the
reason
why
why
we
didn't
make
that
distinction
early
on.
Is
we
had
this
vision
that
tools
like
vs
code,
other
IDE
s?
Would
have
inline
validation
where
you
would
get
you
know
like
yellow
squiggly?
B
That's
some
historical
context,
though,
and
on
why
we
did
this
I
do
think
now
that
we're
in
a
position
where
our
tools
are
much
better
built
out,
it
can
start
to
explore
what
it
would
mean
to
move
this
stuff
out.
It's
part
of
the
reason
why
I
was
raising
that
maybe
there's
a
separate
grouping
of
these
are
like
in
the
past.
We've
considered
it
up
like
a
additional
optional
validation
rules,
the
graphical
linter
like.
B
G
Cool
actually
have
something
at
10,
so
I
can't
stay
much
longer,
but
maybe
I
can,
like
you
know,
take
an
action
to
kind
of
piece
all
this
together
and
come
up
with
like
some
proposal
or
not
and
see
see
where
it
goes.
If
that
sounds
ok
to
everyone,
yeah.
B
C
You
know
just
looking
for
some
feedback:
I
put
up
issue
a
link
to
the
beginner,
where
I
kind
of
yeah
laid
out.
What
I
think
is
a
reasonable
approach
to
extend
to
spec
and
to
allow
full
Unicode
support,
I
put
up
as
a
separate
PR
and
the
craft
gorgeous
repo
and
craft
gorgeous
sim
as
Java
and
and
Ruby,
and
probably
others
already
supports
full
Unicode
actually.
C
Exactly
around
surrogate
corpus
and
to
avoid
like
invalid
code
pairs,
which
might
be
an
edge
case,
but
still
so
yeah
I'm
looking
for
feedback
or
for
pinions
about
it.
You
know
how
to
move
forward
because
it's
it's
basically
cleanup.
It's
not
really
like
adding
a
lot
of
new
stuff,
I
guess,
but
the
big
change
inside
the
spec
would
be
like
to
be
expand.
The
range
of
allowed
core
points
to
full
Unicode.
B
C
Know
that
actually
like
for
the
full
Unicode
supported,
covers
everything.
It's
like.
The
extra
change
is
just
adding
just
increasing
the
source
character,
cocoapod
range
to
ten
for
F,
like
that's
the
major
change,
and
then
something
needs
to
be
done
about
escaping
coupons,
also
at
the
BMP
so
yeah,
that's,
basically,
all
of
what
I
want
to
achieve
at
the
moment.
C
C
It's
it's
a
little
bit
like,
like
you,
put
a
previous
PR
sleaze
where
you
kind
of
removed
all
restrictions
in
the
source
character
to
allow
all
court
points
which
which
led
to
some
discussion
road
control
character,
which
is
reasonable.
So
it's
really
like
I.
Think
it's
a
sensible
change
or
I
try
to
make
it
try
to
make
it
sensible
to
kind
of
not
put
any
more
burden
on
anybody,
for
example,
to
deal
with
strange
control
characters.
And
so
it's
a
little
bit
refined
version
of
what
you
put
up
two
years
ago.
B
C
That's
the
thing
right
like
we
already
have
escaped
code
for
for
everything
inside
the
BMP
so
like
the
only
thing
that
is
missing
is
like
escape
code
for
outside
of
it
right
and-
and
this
issue
just
adds
it
by
allowing
surrogate
pair
escapes,
so
it
kind
of
leans
on
Jason
and
allows
that
you
can
specify
a
code
point
outside
of
the
normal
range,
with
two
escape
sequences
directly
after
each
other.
That's
a
solution
for
force.
C
B
C
B
B
C
Definitely
it's
like
it.
It's
it's
like
not
yeah
yeah,
like
I,
guess,
there's
a
reason
why
people
invented
like
the
most
more
convenient
six
digit
escape
cause
to
deal
with
this
and
the
thing
why
I
definitely
edited
it's
like
this
is
how
it
already
works
at
the
moment
inside
Kraft
gorgeous
and,
for
example,
inside
crafter,
Java
and
and
and
if
you
kind
of
take
it
out,
you
kind
of
like
maybe
have
give
us
some
edge
cases.
People
come
up
with
and
I
didn't
see
a
reason
to
prevent
sort
of
good
quiet
place.
B
B
I'd
also
like
to
see
you
turn
this
into
a
spec
PR
as
well,
just
to
kind
of
get
a
better
sense
of
exactly
what
this
looks
like
against
the
spec
as
well.
You
you,
you
mentioned
how
the
source
character
needs
to
change,
and
that
one
seems
you
know
you
just
have
like
a
little
snippet
in
the
issue
itself.
That
seems
super
clear,
I
think
that's
probably
right,
but
just
making
sure
that
all
the
various
other
pieces
throughout
that
might
need
to
change.
I'm.
A
A
Jason
is
dominating
format,
and
it
will
not
change
in
next
I.
Don't
know
how
many
years
so
having
something
which
is
differently
and
you
need
to
use
different
function
to
escape
would
be
worth
I'm.
Mama
Cate
is
support,
incredible
and
fine
addition,
but
I
think
we
need
to
support
surrogate
pairs
just
because
Jason
supports
it.
B
C
Actually,
they
were
supported,
but
not
documented.
Oh
okay.
The
current
implementation
lies
on
the
fact
that
JavaScript,
like
Java,
uses
YouTube
16
internally
to
encode
M
strings
and
you
just
if
you,
if
you
put
two
escaped
codes
next
to
each
other,
it
will
be
automatically
converted
into
a
surrogate
pair
like
so
it's
like.
It
worked
already
perfectly
fine
I
just
added
code
test
for
it.
B
B
B
So
that
makes
sense.
There
is
kind
of
an
open
question
of
whether
we
want
to
support
surrogate
pairs
and
escape
sequences.
Since
that's
something
that
people
will
presumably
be
manually
writing,
I
guess
it
could
be
the
case
that
you
generate
those
from
something
that
spits
them
out.
That
way,
in
which
case
we'd
want
to
be
able
to
consume
them
correctly.
So
I
think
that's
reasonable
cool.
Hopefully
this
gives
you
good
feedback
to
continue
I'm
excited
this
is
this
is
much
cleaner
than
my
years
old
approach.
M
M
Role
is
changing
my
job,
so
that
takes
up
a
lot
of
my
time
moving
into
architecture.
Who
knows
what
that's
gonna
mean,
but
we
added
himself
as
a
champion
for
one
of
the
proposed
solutions
and
I
have
a
PR
up,
adding
myself
as
champion
for
two,
because
I
think
two
of
them
are
good
and
should
happen,
and
so
I
guess
I
wanted
to
just
hop
back
in
the
meetings
get
back
in
the
flow
of
things
and
then
maybe
see
if
anyone
here
might
want
to
be
an
advocate
a
champion
for
any
of
the
proposed
solutions.
N
E
M
Let's
see
yeah
I
think
some
of
them
I
think
we
could
take
this
sign
the
signal
that
there's
no
champions
as
dropping
to
the
bottom
of
the
list,
but
I
would
like
if
anyone
has
ideas
about
where
to
put
out
the
call
for
this
I,
don't
have
a
whole
ton
of
connections
to
make
that
happen.
But
people
here
probably
do
I
mean.
B
M
B
B
Of
course
will
eventually
but
push
this
through,
but
it
definitely
requires
a
bit
of
our
our
dedicated
attention,
some
ideas,
what
we
can
see,
which
of
these
ideas
make
sense.
One
idea
is
that
we
could
have
an
out
of
schedule,
one-off
meeting
just
for
the
champions
alone,
kind
of
like
hash
through
stuff.
Just
so
we
can,
like
you
know,
not
worry
about
having
everybody
who
may
or
may
not
care
about
the
minutiae
of
us
fighting
through
the
details,
and
then
that
way
we
could
kind
of
come
back
with
some
clarity.
B
We
could
do
that
a
sync
to
your
to
your
suggestion
of
like
presenting
something.
Maybe
we
want
to
have
homework
before
we
do
something
like
that
by
like
going
through
and
Vince
you've
done,
the
vast
majority
of
the
heavy
lifting
of
going
through
and
writing
up
criteria
and
evaluating
these
various
cases.
But
ultimately
it
should
really
be
on
the
champion
to
make
sure
that
these
evaluations
are
accurate
against
their
own
feeling
of
how
this
could
shape
out.
So
we'll
have
to
do
a
little
bit
of
a
refinement.
B
Those
are
some
ideas.
I
think
the
job
of
a
champion
is
really
to
hold.
The
null
hypothesis,
like
I,
want
the
champion
to
say
not
like
I'm
gonna
fight
to
the
death
to
get
this
one
done,
but
like
I
want
to
like
I'm
excited
about
this
one.
But
it's
like
on
me
to
set
this
one
down
when
something
else
is
more
exciting
and
that
that
I
think
is
how
we'll
arrive
at
a
clear
decision
that
we're
all
collectively
excited
about
is
when
we
can
kind
of
make
the
clear
case
to
each
other.
Yeah.
H
H
I,
wonder,
and-
and
perhaps
this
could
just
be
added
as
an
agenda
item
to
the
next
meeting,
but
one
thing
that
I
felt
we
can
improve
in
the
working
group
is
the
details
around
our
processes
and
roles
as
you
bring
up
champion
and
we're
not
quite
sure
what
it
means
to
be.
One
I
might
point
to
see
39s
proposal
process
and
how
great
amount
of
detail
they
have
and
in
addition
to
that,
what
it
means
to
be
a
champion
and
what
what
it
takes
to
move
things
from
point
to
point
in
the
process.
B
I
can
make
sure
I'll
update
the
template
to
make
the
link
to
this
close
to
the
top
I.
Don't
see
it
in
the
agenda,
yeah
I
think
you're
right,
it's
not
there.
I
can
certainly
do
that,
because
this
this
document
is
really
the
the
place
where
we've
tried
to
capture
these
things.
One
thing
I
think
that
we
have
learned
is
that
every
proposal
has
been
a
little
bit
different
and
some
proposals
are
there
course,
for
it
is
really
well
defined,
especially
modest
changes.
B
B
But
then
a
handful
of
our
changes
are
much
more
ambiguous
and
complex
and
where
there's
not
even
agreement
on
the
problem
statement,
let
alone
the
solution
space
and
for
those
the
champion
role,
looks
really
different,
and
sometimes
we
need
multiple
champions.
When
there's
multiple
proposals
in
the
ring
yeah.
H
And
that's
true
and
the
thing
I
like
about
the
tc39
process
documents
is
that
it
makes
it
very
clear
that
in
each
step
for
example,
in
this
case,
we
would
need
to
define
the
problem
statement
as
a
first
step
and
so
I.
If
we
had
these
kind
of
steps
that
it
takes
this
to
move
it
along,
then
at
least
that
if
anybody
says
what
does
it
mean
to
be
a
champion,
they
could
look
at
this
and
say,
depending
on
what
the
RFC
is
about
or
what
what
stage
it's
in.
This
is
the
the
responsibilities.
H
B
Be
awesome,
I
will
certainly
add
this
to
the
to
the
template
so
that
it's
it's
easy
to
find
I
think
this
is.
This
is
the
closest
that
we
have
it's
much
smaller
than
what
tc39
writes
out,
but
it's
the
equivalent
I
think
to
what
you're,
suggesting
and
and
I
would
I
would
love
suggestions,
I
think
I've,
mostly
written
the
blind
share
of
this
myself.
B
M
So
as
it
relates
to
the
input
union,
I
do
like
the
suggestion
to
have
a
one-off
meeting
amongst
anyone
who
puts
themselves
down
as
champion
for
a
solution
where
we
can
dive
into
this.
The
nitty-gritty,
which
I
think
will
be
really
great,
because
some
of
these
proposed
solutions
have
a
set
of
variations
and
could
probably
like
learn
from
each
other
in
some
ways
and
inform
each
other
so
I'm
a
I'm.
A
fan
of
that
idea
and.
B
I
think
you're
right
one.
One
small
piece
of
clarification,
though,
is
the
the
role
of
a
champion.
Is
really
the
person
who's
who's
willing
to
do
the
work
on
something?
And
whenever
you
have
two
people
who
are
sharing
the
role
of
champion,
then,
if
they're
communicating
clearly
and
well,
then
then
that
can
work
really
well,
if
they're
not,
then
they
can
kind
of
look
at
that
as
a
way
to
say.
Oh,
the
other
person
is
probably
going
to
do
most
of
the
work
here
and
then
nothing
will
happen.
B
B
Maybe
two
or
three
weeks
from
now,
what
might
be
actually
useful
is
to
do
like
one
week
before
next
month's
meeting.
This
way
we
have
a
fair
amount
of
time
to
work
through
that
I
think
we
should.
There
should
be
some
active
participation
of
this
document,
in
particular
mm-hmm
ahead
of
that
meeting,
and
then
we
can
use
that
so
turn
through
a
bunch
of
stuff.
That
way,
we
can
have
a
then
a
week
to
do
anything
follow-up
before
the
next
of
these
meetings.
Yeah.
M
B
Take
that
offline
Vince,
if
you
don't
mind,
opening
an
issue
to
discuss
setting
up
the
time
for
this
and
that
way,
there's
like
a
place
where
anyone
from
from
this
group
or
anyone
who's
on
today's
call
who's
who
spots
that
wants
to
participate.
They
can
Chris
that
there's
an
opportunity
to
jump
in
I'll.
B
A
Spr
was
like
some
soft
mission
and
graphical
Jess
right
now,
I'm
actually
going
through
it
and
fixing
small
things
like
it's
needed
couple
more
tests,
so
I
I
D,
is
over
always
I
think
it's
most
definitely
more
than
a
year.
The
recently
bond
issue
was
raised
about
should
we
should
be
to
make
deprecated
arguments
required
and
and
the
same
for
input
field.
If
input
field
is
required,
should
we
forbid
to
make
it
keep
recreated
I,
actually
think
it's
so
I.
A
A
A
Everything
else
is
kind
of
ready,
I'm.
Definitely
as
we
discussed
I'm,
not
fun
fighting
scope
of
craft
year
2020
so
with
like
totally
for
moving
it
to
next
release,
but
really
white
too
much
whisper
into
craft
hedges,
so
basically
move
to
stage
two
and
moderate
into
craft
cages.
So
people
start
using
it
and
discover
issues
with
it
discovery.
B
Just
taking
a
quick
look
at
these
PRS
I,
don't
think
they're
in
a
state
where
we
could
consider
them
a
near
final
draft,
so
I
think
stage.
2
is
probably
aggressive
stage.
1
absolutely
makes
sense.
I
think
we
just
need
to
the
graphical
JSP
are
I
was
actually
looking
in
pretty
decent
shape,
like
I
can
go
through
and
add
a
quick
review.
The
spec
PR
is
not
kind
of
a
mess.
Oh
yeah.
A
Yeah,
something
happened,
probably
for
some.
He
he
didn't
do.
I
can
fix.
Okay,
like
a
probably
stage
one
I
can
vary
by
set
correctly
I
think
he
he
did
much.
The
boys
actually
forget
to
check
how
him
I
drew
boys,
yeah,
you're,
right
and
I.
Think
it's
technical
before
what
actually
reviewed
it
and
it
was
in
Nice
shape,
so
I
think
person
just
booked
it
by
doing
metal.
Bracing
correctly
is.
B
A
B
B
Cool
science
is
good,
I,
guess
yeah.
Let's
move
it
to
stage
one
and
Devon
I'll
lean
on
you
to
get
these
in
a
good
working
state.
Once
we
have
that
well,
we
can
quickly
move
to
stage
2
offline
and
I.
You
know
I
trust.
Your
judgement
on
the
reference
implementation
I
think
it's
it's
totally
reasonable
to
to
get
that
and
landed
soon
and
start
collecting
feedback
ahead
of
merging
in
a
spec.
So
you
can.
We
can
get
that
even
in
a
release
before
we
do
stage
3.
A
I
think
it's
that's
all
and
thanks
and
give
big
thanks
for
bringing
this
up
because
I
we
actually
forgot
forgot
about
this.
It's
not
like
it's
one
of
these
pairs
that
nobody
opposed
explicitly
and
everybody
was
happy
about,
but
just
like
nobody
I
took
a
time
to
find
it
or
racemization
so
thankful.
Bringing
this
up.
You
know
us
working
group.
O
Yeah,
so
I
can
start
talking
about
batch
responses.
So
basically
it's
a
problem
that
has
to
be
addressed
that
if
the
server
dumps
a
bunch
of
patches
really
quickly,
that
could
cause
a
client
to
reminder
equally
as
fast
as
they're
coming
in
and
that
would
probably
degrade
performance
more
than
any
games.
You
got
from
using
defer.
O
O
O
The
other
thing
is:
should
we
be
treating
defer
and
stream
as
just
a
hints
that
the
server
could
choose
to
ignore,
so
it
could
for
each
different
response
could
just
decide
that
it
goes
into
either
the
initial
response
or
attached,
thus
coming
for
it,
and
so
I
think
that
we
want
to
like.
We
think
that
server,
bashing
and
treating
different
stream
is
oran
ins.
We
want
to
see
if
there
is
consensus,
if
that
should
be
in
this
back.
B
Just
to
make
sure
I
understand
correctly
sounds
like
there's
a
handful
of
things
you
talked
about
at
once.
Tier
one
is
about
whether
stream
or
deferred
directives
are
rules
versus
hints
should
sure
to
server,
be
able
to
look
at
those
and
say
I'm
going
to
ignore
them.
That
I
think
is
its
own
interesting
conversation.
My
personal
opinion
is
that
it
probably
should
be
able
to
do
that.
The
client
is
just
saying
what
it
cares
about.
Then
the
server
might
say
that
the
fastest
possible
way
to
resolve
this
is
to
do
it
all
at
once.
B
But
the
the
broader
discussion
here,
which
is
super
interesting,
is
what's
the
actual
response
shape
look
like
and
is
it
a
stream?
Can
multiple
pieces
of
that
payload
happen
simultaneously
in
that
stream?
I
do
think
that
there's
a
the
lion
share
of
getting
this
right
relies
on
like
documenting
and
the
abstract
response
spawns
format.
D
D
Yeah
I
guess
my
I'd
be
more
good,
be
interested
in
kind
of
like
I'm,
don't
have
as
much
of
a
client
context.
I'd
be
interested
in
like
what
client-side
implementers
kind
of
what
constraints
they're
under
it.
Actually
me
meaning
material,
a
performance
improvement
to
move
a
debounce
to
the
server,
presumably
there's
like
the
cost
of
responding
to
if
at
least
an
event
base,
not
all
the
cost
of
like
responding
to
messages.
D
B
Yeah
I
can
talk
a
little
bit
about
how
I
saw
this
happen,
with
an
experiment
that
we
did
like
years
ago,
maybe
a
little
bit
longer,
and
this
was
actually.
This
is
a
pretty
real
concern
that
if
your
server
is
naively
streaming
things
and
they're
really
tightly
packed
together,
then
you
can
get
in
a
situation
where,
like
if
the
performance
ends
up
being
dominated
by
react,
rear
Enders,
that's
a
little
bit
of
a
specific
react
issue.
Because
of
how
react
will
can
can
often
a
rerender
can
be
expensive
for
other
kinds
of
clients.
B
It
might
be
less
less
of
an
issue
so,
for
example,
iOS
clients
that
I've
worked
on
before
that
that
use
graph
QL
will
actually
stream
responses
into
their
database
and
then
ield
those
back
out
and
so
there's
more
of
a
observable
style
pattern
in
place
and
the
rear
Enders
are
significantly
less
costly.
I,
don't
know
if
recent
advances
in
how
react
apps
are
being
built
mitigate
some
of
those
original
concerns,
but
it's
certainly
something
worth
we're
thinking
about.
There's
there's
an
interesting
question
here,
which
is
you
know.
B
Certainly,
the
the
server
needs
some
flexibility
in
order
to
deliver
things
in
an
ideal
order,
and
in
doing
so
the
server
needs
to
be
doing
not
just
what's
best
for
it,
but
it
needs
to
have
some
intuition
for
what's
best
for
clients,
even
though
that
can
be
kind
of
broad
I.
Don't
know
if
it
makes
sense
to
say,
like
you
know,
never
give
me
payloads
more
than
an
milliseconds
apart
and
like
the
server
tries
to
do
its
best
to
do
that.
B
For
what
it's
worth,
we
tried
doing
a
debounce
on
the
client
side
for
the
reactor,
II
rendering
problem
and
found
that
the
performance
was
at
best,
the
same
and
usually
worse,
because
it
was
really
hard
to
know
what
the
right
debounce
was
and
the
adding
in
of
latency
basically
meant
that
we
had
to
like
yeah.
We
had
turned
the
CPU
less,
but
the
like
user
experience
was
lowest
common
denominator
in
terms
of
responses.
B
D
So
that's
actually
gets
great,
that's
kind
of
the
context.
I
was
looking
for
there
and
so
I
guess
really.
What
we
have
is
a
bit
of
a
challenge
here,
like
we've
got
a
kind
of
a
server,
has
some
context,
the
value
and
having
a
server
deliver
batches.
Presumably
it's
that
I
mean
the
server
may
actually
have
certain
chunks
of
work
which
are
sort
of
generated
together
or
who
knows
maybe
even
be
cached,
and
so
the
server
has
some
context.
D
D
B
Good
yeah
I
know
that
a
lot
of
databases
do
have
streaming
API.
Is
that
work
in
the
way
that
this
like
option
three
is,
is
describing
the
best
responses?
Actually,
this
I
remembered
Facebook's
codebase,
putting
an
abstraction
place
that
have
like
a
chunk
stream,
or
something
like
that.
That
sounds
very
very
similar
to
what
this
is
doing.
B
So
it
sounds
like
there
could
be
a
very,
very
close
one-to-one
mapping
between
how
a
lot
of
back-end
API
is
are
starting
to
develop
their
streaming
api's
with
what
we
want
to
do
here,
which
could
be
great
like
the
this.
The
case
I'm
thinking
of
is
kind
of
even
beyond
debounce,
like
if
you
used
a
stream
and
on
a
list
of
things
that
had
a
hundred
items
in
it
and
the
server
started,
giving
them
back
to
you
ten
at
a
time.
B
D
So
that's
quite
convincing
to
me
that
we
want
some
sort
of
match
format
to
be
standardized.
I
guess.
Actually
it's
I
guess
address
is
my
only
remaining
question,
which
was:
can
we
like
stage
this?
In
other
words,
can
we
standardize
a
subset
of
this
without
the
bachelor-man
and
the
batch
for
manator
from
a
perspective
of
simplifying
the
I?
D
Don't
know
if
that's
a
simplification,
and
it
would
be
all
in
in
an
in
a
form
in
which
you
can
do
batching
if
we
don't
think
dramatically,
simplifies
the
spec
or
or
make
it
easier
to
move
the
proposal.
Fair
work,
I
would
probably
an
advocate
for
actually
just
interesting.
The
burner
and
at
contacts
me
that
we
don't
have
a
bachelor
mat
currently
inside
of
Facebook
she's
on
the
line
can
probably
speak,
doesn't
think
this
has
been
a
significant
problem
for
us.
I
think
we
have
dealt
with
some
rerender
issues.
You.
K
We
only
experimented
the
batching
format
just
for
the
stream
and
leverage
exactly
what
Lee
said
about
chunked
adorable,
which
is
the
database
back-end.
So
we
haven't
had
like
a
global
debouncing
on
the
server
side,
which
takes
into
account
off
all
the
different
directives
and
all
the
stream.
It
is
just
for
the
streaming
and
it
is
like
purely
leveraging.
The
database
streaming
API.
D
K
D
D
B
Don't
think
we
should
fast
follow
it.
I
do
think
it's
important,
especially
with
the
changes
big
as
this
one,
that
it
comes
out
of
the
gates
with
all
the
tools
you
need
to
to
build
a
reasonably
performant,
server
and
client.
That
kind
of
like
use
the
abstract
tools
described
in
the
spec.
We
had
to
do
something
similar
for
subscriptions,
although
subscriptions
does
not
have
this
kind
of
batch
format.
This
kind
of
opens
a
question
of
maybe
it
should
I
think
I
mentioned
one
of
the
last
times
we
discussed
this
that
we
should.
B
We
should
investigate
whether
we
can
reuse
the
stream
abstractions
that
we
put
into
place
for
for,
for
subscriptions
and
and
just
see,
maybe
there's
like
small
changes
we
have
to
make
to
it
for
it
to
be
useful
in
the
context
of
deference
stream.
Now
that
would
be
ideal,
because
it's
just
like
fewer
things
we
have
to
talk
about,
and
it
might
help
us
start
to
see.
The
similarities
between
these
batch
might
be
a
case
that
ends
up
actually
being
useful
in
both
contexts.
But
it's
just
like
more
immediately
useful
here.
E
Forgive
me
if
this
is
somehow
I've
taught
it
because
I
mean
I'm.
The
fact
that
I
haven't
heard
this
discuss
makes
me
think
that
maybe
I
misunderstand
the
problem,
but
as
server-side
debouncing
like
not
generally,
the
solution
to
this
I'm,
not
so
I'm
here
is
that
the
use
of
batch
payloads
here,
because
in
most
of
the
cases
that
we've
seen
in
practice,
it's
been
very
much
kind
of
a
last
day,
twins
situation,
and
so
the
server
can
be
bounced
and
just
discard
the
old
responses,
and
you
don't
actually
need
a
separate
custom
patch
payload.
E
D
B
Yeah
and
subscriptions
I
mean
subscriptions,
are
designed
for
real-time
data,
whereas
difference
stream
is
not
right
so,
which
is
why
the
the
batch
is
less
relevant
in
that
circumstance
like
the
scenario
in
which
multiple
events
would
happen
simultaneously,
such
that
the
batch
is
appropriate.
This
is
weird
from
like
a
real-time
event
processor,
but
in
the
case
of
stream
you
might
actually
like
all
the
data.
Is
there
it's
just
a
matter
of
getting
access
to
it
and,
like
the
simplest
possible
version,
is
like
okay,
you
asked
for
10
things.
B
I'll
give
you
one
at
a
time,
but
databases
might
be
more
sophisticated
and
say
you
know.
I
can
actually
give
you
a
megabyte
at
a
time,
and
so
that
happens
to
be
three
things.
So
here's
three
here's
three
more
used
to
be
more
and
here's
the
last
one,
and
if
we're
gonna
do
that
from
the
database,
then
it
makes
sense
that
we
should
follow
that
through
to
the
client.
B
If
we
can,
if
we
can
process
multiple
things
in
a
chunk
and
then
it's
less,
the
last
thing
wins
and
more
that
you
have
multiple
pieces
of
data.
You
have
to
kind
of
describe
to
the
client,
then,
which
is
I,
think
another
piece
of
the
puzzle
that
we've
yet
to
kind
of
nail
down
for
different
stream,
which
is
like
now
that
you
have
these
streamed
pieces.
How
do
you
reassemble
them
into
a
whole.
D
D
B
B
But
there
was
like
a
lot
of
like
strong
side
that
three
was
the
right
number
for
the
first
size,
regardless
of
what
the
server-side
could
do,
that
one
was
like
pretty
tightly
defined,
specifically
for
newsfeed,
like
obviously
other
things
are
not
gonna.
Follow
that
rule,
but
I
think
my
first
prototype
for
stream
actually
had
an
argument
to
the
stream
directive.
Where
you
could
specify
some
hints
for
the
page
sizes
that
you
wanted
so
that
I
think
there
was
some
precedent
in
that
old
experiment
to
do
something
like
that.
Yeah.
D
Yeah
actually
you're
refreshing,
my
recollection
that
we
we
have
done
something
like
that,
so
it
barely.
This
is
an
idea.
I
came
up
with
all
the
way,
though
I
you
refresh
my
recollection
like
today,
because
we-
and
this
is
maybe
worth
chatting
about-
we
don't
have.
D
Out
of
the
rack,
do
all
three
we
can
make
modification
home,
and
so
that's
one
thing
that
we've
explored,
doing,
which
I
think
might
be
difficult
in
a
directive
like
we
find
like.
Oh,
it's
about
2/3
in
the
new
batch
or
two
new
batch
or
five
or
something
like
that,
and
that
can
be
you
know.
Having
that
expressed
in
a
directive
might
be
a
little
awkward
but
I
think
the
larger
point
here
is
actually
on.
How
do
we
enable
aspects
of
data
delivery,
incremental
delivery?
D
K
Yeah,
definitely,
and
and
just
to
add
some
like
more
context
there,
like
a
lot
of
the
times
like
you,
cannot
find
a
static
value
that
is
always
correct
at
every
single
time.
Right,
like
the
number
might
be.
If
it's
like
around
peak
time,
when
everyone
is
using
Facebook,
you
might
just
want
to
deliver
something.
You
know
minimum
amount
of
stories
to
everyone
so
that
everyone's
phone
is
rendering
but
doing
like
non
peak
time.
D
Summarize
I
think
what
this
speaks
to
is
actually
before
we
add
things
to
the
directives,
it's
probably
worthwhile,
considering
whatever
we
can
find
ways
to
give
this
a
birth
will
actually
we've
had
some
pretty
big
wins
there.
If
we
can
find
ways
of
simply
associating
directives
with
label
or
another
approach,
we've
used
is
actually
we've
rewritten
certain
graph
QL
parameters
on
the
server
prior
to
which,
which
is
actually
a
little,
perhaps
a
little
bit
more
dangerous
in
the
sense
of
taking
potential
control
away
from
with
client
in
the
past.
D
For
actual
you
know,
client
is
expected
to
control
these
things,
but
what
we
found
the
I
would
say
the
headline
here
is
the
world.
There's
tremendous
benefits
and
having
the
client
specify
what
data
it.
Actually,
we
found
that
there's
benefits
in
having
the
server
control,
how
that
data
is
delivered,
and
so
that's
the
distinction
that
we've
discovered
and
so
rather
than
adding
parameters
to
stream
and
defer
wherever
possible,
we
would,
you
know,
want
to
see
if
that
could
be
replaced
by
server-side
configuration,
so
it.
B
Just
like
the
client
says:
I
want
it
this
way
and
the
server
says:
okay,
you
know
best
I'll.
Do
it
your
way,
supporting
both
leads
to
a
hint
based
model
which
I
think
could
be
reasonable?
The
other
thing
that
maybe
you
can
just
kind
of
clarify
draw
for
what
you
meant
by
this
is
something
like
a
label.
Do
you
mean
that
when
you
say
I
would
like
to
stream
this?
B
That
you
want
to
be
able
to
say,
I
would
like
to
stream
this
with
the
server
side,
known
rules
for
how
newsfeed
gets
streams
and
like
have
some
label
that
says
this
is
a
news
feed.
Can
you
get
that
from
the
field
name
itself,
or
is
that
something
that
you'd
want
to
like
explicitly
state
in
the
in
the
query.
D
The
advantage
of
that
approach
is
that
it's
somewhat
safe
in
the
way
that
the
approach
we
have
taken
is
not,
which
is,
we
have
actually
sort
of
use
directives
to
move
certain
parameters,
configure
essentially
similar
models,
sort
of
saying
to
the
server
a
server
by
the
way
feel
free
to
override
this
parameter.
If
you
feel
like
you
can
make
a
better
guess
at
this,
so
this
applies
not
just
to
weather
stream
and
defer
is
enable,
but
also
what
the
page
size
might
be.
D
For
example,
it's
an
interesting
approach
to
consider
the
Woodhouse
sort
of
difference
here
and
sort
of
use
directives.
If
you
think
of
directive
is
controlling
how
data
is
delivered
rather
than
what
today.
That
separation,
however,
is
not
so
clean,
and
so
the
danger
of
this
approach
is
that
the
server
starts
overriding
Korea
Korea
parameters
that
actually
change
what
data
is
returned,
which
would
be
very
bad
and
invalidate
important
invariants,
that
we
expect
clients
and
servers,
and
so
we've
chosen
the
query,
string,
parameter
approach,
but
I
don't
know
I'm,
not
really
confident.
D
That
is
the
right
one.
When
movin
of
standardization
phase
we're
kind
of
it's
important
to
consider,
we
can
do
a
lot
more
in
configuration
because
we
have
a
closed
world
as
a
set
of
applications
which
we
support.
So
we
can
say
hey.
These
are
the
seven
or
more
likely
mobile
device
configurations
in
the
extreme,
whereas
if
you
were
github
and
you
were
published
unknown
clients
that
might
mean
that
might
in
those
cases
you
might
want
to
have
a
more
explicit
API
or
specifying
this
information.
D
D
I
mean
when
you
have
a
limited
set
of
apps
to
support
I.
Think
it's
practical
when
we
get
into
you
know.
Github
would
be
a
great
example
here.
Public
API
is
it
made.
You
know
just
may
not
work,
we
get
the
configurability,
we
need
where
we
don't
know
anything
about
the
plan.
They're.
Truly
a
stranger.
K
So,
just
to
offer
some
of
my
understanding
to
what
you
just
said,
Jaffer's,
it
seems
to
me
that
we
would
read
on
like
the
direction
to
go,
is
to
treat
the
defer
and
stream
as
a
hint
rather
than
this
is
the
imperative
thing
that
you
need
to
do.
However,
the
way
that
we,
how
do
we
achieve
to
make
them
a
hint
one,
is
directly
through
the
the
directives
themselves?
Ie
you
just
make
defer
the
deferral
or
you
make
the
stream
the
streamable
and
the
other
way
is
to
actually
say
hey.
K
Let's,
maybe
we
can
use
a
combination
of
the
defer
and
stream
along
with
a
parameter,
and
this
parameter
itself
is
configurable
on
the
server
side.
So,
like
maybe
you
know
the
defer
that
you
would
have
a
label
argument
and
you
would
have
an
if
argument
and
then,
if
argument
is
associated
with
a
variable
on
the
query
side,
that
is,
you
know
somehow
annotated,
as
this
is
something
that
server
can
chew,
based
on
all
of
them.
The
model
like
sophisticated
models
that
I
have
as
another
way
of
achieving.
K
D
Thank
you,
that's
much
more
cogent
than
I
put
away.
Yes,
in
other
words,
we
in
addition
to
getting
the
hint
about
whether
the
client
can
support
stream
in
deferred
we,
it
may
actually
go
a
long
way
to
all
two
also-
and
this
I
think
is
orthogonal
but
related,
give
a
hint
to
the
server
about
which
parameters
could
be
overridden.
That's
kind
of
a
more
general
mechanism
for
giving
the
server
more
control.
P
D
Sorry
yeah
just
very
briefly
imagine
we
just
had
a
defer
and
stream,
and
then
we
have
a
parameter
essentially
saying
whether
it's
enabled
so
defer
would
have
enabled
:.
True
stream
would
have
enabled
cool
and
true
and
then
you
can
actually
specify
a
parameter
to
the
query
and
then
use
that
to
turn
that
on
or
off
on
the
client,
the
intention
is
not
so
like
that
might
seem
a
little
silly.
You
could
just
not
include
the
directive
so
on
its
own
I.
Think
it's
it's
not
really
useful.
D
I
think
when
paired
with
the
idea
of
having
like
say
declaring
limit
very
variable,
okay
by
the
way
server
you
can
actually
choose
to
override
this
value.
Then
it's
actually
potentially
useful,
because
once
something's
been
deployed
on
the
server
side,
you
can
then
go
and
say:
actually
you
know
defer,
doesn't
actually
improve
our
TTI
measurably
and
it
uses
up
a
lot
of
CPU.
D
So
we're
just
gonna
build
a
configuration
on
the
server
side
and
then
choose
run
an
experiment,
for
example,
with
three
different
values
of
turning
on
or
off
to
four
different
combinations
of
turning
off
on
or
off
defer
and
the
same
for
a
for
example,
and
so
I.
Think
fundamentally.
This
is
this
is
an
interesting
but
fundamental,
but
orthogonal
question
like
stream
and
defer,
which
is
like
hey
what.
How
do
we
hand
over
more
control
to
the
server
and
what
level
of
control
can
we
hand
over
to
the
server
stately?
O
Yeah,
sorry,
guy
I
think
we
found
that
both
having
a
argument
on
deferred
where
we
you
do
control
it
in
the
same
query
was
useful
where
the
client
threat
for
us,
the
client
wants
to
reuse
the
same
query
for
like
a
server
render
page
and
also
like
a
client
side
navigation
and
then
on
the
server.
We
don't
want
to
defer
these
fields,
but
on
the
client
we
do
so
be
with
us.
The
variable
to
control
that
so
I
think
that's
definitely
useful.
O
D
Circling
so
then,
to
sum
up
long
story
short,
it
seems
like
we
should
add
you
know
whatever
ABI
is,
we
think
they're
necessary
to
defer
and
stream
and
not
try
and
oversimplify
them
and
rely
too
much
on
the
server-side
configuration,
because
we
always
have
some
generic
mechanism
for
overriding
this
on
the
server
I
variable
rewriting
I'm,
not
sure
we
want
to
sanction
that
approach.
We
just
know
that
that
approach
works.
That's
something
we've
done
at
Facebook,
so
you
know.
We
know
that
options
and.
K
O
D
This
is
like
orthogonal
to
the
proposal.
Fundamentally
I
bring
that
mostly
just
so
we're.
You
know.
We
were
confident
we're
kind
of
future
proof
for
this
and
you
in
the
future.
This
works
Facebook,
so
I
feel
pretty
confident
about
it.
So
I
think
we
can
consider
it
separate
from
the
proposal
of
the
streaming
de
fer
proposal
and
any
parameters
that
might
make
sense
to
specify
from
the
client
we
should
just
include
and
streaming
defer,
if
certainly
seems
to
fit
the
bill
based
on
your
user.
B
So
I'll
do
my
best
to
sum
up
here.
It
sounds
like
first
of
all
stream
and
defer
likely
need
some
arguments,
the
number
of
which
is
kind
of
yet
to
be
determined,
but
we've
identified
a
handful
of
use
cases
for
places
where
the
client
needs
to
provide
it
as
some
additional
information,
notably
if
which
just
like
toggles
that
thing
on
and
off,
but
maybe
also
an
opaque
label
if
the
server
is
gonna
provide.
B
Some
specific
functionality
may
be
also
a
chunk
size
if
the
server
wants
to
or
if
the
client
wants
to
have
some
control
over
that
I
think
that's
all
in
play.
We
can
kind
of
work
through
what
elements
of
those
we
want
or
don't
want
in
the
final
version,
but
we
should
kind
of
be
having
them
out
in
the
open,
so
we
can
figure
it
out.
Another
is
on
this,
like
batching
model,
pretty
clear
that
that's
going
to
be
important,
I
think
every
any
reasonably
performant
implementation.
Experimental
implementation
of
these
in
the
past
has
had
that.
B
B
Which
is
it's
it's
like
a
weird
member
of
the
family
of
like
iterators
and
async
iterators,
and,
like
my
I
remember
the
first
time
I
encountered
it.
I
was
like
whoa
I've,
never
seen
one
of
those
before
and
that's
very
clever.
It
sounds
closest
to
what
we're
talking
about
here.
Maybe
if
you
could
like
find
some
way
to
talk
about
that
outside
the
context
of
just
hack
in
particular,
that
could
be
really
helpful
for
folks
to
wrap
their
head
around
exactly
what
that
thing
is.
B
B
Nope
single
payload,
like
I,
completely
ignored
that
or
it
might
be
more
fine-tuned,
like
you
asked
for
three
things
in
the
first
batch
and
I
gave
you
four
but
well
we'll
have
to
set
up
some
rules
there,
but
totally
yeah,
yeah
I
think
letting
this
like
careful
dance
between
the
clients,
saying
here's
what
I
want
and
the
server
saying
I
know
better
than
you.
Here's.
What
you
get
is
is
a
careful
one
to
walk,
but
we'll
have
to
come
up
with
a
good
answer
for
that.
K
It
seems
like
that
the
principle
here
is
we
would
want
to
introduce
like
all
these
variables,
but
in
the
specification
we're
not
gonna
specify
what
those
like
arguments
are.
Gonna
guarantee
you.
It
is
just
like
in
the
principle
of
we
think
this
is
going
to
be
helpful
for
any
kind
of
servers
out
there.
We're
gonna
implement
this.
D
Correct
me,
if
I'm
wrong,
Lee
I,
think
you
were
actually
saying
that,
rather
than
a
necessarily
a
blanket
sort
of
decision,
oh
servers,
always
in
control
or
clients,
always
in
control,
you
thought
that
we
might
actually
want
to
look
at
that
on
a
per
variable
basis.
The
one
example
I
can
think
of
was
the
motivating
example
previously,
which
is,
if
you're
doing
a
stateless
render
for
doing
a
single
step
render
and
you're
trying
to
disable
stream
there.
D
B
Enos
might
not
be
okay
like
if
you
have
not
put
at
stream
on
a
connection
and
then
all
of
a
sudden,
this
two
server
decides
I'm,
gonna
stream,
that
to
you,
like,
you
might
be
in
a
position
where
the
clients
not
ready
to
handle
that.
So
that
would
be
a
case
where,
like
you
didn't
even
say
to
do
it
and
the
server
decided
to
like
put
something
in
place,
because
it
has
control
you're
right
that,
like
in
those
situations,
you
could
end
up
in
a
really
bad
position.
B
So
what
will
have
to
be
thoughtful
and
how
we
write
those
rules?
And
hopefully
we
can
do
it
in
a
way.
That's
not
super
confusing
I.
Think
like
saying
here's
how
this
thing
works,
except
when
it
doesn't
because
the
server
overrides
you
can
be
like
a
really
frustrating
thing
to
write
down
in
aspect
so
I.
Imagine
that
will
need
to
spend
a
lot
of
attention
on
like
bouncing
between
powerful
and
simple
and
getting
this
right,
which
I
know
can
be
tough.
D
That's
good,
so
that's
like
its
action
items
for
us
to
take
away
and
sort
of
maybe
put
together
kind
of
a
matrix,
try
and
establish
a
guiding
principle
that
a
high-level
it
would
actually
be
give
blank
control,
actually
the
server
ship
owner
whatever
the
client
specifies.
This
is
just
off
the
top
of
my
head.
It
should
honor,
whatever
his
blinds,
specifies,
with
the
exception
of
backward
compatibility,
where
like,
for
example,
a
server,
doesn't
support
stream
or
defer.
D
This
is
my
straw,
man,
and
then
we
could
introduce
a
generic
mechanism,
nothing
like
what
we
talked
about,
which
is
explicitly
marking
for
each
parameter,
override
of
all
by
the
server
and
then
essentially
sidestep
this
question
and
provide
a
generic
mechanism
for
server
overrides
that
would
apply
to
page
size,
etc.
I
think.
C
D
K
K
B
A
first
step
is
taking
the
that
chunked
iterable
and
like
extracting
it
from
the
world
of
hack
and
like
describing
it
in
the
abstract.
I
think
that'll
be
a
good
first
step
and
we'll
start
to
see
how
much
of
that
thing
is
relevant
and
we
need
to
keep
and
how
much
of
it
is
in
the
weeds
details
that
we
can
kind
of
directly.
D
Yeah
I'm,
actually
I
just
want
to
cut
up
that
may
actually
be
over
generalizing.
In
this
particular
case,
I
think
what
Way
was
alluding
to
was
like,
rather
than
sort
of
trying
to
talk
about
a
chunk
iterator
which
might
be
useful
for
future
concepts,
but
because
we
don't
have
this
concept
in
subscriptions
today,
I've
like
a
batch
of
subscriptions
for
the
reason
we
called
that
earlier.
It
may
just
mean
another
payload
format.
D
B
B
It
can
describe
more
things
so
really
like
what
we're
trying
to
match
is
consider
what
an
implementation
would
look
like
in
you
know:
n
plus
1
languages
and
then
what's
common
amongst
them
and
as
you
start
to
like,
that
is
what
the
spec
should
be,
and
it
needs
to
be
detailed
enough
that
it
covers
the
things
that
you
want
to
guarantee
but
general
enough,
that
it
doesn't
restrict
those
clients
from
doing
the
thing
that
they
need
to
do
so
Jafar.
You
might
be
right
that
maybe
this
chunked
detail
is
is
actually
an
implementation
detail.
B
Maybe
these
are
just
straight
up
streams
and,
like
there's
an
implementation
detail
that,
like
sometimes
you
get
a
lot
of
these
stream
events
all
at
the
same
time
and
then,
like
clients,
are
totally
happy
to.
You
know
a
single
render
in
that.
In
that
scenario,
we
I
that's
like
an
area
that
we'll
have
to
kind
of
fiddle
with
it
and
see
what
makes
the
most
sense,
because
we
ride
that
line
between
not
giving
enough
guidance
to
clients
to
understand
how
to
interpret
the
results
and
giving
too
much
to
the
point
where
we're
restricting
them.
B
There
is
a
CREP
like
at
some
point.
We
do
also
have
to
make
recommendations
on
how
this
stuff
she
realizes.
We
do
that
in
aspect.
We,
you
know,
we
say
like
hey,
you
don't
have
to
use
JSON,
but
if
you
do
like
here's,
the
serialization
you
rules
you
should
follow,
will
will
probably
want
to
do
something
similar
and
so
like.
If
we
want
these
to
look
like
multiple
payloads
that
happen
really
fast
when,
after
another
that
implies
client-side
to
bouncing.
B
If
we
want
these
to
look
like
payloads
of
arrays
of
events,
then
that
implies
no
client
to
bouncing,
and
so
there's
the
rub.
I
think
like
that's,
where
we'll
have
to
figure
out
exactly
how
detailed
that
we
need
to
be
in
order
to
make
sure
clients
can
make
sound
decisions,
because
it
would
be
really
a
bummer
if,
like
different
servers,
took
different
approaches
to
that
particular
question.
Then
clients
would
not
have
the
information
that
they
needed
that
guarantees
that
they
needed
to
like
write.
A
single
network
protocol.
D
Yeah
I
think
in
this
case
I
just
was
probably
prematurely
optimizing.
I
was
thinking
instead
of
like
a
full
payload
and
an
individual
W.
We
needed
like
a
third
but
actually
I,
think
maybe
the
chunk
chunk.
Iterator
is
actually
the
right
model
here.
It
is
more
flexible.
You
can
just
say,
hey
an
array,
then
I,
probably
prematurely
optimizing,
miss
thinking
of
some
third
way
we
didn't
have
to
like
have
all
the
arrays
of
paths
so
yeah,
let's
start
with
the
simple
I
think
that's
the
rate
of
the
rate
from
well.
D
D
K
A
Jaffer
I,
don't
know
if
you
were
in
the
earlier
chunk
of
the
meeting,
I
think
at
one
point:
Lee
was
that
was
recommending
for
another
topic
that
we
would
have
a
work
group
specific
one
like
one
week
prior
to
the
mostly
scheduled
I.
Think
your
topic
of
lazy
versus
async
would
be
a
good
candidate,
for
you
know
a
separate
like
topic
specific
work
group.
Should
we
also
like
aim
at
schedule
that,
before,
like
next
month,
yeah.
D
Sounds
sounds
good
to
me
and
just
for
brief
context
for
folks
async,
both
async
and
defer,
or
essentially
like
asynchronous,
but
they
have
to
be
delivered
and
there's
a
there's
another
auction
now,
which
is
like
we
could
wait
for
a
client
signal
before
delivering
them
and
that's
primarily
beneficial
for
situations
where
you're
like
optimistically
pre
loading
for
like
the
next
view,
for
example,
because
at
peak
time
you
can
decide
to
not
eagerly
deliver
the
data
and
wait
for
laziness.
That's
the
short
answer,
so
anybody
who's
interested
in
chatting
about
that.
D
There's
a
issue
that'll
actually
link
into
the
chat
that
I
open,
didn't
get
much
traction
on
so
I'm,
not
sure
how
interested
how
interested
folks
are?
It's
really
more
about
future
proofing,
async
and
defer
and
being
confident
that
we
can
actually
move
forward
without
worrying
about
laziness,
and
we
can
add
it
on
later
on
in
a
composable
way.
So
I'll
post
that
issue
in
a
group
anyone
who's
interested.
We
can
have
a
breakout
session
to
discuss
them.