►
From YouTube: GraphQL Working Group - February 6, 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
Okay,
let's
review
our
agenda,
we're
going
to
go
over
last
meetings,
action
items
and
actually
we
might
skip
that
this
this
session,
because
I
think
all
of
them
align
tightly
to
what
we're
talking
about.
I'm
gonna
give
an
update
on
where
we
are
on
freezing
the
spec
and
the
release
schedule
for,
for
this
upcoming
release.
A
A
Okay,
let's
dive
in
I
have
the
first
two
agenda
items.
First,
usually
we
review
the
previous
meetings.
Action
items
actually
took
a
moment
to
do
that
before
the
meeting
started
and
realize
that
every
single
action
item
lined
up
with
one
of
the
things
on
the
agenda
today,
so
sort
of
in
the
spirit
of
staying
focused
and
keeping
on
time.
I'm
gonna
skip
over
that
step
and
let
us
sort
of
just
focus
on
the
agenda
of
the
day
in
terms
of
the
spec
freeze
and
the
release
schedule.
A
I'm
gonna
propose
that
the
end
of
today
is
the
freeze
for
the
spec
which,
if,
if
everyone's
cool
with
that
means,
the
release
schedule
is
gonna.
Look
like
the
following
over
the
remainder
of
this
month,
I
at
least
personally
and
I
hope
anybody
else
here,
who's
who's
interested
in
doing
so
should
comb
through
the
spec
and
look
for
any
irregularities,
any
any
issues,
bug
spelling
mistakes.
Anything
like
that
I
think.
There's
already
been
a
handful
of
things
like
that
caught
in
the
last
couple
of
weeks,
which
is
awesome.
A
Meanwhile,
Brian
our
our
program
manager
is
going
to
be
making
sure
that
everyone
who's
contributed
over
the
last
year
and
a
half
has
up-to-date
legal
documents
so
that
we
can
make
sure
that
what
we're
offering
is
bulletproof
and
actually
backed
by
all
the
legal
guarantees
that
we've
been
promising
with
the
foundation
and
then
I'll.
Be
writing
up
sort
of
elongated
release.
Notes
uh-huh,
that
are
that
go
not
just
to
all
the
various
RFC's
that
have
landed
but
sort
of
paint.
A
C
Question
yeah:
it's
a
possible
that
we
have
something
like
tech
to
take
all
the
things
that
went
into
the
graphic
world
space
or,
if
not,
if
we
can't
do
that
for
all
the
merch
stuff
now
it
would
be
cool
if
we
had
like
a
milestone
or
something
for
the
next,
because
it's
I
mean
I'm
also
reading
through
the
spec
like
multiple
times
a
month,
but
it
would
be
far
easier
to
get
an
overview.
What
really
changed.
A
That's
a
really
good
suggestion.
It's
making
me
think
that
we
probably
want
to
frame
up
the
the
release
notes
in
a
couple
different
forms,
so
I
was
thinking
first
to
just
have
like
a
bulleted
list
of
literally
everything.
That's
changed.
Basically,
the
human
readable
version
of
the
commit
log,
in
addition
to
sort
of
like
a
high-level
explainer
but
I
like
your
idea
of
using
a
tag,
I
think,
especially
since
the
vast
majority
of
commits
that
landed
came
from
PRS.
That
spent
a
long
time
which
went
through
the
full
RFC
process.
A
You
can
just
tag
all
those
graphical
2020s
they
landed.
We
can
I'm
open
to
suggestions
about
how
we
wanted
to
do
that
for
next
year's
spec
release.
If
we
want
to
do
a
milestone,
I
think
I
think
that
could
be
a
pretty
reasonable
way
to
do
that.
I
think
the
tricky
part
is
that
we
don't
always
know
which
RFC's
are
gonna
land
in
a
particular
release.
Some
of
these
RFC's
that
landed
in
this
year's
release
were
had
been
worked
on
for
two
or
three
years
so
they're.
B
On
this
note,
like
last
time,
we
release
a
spec
early.
You
asked
like
people
to
write
articles
about
that
and
promise
to
reference
them
in
the
business,
but
when
you
actually
did
that,
so,
maybe
as
if
somebody
actually
work
want
to
work
on
this
article,
you
can
start
now
during
after
future,
freeze
because
nothing
new
is
aging
and
I
think
it
would
be
great
to
whatever
ends
article
and
this
time,
we'll
have
more
time
to
work
on
article.
If
somebody
wants
content
for
the
book.
A
That's
a
great
suggestion,
I
think,
especially
if
you
worked
on
something
that
was
merged
into
this
release.
One
of
the
major
RFC's
there's
there's
a
lot
of
ripe
ground
there
to
talk
about
not
just
the
change
and
how
it's
important
but
kind
of
the
process
that
you
went
through.
The
if
I
makes
a
good
point.
I
think
part
I
didn't
mention,
but
an
important
part
is
a
press
plan.
A
So
I'm
my
hope,
is
to
have
all
this
stuff
sort
of
developed
in
the
open,
so
probably
in
the
graphical
spec
repo,
we'll
just
track
all
the
stuff.
In
the
context
of
an
issue.
A
lot
of
stuff
ends
up
being
developed
through
Google
Docs,
just
because
it's
easier
to
collaborate
with
less
technical
folks
working
on
press,
but
we'll
have
a
full
press
plan
of
like
all
the
various
things
that
we're
gonna
release
and
I'll
incorporate
anybody
who
wants
to
be
part
of
that
process.
More
than
happy
to
include
you.
A
D
D
A
Good
question
I
think
disloyal
non-breaking
change
is
in
approved,
State
or
accepted
State
I'm
gonna
merge
that
one
today,
after
I
kind
of
rude
you
a
final
time
that
one's
based
on
the
fact
that
the
reference
implementations
basically
been
ready
for
months,
if
not
close
to
here.
Actually
the
and
the
last
round
of
feedback
that
one
got
was
a
year
ago,
I
think
cause
some
scalars,
considering
that
it's
on
our
agenda
today
is
not
quite
ready
yet,
which
is
fine.
I
mean
like
the
this
spec
is
really
just
like
a
moment
to
kind
of
snapshot.
A
What
we
have
in
time
missing
that
cut
is
not
a
big
deal
right.
It
just
means
that
it's,
like
all
reference
implementations,
all
of
the
implementations,
track
the
draft
boards.
So
then
they
track
a
specific
edition
of
the
spec,
so
I
think
the
the
custom
scalar
since
we're
still
working
on
it
and
it's
not
released
as
part
of
the
spec
and
there's
still
some
open
questions
will
not
make
the
cut
but
disallow
breaking
change.
Will
anybody
have
strong
feelings
about
this
or
objections.
B
A
No
Jess
could
should
keep
on
truckin.
Basically
what
this
the
freeze
means
from
a
tactical
point
of
view,
is
pull
requests
to
the
graphical
spec
repo
outside
of
the
RFC
folder
are
not
going
to
be
merged
for
a
couple
of
weeks.
We
could
do
something
with
branches,
but
there's
just
a
lot
of
work.
It's
just
much
easier.
E
So
it's
kind
of
just
on
hold
because
of
that
the
only
open
and
the
code
isn't
stable.
That
has
many
changes
there.
The
only
question
I
had
was
all
like
what
we
talked
about
at
the
end
of
last
month's
meeting.
My
incorrectly
said
something
about
how,
if
these
festive
thought
added
to
specified
directives
once
that
that
was
like
allowed
and
it's
not
allowed,
because
you
know
you
should
only
be
able
to
I-
was
supposed
to
a
directive
there
once.
E
But
if
you
extend
it
multiple
times,
then
it
is
present
multiple
times
in
the
10th
extension
that,
and
so
my
implementation
is
just
taking
the
last
entry
there,
which
I
think
is
the
right
thing
to
do,
but
wasn't
exactly
sure
and
how
the
syntax,
like
other
directives,
that
may
expect
to
only
be
there
once.
But
it's
if
you
use
extensions
multiple
times:
it's
there
multiple
times.
So
that's
the
only
the
question
which
maybe
can
be
handled
offline
and
natural
flow
requests,
but
other
than
that
things
are
stable.
B
B
You
had
a
test
for
it,
so
it's
like
actually
validate.
Remember
you
work
at
that
specific
test
for
his
deal.
We
can
figure
out
its
but
pretty
sure
and
actually
I
said
why
it's
redundant,
because
I
should
not
test
every
directive
that
this
will
be
duplicating
because
he
or
we
cannot
do
for
xscape
include
and
duplicated.
Second
was
so.
B
B
B
Probably
need
to
check
one
thing
if
you
create
schema
programmatically
and
when
you
extend
it
with
this
deal,
it's
because,
like
you,
you
don't
use
directive.
Second
time,
you're
kind
of
way,
once
you
specify
URL
programmatically,
one
frou-frou
is
deal
so
maybe
we
need
to
handle
this
case,
but
I
think
it's
like
implementation
meters,
so
spec
is
pretty
sure
location.
E
B
One
thing
quick
because,
like
it's
stage,
two
and
the
way
is
booked,
mainly
because
I
tried
to
minimize
the
scope
for
for
1500
released
to
our
and
resource
pack
release.
So
technically,
it's
like
possible
too
much
work
right
now,
so
I
encourage
everybody
to
actually
like
a
check,
speak
PR
and
whisper
because
we
change
the
name
so
name
of
directives
changed
from
specified
specified
by
an
argument.
The
change
from
I
to
URL
and
introspection
field
change
to
specify
by
URL.
B
So
I
give
everybody
ok
with
this
change,
if
not
like
it's,
it
sounds
like
back
shading,
but
I
think
we
need
to
a
consensus
about.
We
think
I
think
like
it's
the
worst
thing
that
we
change.
You
know
last
month
or
two.
So
if
everybody
ok
I,
think
work
is
pretty
stable
and
ready
to
change,
because
after
we
mentioned
to
draft
address,
any
change
in
graphic
images
would
be
breaking
so
as
it's
better
for
everybody
to
do
before
and
much.
A
Sounds
like
maybe
we
can
just
put
some
intensive
pressure
on
there
and
I
mean
if
you
you
guys,
can
figure
this
out
in
the
next
day
or
two,
then
we
can
include
specified
by
in
this
next
release
cut
but
Matt.
It
sounds
like
you
have
exactly
the
right
framing
of
what
the
issue
is.
That
test
case
does
look
wrong
to
me
as
well.
A
It
is
a
pretty
interesting
edge
case.
I,
don't
know
if
we
have
any
examples
in
the
spec
text
itself
for
any
case
like
this
I
think
all
the
other
examples
we
have
or
when
you
have
like
the
original
type
does
or
doesn't
have
a
directive,
and
then
the
extension
does
or
does
not,
and
we
explain
that
behavior,
but
not
when
there's
two
extensions
but
but
you're
exactly
right
that
that
second
one
should
cause
a
validation,
error.
B
Try
to
review
it,
so
we
owe
a
crew
called
direct
provocation.
You
need
your
key
location,
so
it
should
be
like
unique
in
no
senses,
so
yeah
I
will
check
it's
probably
back
further,
actually
like
introduce
validation
pretty
recently
in
1400.
It
was
like
a
year
ago,
more
than
a
year
ago,
but
like
it's
not
like
five
years
ago,
it's
like
I.
A
E
F
D
I
have
another
thing
to
add
for
the
custom
scalar
I
actually
auto-starting
implemented
in
tráfico
java
and
overall
it
looks
all
fine
and
it's
like
I,
don't
see
any
major
problems.
The
one
edge
case,
I
think
we
should
explicitly
call
out
in
one
way
is
and
one
way
or
the
other
is
what
happens
if
somebody
had
already
declared
a
directive
with
a
specified
name
is
specified
by
name
I
know
it's
an
edge
case,
but
I
think
we
should
call
out
what
happens
if
I'm,
just
also
from
an
implementation
point
of
view.
E
So
the
way
the
kid
works
in
college
is
right
now
is
that
if
you
specify
I'm
your
own
directive
with
this,
that
will
remain
this.
One
is
kinda
like
the
default,
and
you
would
just
be
overriding
that
default
and
I.
Think
then
your
got
cool
like
server
would
be
serving
up
a
non
compliance
schema.
Yes,.
D
Yeah
that
that's
fine
and
the
only
problematic
aspect
comes
when
you
have
special
logic
around
built-in
directive.
If
you
have,
for
example,
logic
that
you
don't
want
to
print
to
build
a
built-in
directive
in
the
STL
like
if
you
print
your
schema
and
you
have
like
logic,
it's
not
it's
built
interactive,
so
don't
print
it.
Then
you
need
to
kind
of
start
distinguishing
are
it's
a
built-in
directive
code
specified
by
odd
custom
directive
code
specified
by
in
order
to
be
consistent?
So
it's
and
yeah?
That's
that,
like
this
follows
up.
D
Recently,
added
that
all
good
in
scalars,
for
example,
should
not
be
printed
in
the
STL
and
there's
another
open
PR,
which
author
says
that
built-in
directive
should
not
be
printed
in
the
schema
and
in
order
to
clarify
this.
But
it's
also
like,
for
example,
tools
like
graphic
err.
They
they
filter
out
the
built
in
stuff
like
it
comes
in
like
you,
you
can
introspect
it,
but
it
never
shows
up
in
your
schema
explorer
on
the
right,
and
you
know
like
so
there's
special
logic
around
the
building
directives
and
yeah
it.
D
A
Including
any
kind
of
guidance
around
this
is
a
little
bit
of
a
mixed
message,
because
we
don't
really
like
describe
how
to
be
compliant
when
you
are
not
compliant.
You
know
it's
like
a
little
bit
of
a
tautology
like
well.
How
should
you
behave
in
cases
where
you're
not
compliant
with
this
scheme,
with
the
with
the
speck?
It's
in.
D
D
Maybe
I'm
not
understanding
on
making
not
clear,
but
it
should
explicitly
in
the
spec
I
think
what
happens
when
you?
What
should
happen
when
you
declare
that
the
directive
called
deprecated,
for
example,
all
that
specified
by
it's
not
like
under
service
against
the
spec?
It's
just
like
I
think
it's
not
covered
yet,
and
we
should
make
a
call
one
way
or
the
other.
Like
you
know
it's
not
it's
not.
Nobody
is
intentionally
against
it.
It's
just
it's
an
edge
case.
D
I
looked
it
up
today,
because
I
wanted
to
understand
what's
happening,
but
yeah
I
agree
with
Evan,
it's
actually
implicitly
I
would
say
it's
again
suspect
to
define
an
own
directive
deprecated
and
to
kind
of
be
consistent.
We
should
state
that
it's
going
forward
forbidden
to
declare
the
directive
called
specified
by
which
I'm
totally
fine
was
from
person
point
of
view.
I
think
it
just
should
be
included,
at
least
with
one
sentence
so
that
server
implementations
have
something
to
deal
with.
A
Yes,
I
think
that's
a
good
suggestion,
so
I
think
there's
one
thing
that
we
can
do
is
make
this
back
more
clear
and
I'm
kind
of
coming
through
it
now
to
look
for
other
examples
of
cases
where
we
do
this
and
we
we
do
this
for
scalar
types.
So
we
say
if
you
have
the
type
called
string,
it
must
behave
in
these
ways
and
strings
of
in
tight.
But
basically
what
that
one
sentence
means
is
that
you
can't
supply
your
own
type
called
string
that
has
different
behavior,
because
anybody.
G
A
Following
along
with
the
spec
or
building
tools,
as
soon
as
they
encounter
a
type,
and
they
see
it's
called
string,
they
immediately
want
to
guarantee
that
it's
gonna
behave
by
the
rules
in
the
spec
I
think
was
to
do
the
same
for
directives
and
we're
just
a
little
bit
more
terse
in
our
explanation
of
the
directives
and
we
click
otherwise
be
I.
Did
post
a
note
in
the
chat
about
at
least
like
a
naming
convention.
They're.
D
Like
I
think
it's
just
because
we're
introducing
in
new
directives,
this
kind
of
educates
becomes
more
more
obvious.
You
know,
like
nobody,
probably
ever,
dare
declare
the
custom
directive
called
applicated
because
it
always
was
kind
of
from
the
start
there,
but
like
the
possibility
of
happening
now,
was
the
new
directive
it's
kind
of
increased,
so
we
should
be
explicit.
Hydrant.
I
A
D
I
Just
wonder:
well,
you
know
the
thing
is
you
have
to
prefix
like
all
that
custom
directives
you
do
right,
you
create
and
they're
just
a
handful
of
directives
that
are
from
the
from
the
spec
itself
right,
so
I'm
not
sure.
If,
if
this
makes
sense
well,
you
cannot
just
prefix
deprecated
and
specify
by
now.
Obviously
that
would
be
breaking
too,
but
just
feel
some
are
weird
to
have
their
custom
directives
we
create,
you
have
to
be
prefixed
and
the
spectre
after
they
respect
directives,
not
right.
B
Actually,
it's
this
way,
I
think
there
is
a
path
forward
because
we
didn't
specify
by
you
wrote
introspection,
but
not
only
again
specified
by
Dirac
you
where
they
specified
by
URL
so
technically
like
if
sometimes
after
we
change
with
another
derivative,
we
can
add
specified
by
URL
which
point
to
this
back
and
it's
a
way
to
detect.
It's
not
gonna,
be
here
so
I'm,
not
sure.
We
need
to
get
anything
right
now,
just
keep
in
mind.
B
If,
like
wait,
so
we
decided
to
do
something
with
more
common
name
like
else
for
example,
or
some
some
more
common,
we
can
always
use
the
same
mechanism
on
to
use
for
the
Air,
Force,
cowards,
ongoing
types
and
directive,
or
anything
else
actually
like
a
kind
of
agree
is
a
fortune.
Everybody
took
everything,
but
the
world
experience
if
we
need
constantly
put
like
people
want
to
use
in
the
do
cognate
specially
working
configuration.
When
you
add
a
couple,
diligence.
A
A
If
you
think
that
this
directive
is
unique
enough,
that
the
odds
that
the
spec
lover
Inc
one
are
so
rare,
like
yeah,
don't
bother
with
a
prefix,
but
if
the,
if
the
working
group
is
currently
discussing
defer
and
you
think,
sweet
I'm
gonna
go
build
an
experimental
version
of
defer
and
you
call
it
defer,
and
then
it
gets
added
to
the
spec
with
like
a
different
behavior
than
yours,
like
you're
gonna
have
a
bad
time.
You
know
call
it
experimental
underscore
defer
or
something
like
that.
I
think.
A
That's
like
really
the
reason
why
it's
there,
because
that's
really
what's
bitten
us
in
the
past,
is
where
we've
had
like
early
versions
of
these
ideas.
It's
like
at
live
is
the
the
reason
that
this
particular
note
was
put
in.
There
is
because
we've
had
shipped
versions
of
graphical
software
with
at
live
added
that
all
has
wildly
different
behavior,
which
is
just
gonna,
make.
G
A
Any
kind
of
future
at
live
even
more
difficult,
but
yeah
I
don't
want
to
force
people
to
do
that
and
then
kind
of
Andy.
Going
back
to
your
original
question
of
what
should
what
should
actual
implementations
do
in
these
scenarios?
I
think
again,
we
can
have
a
little
bit
of
a
judgment,
call
cuz.
You
could
decide
either
to
be
quite
strict
and
say:
I'm
gonna,
throw
an
error
when
you
try
to
instantiate
your
schema.
A
You
know,
and
you
just
like
you
can't
boot
your
graphical
server,
if
you
do
that,
but
you
could
also
describe
to
decide
to
be
lenient
and
say,
like
all
right,
I'll
override
these
things
for
you
technically,
you
now
have
a
non-compliant
server,
but
we'll
do
our
best
to
continue
chugging
along
I
think
either
reasonable.
As
long
as
you,
you
know,
make
it
clear:
what's
gonna
happen
and
keep
people
from
shooting
themselves
in
the
foot
by
accidentally
falling
down
this
path.
A
F
A
F
D
So
I
just
wanted
to
say,
like
I'm
like
I
have
like
two
goals
like,
like
my
personal
opinion,
is
like
to
be
more
strict
and
I
would
honestly
prefer.
If
you
say,
please
reject
a
custom
directive
code
specified
by,
but
but
but
more
importantly,
we
should
be
explicit
in
the
spec
and
say
you
can
choose
either
way.
If
we
decide
you
so
like
that.
D
J
This
is
somewhat
apropos,
but
I'll
just
mention
it,
and
we
can
sort
of
postpone
this
discussion
later
until
we've
had
some
time
to
maybe
talk
about
it
offline,
but
I'm,
just
curious
whether
this
is
this
issue
has
been,
you
can
consider
it
in
the
context
of
like
namespaces
before
I
did
a
search
in
graph.
Ql
WG
were
interested
in
namespaces
at
Facebook.
Just
at
a
very
early
stage.
I
saw
a
mention
of
Facebook
I.
J
A
Think
it
has
not
been
considered
recently.
There
definitely
was
a
lot
of
discussion
on
this
in
like
2000,
17
or
18
I
think
and
at
the
time,
I
at
least
had
a
pretty
strong
opinion
that
it
was
more
of
a
solution
looking
for
a
problem
than
it
was
a
solution
to
a
problem
that
graphical
face
directly,
and
especially
with
some
experience
working
in
languages
that
use
namespaces.
A
It
can
be
really
confusing
if
you're,
if
you're
kind
of
new
to
that,
and
especially
when
you
encounter
a
case
where
you
have
two
things
that
they're
named
the
same
thing,
but
in
different
namespaces.
It
can
kind
of
get
tricky
to
track,
which
thing
you're,
looking
at
and
and
especially
since
I
think.
The
last
time
namespaces
were
proposed.
A
There
was
an
idea
to
have
the
built-ins
in
a
separate
name
space
than
the
like,
an
application
developers
schema
and
kind
of
edit
every
iteration
that
we
looked
at
just
forced
you
to
do
something
like
graph
Caillebotte
string
instead
of
just
string
when
you
wanted
the
reference,
a
string,
type
or
you'd
have
to
do
like
my
app
type
instead
of
type.
So
you
know
you
always
have
to
resolve
to
the
to
the
namespace
that
you
want
to
be
in
and
doing
that
just
ended
up
kind
of
being
really
tricky.
A
A
We
didn't
find
a
particular
path
that
was
exciting,
I
think,
especially
since
these
issues
still
kind
of
bubble
up
time
and
again,
we
can
kind
of
crystallized
exactly
what
the
problem
is,
how
many
people
face
this
problem
and
then
what
a
namespace
solution
tactically
looks
like
kind
of
from
first
principles
within
the
realm
of
graph
QL
that
could
still
have
legs
in
the
future.
Gao.
J
A
A
A
A
D
For
weakness,
which
was
started
in
2017,
maybe
have
a
look
again
so
quite
some
time
ago
chosen
a
key
and
this
progress
discusses,
adding
like
the
deprecation
metadata
to
also
argument
and
input
object,
fields
which
is
kind
of
like
I.
Think
that's
a
missing
piece
simply
in
the
spec.
So
far
you
can
do
pre
create
output
fields,
but
you
can't
duplicate
input,
fields
and
arguments
and,
from
practical
point
of
view,
that's
something.
B
So
I,
actually
today
reviewed
and
actually
remembered
entire
discussion.
So
idea
was
a
guy,
create
PR
and
was
bad
for
repo,
but
he
didn't
throw
up
on
working
group,
so
we
kind
of
discuss
it
without
him
and
because
keyword,
something
probably
happened
in
just-
could
not
join.
The
call
and
agreement
was
after
after
Groff
kill
Jesse
are
is
ready.
B
It
can
be
fast
forward.
Actually
so
it's
my
fault,
I,
didn't
think
the
guy,
so
I
think
works.
Solution
in
this
case
would
be
just
be
encouraged
and
now
after,
if
you
want
to
do
it,
if
not,
somebody
else
can
adopt
it.
For
example,
if
you're
interested
but
I
think
we
need
to
pink
original
guy
shows
and
she
live,
he
interested
continue
it
and,
however,
if
with
guy
with
didn't
response,
I
can
and
wherever
we
substitute
him,
don't
want
to
mess
with
graphical
Jessica
coming
miscarriages.
So
we
are
my
review
it.
Actually.
B
D
K
D
So
a
little
bit
on
top
of
this.
This
is
this
is
more
in
the
realm
of
Hygiene,
of
like
keeping
the
spec
relevant
and
keeping
like
the
spec
actually
up-to-date,
with
the
real
life
implementations.
It's
currently
for
those
of
you
who
don't
know
we
have
a
restriction
inside
Kraftwerk
krema
that
we
only
allow
unicode
code
points
from
the
basic
multilingual
pane
which
is
like
like
which
covers.
D
Basically,
everything
spoke
written,
but
it
doesn't
cover
emojis,
for
example,
so,
and
it's
it's
in
real
life,
actually
like
like
a
Java
and
actually
graphical
Ruby,
also
and
I'm,
guessing
more
allow
or
unicode
characters
to
be
put
into,
especially,
for
example,
descriptions
like
this.
That's
that's
the
most
important
part
like
insert
strings
so
inside
the
description
string
or
inside.
A
I'll
give
some
color,
since
it
was
my
pull
requests
and
and
it's
over
three
years
old
now
I
think
I
abandoned
it,
because
it
was
clear
that
I
just
didn't
have
the
the
context
or
time
to
take
it.
To
conclusion,
there
were
a
lot
of
like
specific
edge
cases
with
how
multilingual
planes
work
and
Unicode
that,
at
least
at
the
time,
I
just
didn't
have
confidence
that
that
change
I
was
making
was
the
right
one.
I
was
asking
for
a
lot
of
help
from
from
Ben
Hamilton.
A
A
I
I
don't
think
I
think
it
would
be
a
good
change
to
make
there
I
think
the
there
are
a
couple
open
questions
that
were
left
when,
when
working
on
this
I
think
you
can
kind
of
just
read
through
the
comments
on
that
pull
request
to
get
most
of
them,
but
I
think
the
biggest
one
is
like
what
happens
when
you're
in
an
environment
that
doesn't
have
good
support
for
for
multilingual
plane.
Unicode
honestly,
part
of
the
reason
why
this
got
tricky
is
Java
scripts.
A
Just
really
bad
at
this,
like
only
in
very
recent
versions
of
the
Java
scripts
SPECT
is
their
multilingual
plane,
support
on
string,
literals
and,
and
so
just
writing
a
reference
implementation.
At
the
same
time
that
I
was
working
on
spec
implementation
just
got
kind
of
really
tricky.
So
as
long
as
we
can
kind
of
get
past
those
hurdles,
I
I
don't
see
any
reason
why
we
shouldn't
be
able
to
to
make
this
work.
Also.
C
They
were
internet,
they
just
introduced
in
utf-8
JSON
parser,
for
instance,
to
get
away
from
having
to
pass
always
a
utf-16
strings
and
high
performance
announcement
service,
and
also
we
for
chocolate.
We
implemented
also
utf-8
graphic
as
reading
on
the
incoming
byte
streams,
so
it
makes
things
bigger
like
the
strings
and
strings
immutable,
so
once
you
produce
them
with
to
garbage
collect
them,
so
there
are
also
things
that
are
to
be
considered
because
of
going
for
you
to
sixteen.
C
D
Like
I
just
want
to
add
on
the
metal
level,
the
whole
discussion
about
like
Unicode,
stuff
and
encoding
is
very
similar
to
actually
like
times
with
stuff.
In
my
opinion,
it's
often
a
topic
which,
like
like
it's,
the
edge
cases,
gets
really
tricky
and
the
common
understanding
of
it
is
sometimes
not
not
there,
I'm
and
and
so
I'm
really
also
not
a
full
Unicode
expert.
But,
for
example,
one
aspect
which
is
kind
of
inside
the
spec
confuse.
D
It's
conflated,
two
things
it's
like
one
thing
is
like
Unicode
support
in
general,
and
the
other
thing
is
how
to
encode
this
Unicode
things
actually
two
different
things
and
like
and
duty
of
eight
and
you
to
have
sixteen,
and
it's
like
two
possible
things
for
to
you,
encode
something
and
it's
an
important
implementation
detail.
But,
for
example,
the
spec
could
also
be
more
clear
that
this
is
outside
of
the
spec,
for
example,
and
so,
like
JavaScript
I,
actually
looked
up.
D
How
JavaScript
in
the
current
spec
I,
don't
know
which
spec
you
looked
at,
probably
in
order
only
but
like
in
the
current
one.
They
actually
allow
for
Unicode
support
em
in
in
all
strings
in
the
source,
text
and
I
think
the
only
open
question
a
little
bit
around
it.
This
may
be
escape
strings
like
if
we
want
to
allow
like
escape
strings
with
more
than
four
digits
for
compounds
outside
of
the
BMP,
and
that
may
be
the
most
critical
part
all
other
things.
D
C
Default
string
is
YouTube
60,
but
then
it's
quite
large,
if
you
are
pulling
in
utf-8
data,
it's
much
more
efficient
to
pass
utf-8
data
and,
like
we
are
never
like
when
a
graph
per
week
loss
comes
into
our
server.
We
actually
never
never
persisting
it
as
a
string.
We
are
pausing
the
incoming
jason
stream
as
reading
on
the
bytes,
and
we
are
then
shifting
the
bytes
a
little
to
get
even
the
grass,
where
request
out
there
and
to
never
create
strings
world
so
basically
to
pass
very
in
a
very
performant
way
and.
C
D
I
think
this
is
not
what
I'm
saying
you
can
do
you
to
f8.
You
can
do
YouTube
16,
you
can
do
it
in
code,
whatever
you
want,
like
the
spec,
doesn't
dictate
how
you
encode
stuff
in
any
way
like
the
reference
implementation
JavaScript
in
Java,
for
example.
Also,
it's
all
internally
actually
utf-16
encoded
in
Java
and
JavaScript,
but
this
has
nothing
to
do
with
how
you
represent.
A
I
could
just
interrupt
for
a
bit.
This
is
just
wrong.
It's
there,
the
circles
back
to
to
me
saying
that
I
am
NOT.
A
Unicode
expert
I
wrote
the
original
spec
for
our
scalar
types
and
I'm
pretty
sure.
That's
just
completely
incorrect,
like
Andy.
What
Andy's
suggesting
is
what
it
should
be
and
the
fact
that
our
string
type
declares
the
encoding
of
the
Unicode
is
is
just
weird
like
anyone
looking
at
that
that
understands
Unicode
probably
thinks
Graff
kills
a
joke,
because
you
know
I'm
I'm,
just
like
bad
at
my
job,
so
I
think.
A
I
didn't
not
saying
that
you
did
I'm
being
self-critical
I,
just
in
the
sake
of
time,
because
I
think
we
can
treating
this
as
a
holistic
problem
as
actually
pretty
hard
as
part
of
the
reason
why
I
had
to
put
this
down
on
the
ground
and
walk
away
from
it.
I'm
gonna
suggest
that
if
you
want
to
pick
this
back
up
as
a
champion
Andy
that
you
snap
it
into
a
couple
pieces
and
and
take
on
those
individual
pieces
rather
than
the
whole
I,
think
it's
a
it's
worthwhile
to.
A
Whenever
you
talk
about
one
of
those
pieces
to
talk
about
the
the
vision
is
to
get
to
full
Unicode
support
for
graphic
you,
oh,
but
we
want
to
talk
about
those
as
individual
pieces
so
that
it's
easier
to
kind
of
think
about
the
implications
of
each
I.
Think
the
first
one
is
is
gonna,
be
really
easy
to
do.
It's
just
gonna
be
to
comb
through
the
spec
and
make
sure
that
we're
just
super
consistent
with
language.
A
Whenever
we
talk
about
characters
or
code
points-
or
you
know,
sometimes
we
say
characters
but
a
character
in
a
code.
Point
are
not
the
same
thing:
I
learned
this
after
I
wrote
these
things
in
the
spec.
Whenever
we
say
character
in
the
in
spec,
we
really
need
code
point
anytime,
we
say
utf-8,
we
really
just
mean
Unicode,
so
I
think
like
having
a
first
pass.
It's
just
like
an
editorial
pass.
It
makes
it
general
I.
Think.
A
Another
thing
you
could
do
is
just
only
just
like
change
what
code
points
are
allowed
right
now
we
say
any
code
points
outside
of
the
basic
plane
are
not
allowed,
and
that
means
that
a
bunch
of
implementations
are
non-compliant
because
they
accept
code
points
outside
of
that
range.
That's
also
weird.
We
can
fix
that
I.
Think
that
opens
some
questions
for
what
parsers
do.
We
might
end
up
with
some
version
of
like
a
note
that
you
don't
have
to.
A
You
know
if
we
want
to
have
a
multi
plane
escape
sequence,
which
was
also
kind
of
like
all
these
things
were
packaged
together
or
in
that
one
original
ploy
request
for
me
a
couple
years
ago
and
I
think
I
just
probably
did
a
bad
job
doing
that
I
think
if,
with
a
better
champion
and
splitting
it
out
in
two
separate
pieces
of
work,
we
can
probably
get
that
landed.
Okay,.
G
And
just
and
no
character
has
in
the
wild,
been
problematic
in
like
databases
and
things
Postgres,
for
example,
doesn't
like
like
the
null
character
generally
speaking,
and
it's
I
think
valid
in
the
BMP
by
default
and
maybe
even
allowed
in
graphical
by
default.
Anyway.
It's
just
no.
It
was
just
another
one
of
those
things.
I
guess
needs
to
be
carefully
considered
in
terms
of
Interop.
D
Yeah
like
this
is
like
also
another
interesting
thing
like
system
interoperability
and
encoding
is
a
whole
nother,
beast
and
and
I
think
like
Lee
is
absolutely
right.
Like
it's.
It's
kind
of
a
hygiene
thing
where
we
need
to
have
multiple
paths
of
multiple
smaller
aspects
and
I
just
want
to
get
like
an
initial
feeling
if
they're
like
fundamental
things
that
prevent
us
of
moving
forward
or
if
we
could
try
to
take
it
and
I'm
happy
with
the
sentiment
that
we
could
try
to
take
yeah.
A
B
Submit
a
project
for
cuts
in
graphical
cuts
that
we
discussed
ringless
coated
in
autumn,
so
I
know
I
promised
to
do
something
but
Morrigan
behind
with
water
stuff,
including
this
one.
So
I
submitted
for
google
Summer
of
Code
and
since
white
unicode
is
not
coming
to
this
back,
hopefully,
by
the
end
of
summer,
we'll
have
cuts
and
I
think
it
would
be
great
to
have
a
Unicode
test
there.
B
D
After
a
little
bit
more
more
to
try
topics,
I
think
this
is
one
way
we
could
talk
a
little
bit
more
about
what
we
wanted
to
or
like
what
kind
of
possibilities
we
have.
So
the
fundamental
challenge
we
have
right
now
and
going
on
forward
I
think
this
challenges.
Getting
more
I'm
urging
to
address
is
the
introspection.
D
Query
is
like
it
Norma
graphically
right,
like
you
have
to
specify
every
field
you
want,
and
we
already
have
one
feared
added
over
time:
description
which,
which
means
for
clients,
in
order
to
get
all
the
metadata
like
all
the
Indian
introspection
data
they
often
have
to
use
OData
tried
to
use
like
a
two
phase
introspection
why
they
try
to
query
the
introspection,
including
description.
If
the
error
comes
back,
saying,
description
is
not
supported,
then
it's
an
old
version
of
the
server,
so
they
go
back
and
and
very
introspection
without
description
field.
D
So
we
just
actually
we
add
three
new
fields
now
in
the
new
on
the
in
the
soon-to-be-released
back
and
it's
like,
we
add
the
description
field
choose
email,
I
think
we
add,
like
it's
repeatable
attribute
to
scale
us
and
at
some
point
accustomed,
scalar
and
specified
bias,
also
added
so
now.
D
Suddenly
we
have
like
including
description
for
feared,
which
each
of
them
theoretically
could
be
optionally,
supported
or
not
yet
supported
by
the
server,
and
this
makes
this
whole
multi-phase
varying
ron,
shipp
from
a
client
I
think
very,
very
awkward
and
I
think
it's
a
generous
challenge
with
introspection
and
how
to
evolve
introspection
data
over
time
and
I
wanted
to
just
ask
what
do
you
think
about
it?
Should
we
take
this?
What
are
the
options,
but.
C
Why
is
it
awkward?
I
mean
we
what
we
do
for
all
the
tools
that
we
now
have?
It's
really
a
two
phase
introspection
and
the
first
corner
gets
all
those
optional
stuff.
So
we
know
after
the
first
coil
that
which
of
those
four
things
actually
are
there.
We
are
also
checking
for
the
subscription
type,
because
in
scheme
of
stitching
we
also
have
sometimes
very
old
records
everything
in
the
back
end.
So
we
are
also
asking
for
the
subscription
type.
Is
it
there
is
not
there
subscription.
C
B
When
first
you
asked
what
fields
existing
and
when
you
form
a
query,
am
I
doing
a
presentation
and
we
discussed,
like
everybody
agreed
when
I
worked
behind
this
implementation
inhale
implemented
it
and
thank
you
for
whether
actually
we
reviewed
implementation
so
and
it's
coming
to
graph
changes
already
agreed
with
graphical
guys,
the
thing
is
I,
don't
want
to
add,
like
I,
don't
want
to
provoke
1500
and
I
promise,
Jesse
maintainer,
not
to
add
more
breaking
stuff
or
experimental
stuff,
and
finally,
at
least
1500.
So
just
who
is
really
say
the
simple
solution.
F
G
B
L
B
D
B
Reviewer,
so
if
you
open
the
white
presentation,
it's
like
I
sent
the
link
in
the
chat.
So
it's
like
little
so
like
some,
but
basically
on
the
fourth
slides
one
of
the
slides,
yeah
slide
number
10.
You
can
see
you
can
ask
the
server
what
types,
what
fields
on
introspection
type
so
like
in
curl
case.
He
asked
like
all
the
types.
What
fields
they
have
I
personally
think
it's
too
much
traffic.
So
we
can
just
ask
what
heals
introspection
types.
C
A
Have
a
couple
of
thoughts
on
this
one
is
that
I
do
think
it's
worth
backing
up
a
bit
and
thinking
if
there
are
different
solutions
like
is
there
something
that
in
the
future
could
replace
introspection,
I
think
it's
at
least
worth
the
thought
experiment
so
Andy?
If
you
feel
strongly
about
this,
if
anybody
else
feel
strongly
about
this
I
don't
want
to
I,
don't
want
to
set
things
up
so
that
that's
that's,
not
a
path
that
we
can
explore.
We
might
decide
that
everything
we
explored
down.
A
That
path
isn't
worth
doing,
but
it's
better
to
explore
it
and
say
it's
not
worth
doing
than
not
explore
it
and
keep
asking
the
question
so
just
want
to
make
sure
that
that
part
is
clear.
The
other
part
is
that
we've
been
talking
about
this
to
you
phase
introspection
thing,
I
feel
like
forever,
like
it's
a
long
time
that
we've
been
talking
about
this
and
it's
one
thing
to
have
like
a
handful
of
it
like
different
tool
like
the
hot
chocolate
tools,
have
a
variant
of
this.
A
The
graphical
jeaious
core
has
like
a
more
minor
version
of
this,
and
Evon
has
like
a
more
sophisticated
version.
Mikhail
was
contributing
some
version.
It
seems
to
me
that
if
introspection
is
going
to
be
core
to
tooling,
then
ultimately,
this
same
bit
of
code
is
gonna,
get
replicated
by
every
language,
which
means
we
should
describe
exactly
how
it
should
work.
A
We
should
do
that
in
the
spec,
so
I
think
if
anybody
has
gotten
to
the
point
where
they
think
that
their
two
phases
introspection
is
pretty
bulletproof
and
future
proof,
then
let's
start
evolving,
that
into
spec
text
description
and
add
that,
as
a
chapter
to
the
introspection
section,
I
think
that
would
be
super
valuable
for
people
who
are
encountering
exactly
the
same
question
and
aren't
as
plugged
in
as
everybody
in
on
the
call
is
and
they're
like.
Oh
yeah,
all
my
tools
are
breaking.
A
How
should
I
handle
this
and
instead
of
like
looking,
you
know,
source
code,
implementation
of
other
tools
or
like
at
best
finding
notes
from
these
meetings?
They
should
be
able
to
open
up
that
spec
and
be
like.
Oh,
okay,
there's
the
answer
to
my
question
right.
There,
oh
cool,
look
and
here's
even
like
an
algorithm
description
and
like
a
human,
readable
description
of
how
that
thing
should
work.
I,
don't
know
if
anyone
wants
to
volunteer
to
take
a
stab
at
that,
but
I
think
I
would
be
hugely
valuable
to
have
just.
C
A
A
safe
way,
it
is
a
little
bit
weird
I,
do
think
it's
worth
kind
of
like
thinking
through.
If
there's
anything
normative
there,
I
don't
I,
don't
know
if
there
is
or
not
it
sounds
like
it's
probably
non
normative,
but
but
still
valuable
to
include,
but
I
wouldn't
get
too
hung
up
on
the
deal
tilt
details
of
that
stuff.
First
I
think
at
first
we
should
just
kind
of
say
we
should.
We
agree
that
it
would
be
valuable
to
capture
that
stuff
outside
the
context
of
source
code.
D
B
Yeah
I'm
totally
okay
with
non-normative
mode.
It's
like
actually
like
the
flexibility
of
introspection.
If
it
wasn't
flexible,
we
would
know
right.
We
cannot
do
a
two-stage
introspection,
so
I
ideas
that
introspections
the
same
query
I
wore
was
to
use
this
trick
right
now
like.
If
we
fixate
work
introspection
query
like
years
ago,
we
would
not
be
able
to
to
station
inspection
so
on.
B
Right
and
party
people
have
five
year
extensions
to
introspection
which
is
like
what's
not
going
yet,
but
that's
why
I,
partly
for
keeping
it
no
more
mature
so
like
when
people
experimented
with
extensions,
they
were
able
to
do
that
or
give
they
have
certain
use
case.
Like
I.
Remember,
sashko
submitted
an
issue
that
oh
boy.
B
Yeah
and
like
small
note,
I'm
also
not
sure
about
that,
but
I
work.
You
know
Utley
about
considering
other
possibilities,
at
least
like
we
need
to
write
with
why
we
refuse
so
like
crazy,
submitted
I
said,
and
you
basically
like
mark
field,
is
it's
like
servant
and
rejected?
If
it
doesn't
know,
we
sealed.
So
it's
like
why
simply
a
solution
not
involve
into
stage
and
it's
kind
of
like
weird
in
some
senses
and
that's
like
breaking
like
a
lot
of
things
but
I
believe
if
we
expect
we,
we
need
to
consider
other
options.
B
So,
like
one
thing
is
to
like
respect,
isn't
for
show
called
roughly
geographical
Java
and
he
was
the
consequences.
Another
thing
he
stirred
stuff
in
this
part
so
I
think
what
Barry
and
Foursquare
country
should
be
higher.
We
should
maybe
have
works
more
if
she
discussed
other
possibilities
and
why
it's.
A
Yeah
I
agree:
I,
don't
want
to
cajole
anyone
into
doing
those,
but
certainly
if
anyone
feels
strongly
about
writing
them
up.
I
do
think
it's
you
know
well
well,
it
doesn't
feel
great
to
have
RFC's
end
up
in
the
rejected
state.
It
is
actually
like
a
pretty
useful
way
to
document
process,
and
so,
when
someone
pops
up
and
says
like
hey,
why
isn't
there
a
field
that
I
can
call
and
get
like
one
big,
JSON
blob?
That
is
everything
it's
like.
We
should
talk
about
that.
A
If
we
decide
it's
good,
we'll
do
it,
and
if
we
decide
it's
not
good,
then
we
can
forever
have
an
issue
that
we
can
point
to
that's
rejected.
That
has
context
on
why
we're
not
following
a
particular
task.
So
if
that's
something
that
anybody
feels
strongly
about
doing,
I
think
would
be
valuable
to
have
that
kind
of
thing,
but
but
again,
I
know
it's
like
it's
a
weird
thing
to
kind
of
follow
that
process.
C
As
far
as
the
introspection
goes
in
the
current
way,
I
also
was
I
mean
I
was
talking
with
even
in
bed
that,
when
I
wasn't
and
I
always
thought,
the
growth
last
year
would
be
the
best
way
to
express
the
schema.
But
having
a
way
to
query
the
system
for
type
information
is
basically
offering
a
way
like
I
can't
fetch.
The
type
information
like
I
can
fetch
data.
It's
a
very
like
a
very
safe,
sufficient
way.
Graphical
work
and
I
think
we
shouldn't
break
that.
A
D
A
K
Hey
everyone
so
I.
Basically,
our
sample
submitted
a
poor
request
and
that
added
a
little
bit
content
to
Liliana's
initial
RFC.
The
poor
request
itself,
basically
added
some
background
of
alternative
solutions
of
traditional
request
response
in
order
to
improve
your
latency,
such
as
the
split
query
or
you
can
do
pre
fetch
as
well
as
highlighted
what
we'd
on
difference
between
subscription
and
different
stream.
K
We
highlighted
that
the
use
case
of
different
stream
is
not
for
to
reflect
real
time
changes
and
what
that
means
is
that
implementation
are
not
required
to
reflect
any
changes
happening
with
the
interleaving
mutations
and
so
appreciate
comments
on
that
and
thoughts.
Definitely,
and
so,
as
we're
trying
to
move
come
come
up
with
the
phase.
One
of
the
proposal,
I
realize
I
have
a
lot
of
questions
about
what
to
include
in
the
different
streams
back
and
what
to
not
include,
and
so
the
very
I'll
send.
K
K
A
Think
this
is
exactly
the
right
conversation
that
we
should
be
having
the
way
that
I
think
the
the
highest
quality
RFC's
that
have
gone
through
this
process
have
worked.
Is
they
start
out
not
by
describing
a
solution
or
a
change,
but
by
describing
a
problem
space
and
the
solutions
that
exist
in
that
problem,
space
and
weighing
them
against
each
other?
A
That
takes
a
lot
of
work,
but
it
yields
much
higher
quality
results
because
it
like
these
are
exactly
the
kinds
of
questions
that
come
out
of
that
process.
So
it
sounds
like
you're
already
backing
up
and
thinking
about
this
at
a
broader
level,
which
is
awesome
so
I
want
to
support
you
doing
that
and
if,
if
you
can
kind
of
find
ways
to
capture
that
in
this
RFC
document,
I
think
that
that
can
be
a
good
way
to
sort
of
like
reframe.
A
This
document
around
the
problem
that
we
want
to
solve
and
then
talk
about
defer
and
stream
as
to
potential
solutions
in
that
space.
But
it
sounds
like
what
you're
describing
is
some
kind
of
like
prefetched,
decorator
or
something
similar
to
that.
But
I
don't
know
exactly
what
it
looks
like,
but
I
just
want
to
say
that
I
would
support
any
kind
of
exploration
beyond
kind
of
the
solutions
that
we've
already
considered.
Yeah.
K
F
A
It
might
make
sense
to
separate
them.
I
do
think
it
will
open
questions,
I,
guess
it
depends
on
how
exactly
stream
ends
up
working
and
if
stream
takes
on
the
similar
properties.
That
defer
currently
has
my
the
original
version
that
I
had
pitched
and
things
very
much
may
have
changed
since
then
was
stream
would
operate
on
arrays
of
things
where
defer
would
operate
on
Singleton's
of
things
so
describing
the
difference
between
waiting
on
everything
in
a
field
versus
waiting
on
everything
consecutively
I
think
there's
a
clear,
parallel
and
react
concurrent
plans
about
there.
A
They
have
this.
Like
concur
list
I,
don't
remember
exactly
what
it's
called,
but
something
like
that.
That
allows
you
to
wait
for
things
in
order
in
the
array,
so
that
that
was
kind
of
the
original
idea
behind
that.
But
if
that's
going
to
shift
I
think
that's
totally
fine,
we
should.
We
should
allow
space
for
that
to
change.
K
Make
sense
the
second
question
that
I
have
at
Facebook,
we
experimented
with
different
stream.
We
added
a
lot
of
like
supplemental
features
such
as
batch
payload
and
if
arguments
in
your
stream
and
deferred
directives
for
easy
AV
testing.
So
those
are
features
I
was
wondering
like,
which
would
be
valuable
to
include
in
this
bag
and
what
would
be
like
and
so
sort
of
like.
K
A
That's
a
good
question,
I
think
some
things
to
think
about
as
you're
as
you're
working
out.
That
answer
is
sort
of
one
back
to
your
original
question
of
just
doing.
One
thing
make
it
harder
to
do
another
thing,
I
think
that's
always
like
a
great
question
to
keep
in
mind
that
if
you
it
from
a
high
level,
I
agree
with
what
you're
suggesting
like
find
the
thing
that
is
simplest
and
propose
that.
A
But
if
the
thing
that
is
simplest
actually
makes
it
harder
to
do
the
more
sophisticated
thing
down
the
line,
then
it
could
become
more
problematic.
Also,
if
there's
cases
where
it's
not
necessarily
about
it
being
simple
or
complex,
it's
about
just
making
sure
that
we
fully
describe
behavior.
So
you
have
this
thing
describing
how
the
first
ream
might
interact
with
include
and
skip.
It
feels
like
we'd
have
to
describe
that.
You
know
that
that's
just
going
to
come
up
as
a
question
is
when
these
two
things
are
next
to
each
other.
D
Like
I
I,
really
like
the
your
push
of
bringing
this
more
to
the
open
after
experiencing
inside
Facebook
over
the
couple
and
last
couple
of
years
with
it,
I
would
be
really
interested
to
know
a
little
bit
more
about
your
overall
system.
How
you
implemented
it,
not
maybe
in
every
detail,
but
because,
on
a
cracking
point
of
view,
if
I
look
at
this.
D
We
had
a
discuss
Matt
in
our
year,
one
a
half
years
ago
and
his
working
group
and
somebody
from
Facebook
also
shared
some
some
thoughts
about
it
and,
and
only
maybe
it
was
you
like,
and
they
mentioned
that
all
of
these
stream
and
different
semantics
really
depend
on
the
underlying
infrastructure
of
Facebook,
also
to
actually
to
bring
in
streaming.
Data
and
I
would
be
really
interested
to
know
at
least
a
little
bit
more
about
how
this
works
and
how.
D
D
Yeah
I
just
have
like
very
simple
question
like
okay
stream
sounds
good,
but
my
database
allows
me
to
query
a
table.
It
doesn't
stream
back
easily.
Is
it
implemented
as
a
pops
up
mechanism?
Is
it
like
a
human
system?
Maybe
on
your
side
and
what
are
the
patterns
you
saw
of
what
kind
of
use
cases
and
that
was
actually.
C
C
When
he
wasn't
Facebook
about
that,
like
he
explained
that
there,
in
some
cases
needs
to
be
a
reactive
data
system
to
support
some
of
those
features,
and
there
was
something
like
that
in
that,
like
explaining
a
bit
more
deeper,
how
that
really
works,
how
you
can
bring
that
system
to
life
I
would
be
totally
interested
as
well.
Yeah.
K
And
so
for
different
stream
at
Facebook,
we
make
basically
it's
an
attempt
to
represent
the
future
and
promises
in
a
lot
of
common
languages
as
stream
and
defer,
and
we're
not
using
pub/sub
for
stream
and
defer,
for
the
exact
same
of
for
the
exact
reason
that
we
are
not
here
to
keep
a
long-lived
connection
and
to
reflect
real-time
changes.
So
the
connection
is
actually
very
short-lived.
K
We
I
don't
think
we
have
the
stream
mechanism
to
the
underlying
databases.
So
what
happens?
Is
people
would
actually
create
a
Suberu
like
futures
and
then
like
put
them
in
their
event
loop,
so
that,
like
we
stream
things
back
in
that
order,
so
that
was
basically
the
underlying
mechanism.
We
actually
allow
people
to
implement
their
own,
like
async,
iterator
or
a
sync
generator
under
the
hood.
So
this
is
just
an
API
to
hook
into
those
projects.
A
One
thing
I
wanted
to
point
out.
Was
you
know
something
that
we
really
deliberated
over
when
working
on
subscriptions
is
describing
a
an
abstraction
for
both
content
delivery
and
for
under,
like
you
have
to
model
how
things
are
returned
in
a
response,
and
you
have
to
model
how
you
get
information
and
in
like
vanilla,
graph,
QL
queries
all
we
really
had
to
describe.
A
It
was
promises,
and
we
we
didn't
even
really
do
that
particularly
well
I,
don't
think,
but
we
just
said
like
sometimes
when
you
call
this
field,
it
could
be
asynchronous,
which
means
everything
has
to
be
asynchronous
and
that
just
implied
that
there
was
a
promise
and,
and
so
the
modeling
of
the
underlying
data
was
you
have
to
ask
for
something.
You
wait
and
you
get
the
data
back
and
the
modeling
response
was
you
get
a
request
you
execute
and
then
you
send
the
data
back
so
fairly
straightforward.
The
subscriptions.
A
It
became
way
less
clear
and
exactly
the
same
kind
of
questions
that
you're
hearing
now
we're
coming
up,
which
was
like
okay.
We
can
cut
some
kind
of
idea
of
how
this
might
get
sent
back
from
a
graphical
server,
but
like
what
does
that
graphical
server
doing
under
the
hood?
So
with
subscriptions,
we
ended
up
describing
two
ideas:
we
described
source
stream
and
response
stream,
so
you
can
like
find
these
in
the
spec
there
like
right
under
the
executing
subscriptions
section
and
response
stream
is
actually
the
important
one
like
response
stream
describes.
A
How,
with
the
graph
QL
service,
responds
back
to
a
client,
that's
asking
for
something,
but
what
was
like
not
actually
required,
but
ended
up
being
really
valuable.
Was
this
source
stream
concept
and
source
stream?
It's
like
really
like
it
even
says
this
is
application-specific,
but
it
allowed
us
to
describe
behavior
in
the
spec
by
some
underlying
low-level
mechanism.
That,
basically,
is
in
is
an
async,
iterator
I.
A
Is
there
a
execution
logic
that
consumes
event
streams
is
their
execution
logic
that
only
consumes
promises
like
do
you
need
one
or
the
other
in
order
for
this
to
work,
or
is
there
some
new
concepts
that
makes
the
ferrand
stream
work
the
way
we
expect
them
to
work?
My
sense
is
that
all
the
concepts
that
we
need
are
already
described
but
I
think
it's
gonna
be
an
open
question.
A
One
one
thing
that
might
help
is,
you
know,
kind
of
jumping
the
gun
and
going
all
the
way
to
like
if
we
had
to
write
an
execution,
spec
text
like
what
would
that
look
like
it
would
at
least
kind
of
force
you
to
write
it
down
in
a
way
that
would
start
to
consume
these
things
that
are
already
described.
So
when
the
question
comes
up
of
like
alright.
Well,
what
are
your
underlying
systems
actually
look
at?
You
can
kind
of
point
to
a
line
there
and
say
like
okay
yeah.
A
Well,
we
have
a
database
that
speaks
streaming,
and
that
goes
here
and
second,
this
database
does
not,
but
we
fake
it
in
this
way
and
then
that
lets
us
model,
this
abstraction
that
we're
writing
down,
but
I
think
that's.
This
is
gonna,
be
the
hardest
part
of
differnce
stream.
By
far
is
helping
people
understand
how
they
would
actually
go
implement
this
thing,
hopefully
that
was
useful.
Yeah
yeah.
K
Yeah
definitely
I
actually
what
what
was
interesting
for
me
when
I
was
implementing
different
stream.
Is
that
those
two
actually
behave
very
differently
so
with
extreme?
What
happens?
Is
we
basically
allow
people
to
return
us,
so
your
resolver
is
that
over
two
a
value
returns
and
async
iterator
or
some
similar
for
other
languages.
K
You
know
resolver
that
we
delayed
in
like
in
the
queue,
so
that's
kind
of
a
different
kind
of
implementation
and
have
a
different
feeling
into
that.
Specifically
when
crowded
developers,
they
need
to
write
prada
logic
for
the
async
rewriter
if
they
want
to
use
upstream,
and
they
don't
need
to
do
anything
if
that's
a
defer.
K
So
that
was
kind
of
interesting
and
that
and
what
you
just
said
made
me
feel
like
maybe
like
there
is
an
abstraction
that
we
did
not
describe
for
the
defer
itself,
because
yeah
yeah,
like
that,
the
idea
of
the
queue
the
idea
of
when
the
underlying
resolver
code
is
asynchronous.
An
executor
can
choose
to
not
a
weight
on
it
and
instead
of
instead,
just
put
it
into
you.
A
Cool
yeah
I
think
it
might
be
useful
as
an
exercise
to
write
out.
You
know:
low-quality
spec
texts,
just
to
kind
of
force
you
to
exit
the
hack
code
base
and,
like
re,
implement
the
ideas
yeah
cuz.
It's
also
a
way
to
take
like
real
code
that
you've
written
and
put
it
in
front
of
other
people,
and
that
way
we
can
all
kind
of
look
at
the
same
thing.
A
K
A
K
A
couple
more
question
is
that
we
have
a
lot
of
additional
context
that
we
felt
would
be
useful
to
the
end
user
of
different
stream
they're,
not
necessarily
going
to
be
helpful
for
the
implementers
of
different
streams
such
as
like
what
what
are
the
intended
use
cases
for
those
things,
and
it
doesn't
feel
the
spec
is
the
right
place
to
put
those
contents,
but
it
does
feel
like
helpful.
So
I
was
wondering
what
are
some
common
suggestions
about
those
pieces
of
information
like
where
do
we
present
them?
I.
A
Think
we
can
err
on
the
side
of
including
that
stuff
in
the
spec.
There's
lots
of
examples
already
of
non-normative
notes,
scattered
throughout
the
spec
that
make
suggestions
about
how
and
why
you
might
use
various
things.
My
rule
of
thumb
is
if
the
FAQ
for
graph
QL
should
be
interleaved
with
the
spec
when
possible.
If,
when
reading
the
spec,
you
have
a
question,
we
should
do
our
best
to
answer
that,
and
in
that
way
the
spec
is
is
more
than
just
a
description
of
how
to
implement
graph
QL.
A
It's
actually
kind
of
a
way
to
learn
it
along
the
way
so
I
I
mean
I,
saw
some
of
the
ones
that
you've
noted
in
in
your
comment
about
especially
around
the
performance
stuff.
I
think
that's
that's
hugely
useful
to
talk
about,
because
the
one
thing
that
scares
me
the
most
about
proposals
like
this
is:
is
people
misunderstanding
what
they
are
thinking?
It's
magic
performance,
pixie
dust
sprinkling
it
all
over
everything.
B
Best
practices,
which
also
we
should
speak
more
like
even
more
about
best
practices.
So
it's
also
another
place
because
at
the
move
they
don't
have
frequent
last
question.
They
really
created
a
repo
but
know
what
you
volunteer
to
work
on
it.
So
thank
you
like
stuck,
but
we
have
best
practices
page,
but
obviously
it's
like,
oh
when
we
merge
it
graduate
in
the
stage
another.
A
comment
about.
B
One
of
the
think
I'm
personally
I'm,
not
using
graph
kill
so
I,
had
not
experienced
problems
for
which
were
different
and
three
MS
solutions.
So
for
me,
awake
I'm,
just
like
doing
executors
and
other
stuff,
but
I
noticed
when
we
discuss
subscriptions.
It
was
two
mechanisms.
One
is
to
create
a
ravine,
expect
people
and
also
Robert
use
issues.
So
he
tried
to
ask
my
kids
awaited
questions.
B
Should
we
support
multiple
subscription
and
one
query
or
not,
should
be
sure
transport
be
unidirectional
or
bi-directional
and
he
creates
separate
the
issues
for
issue
access
question
and
he
tried
to
make
it
really
really
narrow.
So
discussion
is
going
wild.
So
if
I
think
it's
also
a
good
mechanism
and
what
happened
back
then
it's
like
group
of
people
from
who
was
really
interested
in
subscription
and
they
constantly
discussing
like
with
with
issues
on
the
repo.
B
So
it's
actually
move
RFC
forward
because
for
other
issues
like
for
input,
unions
who
don't
cover
because
oh
wait,
trophical
kind
of
questions
we
we
just
need
to
choose
so
RFC
is
like
fully
sufficient
for
what
we're
doing,
but
with
totally
new
stuff
like
if
you
feel
like.
It's
useful:
you
can
create
issues.
K
K
B
G
A
K
Also
aren't
interested
being
the
champion
yeah
yeah
and
that's
great
yeah.
Maybe
we
can
like
start
working
on
like
trying
to
change
this
back
and
then
figure
out
what
what
are
the
things
we
need
to
answer?
Come
there
yeah
open
to
changing
the
reference
implementation
to
match
the
spec
as
it
evolves?
Yeah
sounds
good.
Let's
check
offline,
then
yeah,
perfect.
A
Great,
the
rest
of
the
entrance
criteria
are
are
like
a
little
bit
more
ambiguous
they're
there
on
purpose,
the
the
real
reason
for
the
difference
between
stages,
0
and
stage
1
is
we
want
to
encourage
lots
of
people
to
come
up
with
ideas
they
all
at
zero
stage?
1
are
really
the
the
set
of
ideas
that
we
expect
there
to
actually
be
like
continued
work
on
so
there's
there's
a
clear
champion,
we
kind
of
know
what
space
we're
working
in.
A
So
there's
a
clear
explanation
of
the
problem:
space
and
beginning
of
an
exploration
of
the
solution
space,
so
I
think
we
have
that.
You
know
we
we
want.
We
want
data
string
back
over
time.
Difference
dream
to
clear
explorations
into
the
solution
space.
Some
illustrative
examples,
incomplete
spec,
edits,
I,
think,
like
the
reference
implementation,
change
kind
of
serves
that
purpose,
but
really
it's
like
stage.
1
means
that
the
working
group
kind
of
agrees
that
this
is
something
that
everybody
is
excited
about.
A
Continued
work
happening
in
if
everyone
thought
like
this
is
a
crazy
thing
to
work
on
then
we'd
like
advice,
doesn't
you
to
save
your
energy
and
it
would
stay
at
zero,
but
I?
Think
everybody's
pretty
up
about
this,
so
makes
sense
to
me
to
move
this
to
stage
1
stage.
1
is
where
the
bulk
of
the
work
happens
potentially
takes
years
right,
I
mean
the
fern
stream.
We,
when
did
we
talk
about
them
in
2017,
so
yeah
you're
already
in
the
multiple
years
phase.
K
A
A
B
Yeah
a
little
bit
context
on
the
word
yeah,
who
went
that
he
wanted
to
discuss,
but
one
of
the
thing
he
create
tasks
for
student
for
Summer
of
Code
and
Horta
said
he
only
can
comment
a
nit.
So
if
somebody
else
won't
comment
in
the
resort,
so
the
task
is
about
ready
sign
in
graphical
to
torque,
like
particular
project
is
like
just
like
get
things
done
so.
B
A
Cool,
hopefully
he
can
make
it
to
one
of
the
next
ones
and
we
can
go
into
that
with
more
depth
if
it's
just
about
making
sure
we
get
Summer
of
Code
tasks.
Panned
out,
then
seems
like
we're.
Not
time
pressed
to
do
that.
Maybe
we
can
also
take
an
action
to
open
an
issue
about
this
and
work
on
it.
A
little
bit
off
line
between
meetings.
A
B
One
thing
is
kind
of
what
ice
during
discussion,
both
names
crisis,
justice,
an
idea
if
somebody
wants
to
do
it,
I
think
it
would
be
useful
to
go
through
rejected,
rejected
things
or
things
that
we
didn't
discuss
like
what
and
kind
of
create,
frequently
asked
question
why
we
don't
have
like
asterisk
being
gravel,
quarries
or
other
things,
because
people
is
the
most
popular
issue.
I
constantly
want
asterisk
and
there
is
like
multiply
it's
like
want
issue,
nobody
bothers
to
read
it
and
for
this
bunch
of
its
foundation
in
different
places.
L
L
There
is
discussion
of
them
at
the
moment
around
whether
we
potentially
do
want
to
support
scalars
in
there
or
not,
and
whether
the
output
of
the
whether
our
output
unions
and
interfaces
need
to
be
like
basically
exactly
structure
as
the
input
ones.
So,
if
you're
interested
in
that,
please
do
get
involved
in
those
discussions
in.
B
Actually,
a
termite
action
item
for
discussion.
I
just
remembered.
We
decided
that
every
proposal
should
have
a
champion
and
if
we
don't
find
like
a
champion
for
one
of
the
input,
Union
variants
with
it's
kind
of
like
who's
in
the
race,
so
yeah
and
I
said
that
the
discriminator
solution
I
need
to
work
on
rather
than
water,
but
I
would
like
try
to
find
time
and
implement
a
tree
so
expect
some
competition
and
encourage
other
people
to
read
like
a
FC
and
choose.