►
From YouTube: Incremental Delivery Working Group - 2023-04-24
Description
GraphQL is a query language for APIs and a runtime for fulfilling those queries with your existing data. GraphQL provides a complete and understandable description of the data in your API, gives clients the power to ask for exactly what they need and nothing more, makes it easier to evolve APIs over time, and enables powerful developer tools. Get Started Here: https://graphql.org/
A
B
D
C
Okay,
yeah
I
haven't,
haven't
seen
that.
Did
you
see
the
changes
that
that
I
sent
you.
D
Yeah
yeah,
you
know
your
the
conversation
and
those
changes
are
very
helpful.
I
I
tried
to
put
as
much
as
I
could
into
collect
Fields.
D
E
You
know
I
mean
I
know
why?
Because.
D
It
hasn't
I
haven't
completely
done
everything
that
needs
to
be
done.
I'm.
D
Working
but
but
it's
coming
along.
B
So
it's
it's
like
just
to
qualify,
uspr
that
you
did
it's
it's
the
one
that
keep
everything
current
behavior,
but
it
do
it
without
branching
and
with
the
duplication
of
execution
right.
It's
not
like
bangerous
proposal
or
crops
proposal,
it's
like
time
as
previous
pair,
but
you
create
alternative
version
of
your
previous
pair.
D
Well,
actually,
I
think.
Thank
you.
Pretty
much
is
similar
to
Rob
and
Benji's
proposal
in
the
sense
that
it,
you
know,
Rob
showed
me
a
thing
or
two.
You
know
and
clarified
a
lot
which
got
clarified
a
lot
and
I
think
it's
pretty
similar,
meaning
it's
going
to
emit
unique
like
sort
of
sub.
You
know
fragments
of
the
Deferred
fragments
and
with
with
with.
D
E
B
Okay,
can
you
update
description
because
I
was
confused
what
what
I
was
soaking
on?
Also,
what
what's
is
CF
UCF,
as
abbreviation
before
your
reference
right
there?
What
CF
means.
B
C
All
right,
yeah,
so
I
guess
just
to
update
where
we're
at.
We
have
that
proposal
from
me
and
Benji
that
we
talked
about
last
week.
C
Since
then,
there
were
like
a
few
minor
changes
that
I
made
I
I'm,
not
sure
that
Matt
has
seen
the
proposal
and
I
would
like
to
get
his
feedback
on
it.
So
maybe
I'll
quickly
go
through
a
few
of
the
examples
now
and
I'll
show
what
changed
and
then
yeah
and
and
Jacob
and
I
have
both
been
working
on
implementation
details,
but
yeah
I
think
we're
making
good
progress.
A
E
C
Right
yeah,
so
so
the
basic
the
basic
idea
is
that
we
only
ever
both
execute
and
deliver
a
field
once
so
here.
In
this
example,
everything
that's
that's
overlapping
from
the
initial
payload.
That's
going
to
be
in
the
initial
data
response.
We
have
a
pending
array
that
tells
you
a
path.
The
path
will
point
to
where
the
defer
is
and
the
label.
If
there
is
one
the
labels
don't
affect
execution
anyway,
they're
just
purely
informational
and
they're
optional.
C
So
only
if
they're
provided
you'll
you'll
get
it
here
and
now
we
have,
there
could
be
many
objects
in
incremental
for
one
defer
a
payload,
but
they
will
all
be
delivered.
C
They'll
only
be
delivered
once
there's
enough
to
satisfy
one
entire
defer,
and
the
incremental
has
an
idea
that
points
to
the
pending,
and
this
doesn't
necessarily
mean
that
this
field
is
completely
associated
with
this
ID,
because
there
could
be
overlap
it
could.
It
could
belong
to
many
deferrs.
So
the
idea
that's
used
is
whichever
one
has
the
longest
path
and
then
there's
a
subpath
which
is
based
on
whatever
the
pending
path.
C
Is
it's
more
levels
deep
to
get
into
there,
because
here
all
of
the
intermediary
Fields
were
already
sent
in
the
initial
payload.
Now
we
have
to
we're
only
sending
these
fields
that
this
is
like
the
intersection
of
what
wasn't
overlapping
with
the
initial
payload,
and
so
the
subpath
points
down
further
into
the
response,
with
the
with
the
fields
that
are
sent
there
if
new
deferrs
are
discovered,
while
it's
being
executed,
you'll
get
more
pendings
and
then
there's
a
completed
to
tell
you
an
ID
when
of
which
ones
are
completed.
C
Yeah.
Here's
like
a
slightly
simpler
example
where
all
these
are
duplicated,
between
the
defer
and
not
being
in
the
defer,
I
and
J
are
the
only
differences,
so
I
Ascend
in
the
initial
payload,
and
now
we
have
the
defer
it's
at
the
root.
So
that
is
the
empty
array
and
now
there's
two
data
fields
that
are
sent.
C
This
one
doesn't
have
a
subpath,
because
this
field
is
at
the
the
root
and
this
one
does
that
points
down
into
F2
CF,
with
the
J
response.
A
F
And
then
just
a
quick
I
want
to
introduce
Sabrina
who's,
my
teammate,
who
is
likely
to
spend
more
time
on
the
first
stream,
like
she
does
actual
diverse
stream
stuff
on
my
team.
Everyone.
So,
if
possible,
I'd
like
her
to
join
these
meetings
and
probably
will
actually
be
here
weekly,
whereas
I
mostly
can't
be
I'm.
Like
sorry,
yeah.
C
Yeah,
if
you
just
send
me
over
your
email
address
and
we
can
go
to
on
Discord
and
in
the
on
the
calendar,
invite.
C
Yeah
so
so,
this
next
example
is
there's
two
defers
here
at
different
levels
and
there's
some
combination
of
fields
overlapping
between
them,
notably
E
and
F,
is
both
is
inside.
Both
of
these
differs
not
inside
the
initial
response,
and
then
we
have
these
two
fields
which
we're
saying
we
don't
know
which
one's
going
to
complete
first
and
there's
a
few
more
fields
on
this
one.
C
So
here's
the
scenario
where
this
one
completes
first,
so
we
have
in
the
we
have
the
two
pendings
that
correspond
to
the
two
defers
there's
the
now.
These
are
sent
in
separate
incremental
objects,
but
they're
sent
together
as
soon
as
the
slower
field
is
completed.
Now
we
know
we
have
the
data
for
enf.
We
have
the
data
for
this.
C
That
completes
one
whole
defer,
so
they're
sent
together
and
that
that
corresponding
ID
is
marked
as
completed,
and
when
this
other
field
is
ready
that
sends
here
and
the
logic
that
we're
using.
So
you
know
how
to
split
them.
Up
is
like
whatever
fields
are
completely
overlap
and
diverse,
are
can
be
sent
together
so
because
GH
and
potentially
slow
field
B
are
not
in
any
other
deferest.
This
can
be
sent
in
one
incremental.
C
Enf
is
always
going
to
be
sent
in
its
own
because
it
overlaps
here,
and
this
is
always
going
to
be
sent
in
its
own,
and
so
then
you
could
see
in
the
same
example
where
they
complete
in
the
where
this
one
completes
later.
It's
we
have
all
of
the
same
incremental
objects.
They're
just
sent
in
a
different
order.
Now
here
like
this,
one
is
sent
in
the
first
payload,
along
with
enf
that's
more
completed
and
when
slow
field
a
is
ready
in
that
sense,
and
this
other
one
is
more
completed.
C
C
Yeah
one
one
case
where
it
might
get
a
little
confusing
is
there's
two
differences
here
list
and
item
bulk
overlap.
Id
and
value
are
different,
and
so
we
can
we'll
send
one
payload
that
has
listed
item
in
it
and
other
other
objects
that
have
the
ID
and
value
and
depending
on
which
one
is
ready.
First,
that's
when
you'll
one
of
these
will
be
marked
complete,
but
as
we're
traversing
down
once
we
like
listens
in
the
they're,
both
overlap,
so
that's
executed
together.
C
Item
same
same
thing
is
executed
together,
but
when
we
get
to
ID
and
value
now
we
know
that,
like
when
ID
is
being
executed,
it
doesn't
match
what
was
in
the
parent,
so
it
has
to
break
off
into
its
own
object.
F
Question
I'm
sure
you've
already
litigated.
This
is
why
use
the
subpath
instead
of
like
just
resending
the
path
as
a
set
of
objects.
C
I
think
it
was
just
just
to
why
send
this
up
path
instead
of
sending
the
objects
inside
of
data
again
is.
F
That
the
question
so
right,
because
at
least
in
this
case,
like
it
I
guess,
if
you're
in
one
element
inside
of
a
list,
you
have
to
figure
out
how
to
have
that
specific
list
element
but
like
in
this
case
you
it
would
be
less
pale
like
less.
It
would
be
a
lot
less
data
sent
if
it
was
just
data
list,
item
items
and
then
the
list
of
you
know
one
two,
three
or
whatever.
D
F
D
So
what
one
of
the
constraints
that
we
were
talking
about
was
that
that
whether
each
item
requires
a
simple
merge
rather
than
a
rather
than
a
deep
merge.
So
in
order
to
do
that,
you
you
you
end
up
with
a
lot
of
repetition.
D
I
I
suggested
on
the
the
Discord
chat
one
way
to
avoid
that,
but
this
is
I,
guess
the
naive
and
now
you've,
you
know
approach.
You
know
which
works.
C
Yeah,
the
trade-off
was
specifically
like
not
having
clients
do
having
to
do
deep,
merges.
C
Yeah,
if
there's
no
fields
in
your
defer,
it's
it's
just
going
to
be
ignored
completely
like
this
example
and
we're
not
doing,
we
had
talked
about
merging
defers
with
either
the
same
label
or
at
the
same
path.
We're
not
doing
any
of
that
anymore,
because
there
isn't
the
opportunity
for
the
response
to
be
Amplified
like
it
was
with
the
previous
iteration.
C
So
we
have
the
labels
and
there
it's
only.
The
fields
that
are
inside
the
same
differ
are
grouped
together
and
will
be
held
up
for
each
other.
C
This
one
I
feel
like
might
be
the
most
I,
don't
know
it
the
the
thing
that
might
be
most
surprising
to
people
and
it's
with
no
bubbling.
So
what
happens
if
you
send
a
field?
And
now
another
field
that's
being
executed
later,
should
null
should
bubble
to
null
out
that
field.
C
So
what
what
we're
saying
is
going
to
happen?
So
here's
the
example
we're
saying
that
baz
resolves
before
glucks,
but
what's
is
non-nullable
and
returns
null.
So
if
there
were
no
deferes
here,
you
should
get
back.
Fu,
Me
Foo
with
another
another
field,
but
bar
would
be
null
because
this
one
nulled
out
and
bubbled
up.
But
here
that's
we're,
saying
bad
as
finishes
first,
so
we're
sending
this
payload
that
has
Fubar
and
bass
in
it.
C
But
now
we
can't
go
back
and
we
don't
want
to
go
back
and
all
this
out,
so
we're
going
to
basically
say
that
this
whole
fragment
can
be
delivered
because
we
don't
want
to
overwrite
a
field
that
was
sent
previously,
so
you'll
get
just
the
ID
and
the
data
being
null
on
the
errors
and
that
it
was
completed.
C
So
that
basically
means
that
this
another
field
is
getting
lost.
Now
it's
not
equivalent
to
they're
not
being
deferred
there,
but
I
think
that
have
that's
the
best
alternative
that
we've
come
up
with.
F
And
I
I
assume
you
guys
have
already
thought
through
the
like,
treating
it
the
same
as
a
normal
payload,
where
you
just
in
this
payload
bar
is
null,
but
another
field.
Is
there
and
there's
an
errors
array.
C
Yeah
I
mean
we
didn't
want
like
this.
Payload
is
I
mean
this,
like
response
is
based
on
not
sending
the
objects
twice
so
bar
is
already
sent
and
so
like.
We
could
send
it
again
and
I
guess,
leave
it
up
to
the
clients
if
they
want
to
ignore
it
on
their
end
or
takes
data
that
was
already
rendered
and
remove
it,
but
that
taking
data
and
removing
it
sounds
bad.
So
I
think
we're
doing
the
work
that
the
clients
we're
expecting
the
clients
would
do
anyway.
C
C
C
C
But
then
it
gets
confusing
when
you
have
the
subpath
and
then
so
we
just
the
rule
is
just
going
to
be
that
whichever
one
is
the
longest,
that's
what
we're
going
to
use
for
the
IDS
to
minimize
what
goes
in
the
subpath,
but
but
really
it's
the
pending
and
completed.
That's
like
the
metadata
to
tell
you
like,
what's
being
executed
and
what's
done,
and
the
ID
inside
incremental
is
really
just
a
shortcut
to
avoid
repeating
the
longer
paths.
C
Yeah,
so
it
seemed
like
most
people
that
we
talked
to
so
far
are
on
board,
with
this
I
I
would
love
to
hear
from
Matt
or
anyone
from
Facebook
has
concerned.
Concerns
about
it
all
right,
because
I
know
that
it's
pretty
different
from
what
you
guys
have
implemented.
F
Yeah,
the
the
trade-off
to
me
seems
like
we
get
client
mutable
like
we
get
local
component
mutable
state
at
the
expense
of
a
lot
of
network
redundancy
right,
whereas
if
we
and
you
get
that
state
updating,
basically
as
quickly
as
humanly
as
quickly
as
could
be
done
right,
you,
you
basically
never
block
for
any
thing
that
you
might
end
up
accidentally
blocking
on
I.
Do
Wonder
given
like
in
the
P90
or
like
in
the
most
common
cases,
whether
the
duplication
of
IDs
and
paths
and
whatnot.
This
might
just
maybe
I
need
to.
F
Maybe
somebody
needs
to
me.
Somebody
I,
don't
know,
needs
to
like
do
the
payload
size
analysis,
but
there's
basically
I,
don't
know
if
response
it,
if
we're
approaching
the
same
response
size
as
just
having
duplicate
like
full
duplicated
response
objects
for
all,
so
we
we
know
that
Foo
will
only
be
executed
once
and
then
on
the
server.
You
basically
have
to
have
a
like
execution
like
yes,
this
was
already
resolved,
we're
not
resolving
it
again
map.
F
If
we
can
shrink
the
size
of
the
incremental
payloads
to
just
be
basically
the
singular
path
from
root
or
path
from
wherever,
even
just
ID
I
don't
know
and
not
have
the
sub
path
and
not
end
up
ever
having
like
ID
one
multiple
times.
Basically,
when
you
get
an
ID,
it
means
it
is
completed,
or
at
least
that,
like
portion
up
until
the
next
defer
is
completed,
but
I
don't
know
like.
F
That
would
be
my
because
this
is
certainly
the
other
thing
is
I'm,
not
confident
that,
like
I'm
in
the
middle
of
trying
to
figure
out
a
very
simple
open
source,
compatible,
client
and
I'm,
not
sure
that,
like
how
I
would
actually
represent
this
on
the
client
is
merging
versus,
read
throughs
so
like
when
I
hit
the
me
field
now,
I
go
look
at
some.
Basically,
these
pending
payloads
and
just
read
them
as
they
come,
in
which
case
having
fewer
of
the
pending
payloads
sent,
would
be
or
like
having
a
clearer
pointer
to
those
pending.
F
It's
yeah,
all,
that
is
to
say
it's
like
it.
It's
right
now,
if
I'm
the
client,
what
I
have
to
do
is
look
up.
So
as
I'm
walking,
the
tree,
I
hit
some
deferred
field
and
I
have
to
be
walking
my
my
pendings,
my
pending
Fields
as
well
right
so
I'm
on
me,
I
I'm,
not
sure
how
I
would
on
the
client
walk
the
pending
array
to
know
what
I'm
missing.
F
Versus
I'd
be
tempted,
like
the
data
might
only
to
be
there,
but
I'd
be
tempted
to
turn
the
pending
array
into
a
tree
itself.
But
I,
don't
know
I,
don't
know.
If
that's
a
good
idea.
A
F
F
My
client
should
know
that,
because
there
is
that
ad
to
fur
or
whatever,
but
like
I
I,
basically
need
to
have
a
pointer
in
that
defer
at
that
point
of
what
the
path
is
and
the
way
that
the
pending
payloads
work
right
now,
I
have
to
go
through
every
single
pending
payload
in
order
to
find
the
one
that
corresponds
to
the
ID
that
I'm
at
right
now,
whereas
like
if
I
know
that
I'm
like
if
there's
a
pending
tree
or
something
instead
of
like
a
list
of
pending
payloads
I,
would
be
able
to
basically
be
walking
at
the
same
time
both
the
pending
tree
and
the
data
or
like
from
the
path.
F
It
basically
turns
the
lookup
cost
into
a
login
instead
of
linear,
but
I'm,
not
I'm,
not
confident
that
that's
even
like.
F
A
F
Especially
because
I
would
expect,
if
you
had,
you
might
have
a
hundred
defers
if
you
have
like
a
long
list
or
something
but
they're
going
to
be
probably
nested
and
nested
within
each
other.
So
right,
I
I
would
be
surprised.
Also,
if
you
have
that
you
probably
should
be
using
stream
instead,
yeah
so
yeah.
E
F
C
No,
it's
interesting
to
think
about
if
you,
like,
think
of
like
a
way
to
represent
it.
Definitely
let
me
know,
and
we
can
consider
it.
F
Is
the
the
right?
The
question
then
becomes
like
part
of
the
point
of
having
fewer
like
allowing
us
to
merge
the
data
or
having
like
fewer
deduplicating.
The
data
is
that
one
you
can
use
it
quicker
and
two:
you
can
your
response.
Your
overall
response
size
goes
down
and
I'm,
not
yet
convinced
that
the
second,
the
first
is
definitely
true
with
this,
which
is
good
I'm,
not
true.
The
second
is
I'm,
not
confident.
The
second
is
true
in
like
the
normal
case,
but
I'm
also
not
confident
that
that
matters
too
much.
C
F
A
C
Especially
the
concern
about
duplication
in
the
response
size
is
the
case
of
like
public
graphql
servers
where
the
client
may
be
acting
maliciously,
and
it
definitely
is
easy
to.
If,
if
every
for
every
defer,
you're
getting
all
the
data,
then
it's
definitely
easy
to
yeah.
Get
like
a
very
large
response.
F
C
Yeah
the
way
that
this
algorithm
works
works
now
it's.
C
It's
it's
basically,
each
one
of
these
objects
it
that
it
creates
they're
they're
their
own
execution,
pretty
much.
So
it's
like
doing
execute
fields
for
this
group
of
objects.
For
this
group,
for
this
group
Yakov
solution
that
that
did
they
did
that
like
reassembled,
that
it
would
have
it
had
like
another
step
that,
after
doing,
that
would
reassemble
them
back
into
the
the
shape
that
matches
the
defer
more
closely,
and
so
so
it's
doable,
but.
D
So
so,
but
we
could
we
could
so
some.
D
So
basically,
I
was
looking
at
how
some
of
some
of
the
results
in
the
incremental
array
also
might
be
better
represented
as
a
tree
and
I
posted
in
the
in
the
chat,
a
suggestion
that
you
know
we
could
sort
of
Mark
the
divider
between
the
subpass
and
the
data,
with
kind
of
a
special
character,
I
thought.
Initially,
we
could
just
use
a
double
underscore,
but
Benji
pointed
out:
that's
actually
valid
for
an
alias,
so
that
actually
might
show
up
in
the
past.
D
But
if
we
allowed
like
another
special
character,
like
the
plus
sign
you
know
we
could.
We
could
basically
have
a
marker
between
where,
in
the
incremental
array,
where
we
could
sort
of
condense,
some
of
those
and
that
same
basic
approach
of
using
a
special
character,
if
I
understand
correctly,
might
help
some
of
what
what
you're
talking
about
Matt
in
terms
of
the
pending
array,
meaning
we
could
have
a
a
list
of
potentially
of
of
sort
of
merged,
f
and
sort
of
have
a
marker
to
to
identify
you
know
to
to.
D
F
Yeah
I'm
yeah,
that
makes
sense.
C
Yeah,
it's
just
that
I
feel
like
putting
metadata
inside
of
data,
even
if
it's
only
in
the
new
incremental
incremental
payloads
could
be
very
controversial
and,
like
I'm,
not
saying
that's,
not
the
reason
to
do
it,
but
I
feel
like.
We
need,
like
a
really
solid
reason
for
doing
so
that
everyone
that
there
isn't
like
objection
to
it.
You
know.
D
Yeah
I
mean
it's
also
true
that
this
is
basically
just
you
know.
It's
basically
just
a
different
serialization
of
the
same
information,
so
to
speak
to
condense
data,
make
things
a
little
bit
easier,
and
so
it
you
know
it
it
it
it.
D
C
Yeah,
anyway,
for
as
far
as
next
steps,
I
think
that
I
want
to
present
this
at
the
next
working
group,
which
I
think
is
in
two
weeks.
F
F
All
if
you
I
assume
this
link
is
in
the
Discord
perfect.
F
And
and
I'll
make
sure
to
get
Sabrina's,
email
and
Discord
to
you.
D
Rabbit
at
the
last
meeting
I
had
to
drop,
did,
did
you
cut
or
did
the
group
come
to
a
conclusion
about
whether
the
spec
text
and
slash
or
the
implementation
should
allow
early
execution
or
early
initiation
of
execution
of
deferred
payloads
yeah
I
mean
you
mean
that
delivery
is
definitely
deferred,
but
was
it
just,
you
know,
decided
one
way
or
the
other
about
allowing
the
execution
to
begin
earlier?.
C
Yeah
so
Benji
brought
up
his
thoughts
were
that
we
shouldn't
even
begin
to
start
executing
any
deferred
Fields
until
all
of
the
non-deferred
fields
or
fields
from
a
higher
up
defer
are
completed,
and
that
does
simplify
the
spec
and
he
mentioned
like
if
you
have
a
queue
of
database,
connect,
queries
and
there's
a
there's.
C
The
possibility
that
your
deferred
data
could
be
slowing
down
your
non-deferred
data,
but
I
think
that
I
I
also
brought
up
but
I
I
think
it
could
also
be
dangerous
to
drastically
extend
the
amount
of
time
that
it
takes
a
request
to
complete.
So.
E
F
I
definitely
do
not
think
we
should
like
this.
I
have
a
strong
opinion
on,
which
is
that
you
should
not
over.
It
may
be
the
case
that
you
should
require,
like
the
Deferred
payloads
coming
separately,
but
specifying
the
order
that
the
server
execute
like
results
runs.
The
resolvers
I
think
is
not
a
great
path,
because
servers
like
essentially
the
deferrer
is
its
own
resolver.
E
C
Does
a
spec
say
that
it
doesn't
start
executing
until
later,
but
make
a
note
that
you
could
do
it
earlier
or
does
it
do
you
write
the
spec
as
if
it's
executing
right
away
but
say
that
you
could
delay
it,
and
so
my
the
the
spectacs
is
simpler.
If
you
wait,
if
you
so,
my
argument
was
that
we
should
do
it
the
other
way
where
it
executes
right
away.
C
So
this
way
we
can
also
have
the
logic
that
says
that
if
a
sibling
field
nulls
up
that,
if
a
sibling
in
the
initial
payload
nulls
up
and
that
wipes
out
where
your
defer
is,
but
you
actually
already
started
executing
it
you
should
we
could
write
the
function
that
says
to
make
sure
that
that
gets
canceled
instead
of
like
just
saying
you
can
do
it
earlier,
but
it's,
but
it's
not
really
documented.
Like
what
other
steps
you
have
to
take
to
make
sure
that
you
don't
send
invalid
stuff.
E
F
Oh
sorry,
yeah
I,
don't
know
if
that's
super
important
one
way
or
the
other,
but
like
rather
the
canceling
mechanism
like.
C
Yeah,
that
was
an
issue
that
we
had
talked
about
sometime
last
year,
I
think
yeah
and
we
didn't
want
just.
We
said
we
didn't
want
the
server
to
send
a
payload
that
points
to
that
has
a
path
that
doesn't
exist
in
the
tree,
which
would
happen
if
a
sibling
null
bubbles
up
so.
F
F
C
Yeah
when
I
say
sibling,
I
don't
mean
a
sibling
defer.
I
guess
I
mean
a
sibling
field,
that's
outside
of
the
defer,
so
I
guess:
oh
sibling
field
in
the
initial
payload.
E
C
Yeah
so
let's
say
that
D
that,
like
you,
you
start
executing
B.
This
is
deferred.
This
also
starts
getting
executed.
C
C
Yeah
I
think
most
people
agree
on
that,
but
maybe,
if
Benji
once
we
can
discuss
it
at
another
working
group
later
on,
but
I'm
going
to
go
forward
with
that
assumption.
C
As
far
as
far
as
the
implementation,
I
I
did
some
rough
changes
to
yako's
previous
implementation.
That
gets
us
I,
think
pretty
close
to.
What's
here
and
I.
Think
yaakov
has
been
working
on
a
more
optimal
version
of
that
I
I'm,
not
sure
that
if
we
should
spend
the
time
to
merge
the
changes
that
give
you
the.
If,
if
we're
leaning
in
this
direction,
I
don't
know
if
it
makes
sense
to
merge
the
changes
that
give
us
what
we
have
on
Main.
B
So
if
you
compare
like
PRS,
they
like
they
like
second
pairs
like
proposal
Behavior,
it
remove
stuff
change,
stuff
or
add
stuff.
C
Yeah
I
think
so
we
have
on
Main.
Now
we
have,
everything
is
duplicated
right.
We
have
yaakov's,
PR,
which
is
response
is
duplicated.
Execution
is
not
deduplicated
and
we
have
hypothetical
PR
that
completely
implements
this
I
think
that
this
one
is
a
smaller
change
than
the
one
that
does
only
an
execution
deduplication
but
keeps
the
response,
duplication.
B
Okay,
yeah,
in
that
case,
it
makes
sense
to
give
it
a
shot
on
next
working
group,
mind
working
group,
a
fabric
exists,
agree
kind
of
we
get
like
a
fast
path.
If
not,
we
still
have
yakub,
PR
and
I
think
what
a
proposed
solution
like
that
yeah
on.
B
If
next
work
can
group
like
we
see
with
proposals
away
forward,
it
makes
sense
to
a
Polish
it
or
match
it
right
away.
If
not
I,
think
we
need
to
update
what
we
have
on
Main
to
have
a
international
process
for
people
to
see
and
how
I
can
buy
swine
and
move
base.
One
a
little
bit.
C
Yeah
makes
sense.
The
difference
is
that
between
this
and
keeping
and
is
I,
think
both
PRS
do
roughly
the
same.
Both
approaches
do
roughly
the
same
amount
of
work
in
how
they
execute
things.
C
The
step
that
maintains
the
output
that
we
have
now
has
to
do
another
step
of
assembling
these
incremental
objects
that
were
executed
separately
back
into
the
shape
that
matches
what
we
have.
So
that's
like
the
extra
code
that
I
that
wouldn't
be
fully
necessary.
If
we
went
straight
to
this
proposal,.
D
Yeah
I
mean
Rob
from
my
end
from
my
point
of
view,
because
we're
making
I
think
such
rapid
progress,
hopefully
right.
D
You
know
it
may
not
pay
to
merge
it
like.
If
it
was
taking
up
a
long
time,
then
then
yeah,
then
it
would
be
nice
to
have
something
like
as
a
reference.
But
the
thing
is
we're
hopefully
making
such
rapid
progress.
You
know
no
I
I
would
agree
with
you
that
we
can
just
hold
off.
B
B
Game
plan
so,
like
you,
will
do
review
The
Joint
presentation
with
battery
like
last
time
or
or
like
so
we
should
write
next
working
group
will
have
a
sword
for,
for
which
topic
right.
B
Yeah
I
think,
like
one
thing
we
want
to
prevent,
is
is
like
situation
where
Lee
or
like
like
working
group
without
attendees.
B
So
if
we
had
that
last
minute
or
like
in
a
day
or
two
people
like
some
people
wouldn't
show
show
up
and
it
will
create
their
situation
where
technically
we
discuss
it,
but
practically
it's
the
same
people
as
we
have
here,
and
there
is
no
like
why
discussion
submitting
right
now,
it
will
give
it's
it's
it
put
like
it,
make
it
more
serious
and
people
put
it
in
the
calendar
that
they
need
to
show
up
to
to
discuss.
B
Also
Kevin
like
some
some,
you
created
a
good
document
having
it
upfront
you
will
have,
it
will
give
people
a
chance
to
you.
You
cannot
maybe
it's
that
it's
not
the
like
final
draft
of
what
will
be
presented
there.
I
expect,
like
some
Evolution
happening.
You
know
agriculture,
but
at
least
people
who
have
like
by
swipe
and
confirm
the
opinion.
C
Yeah
so
I'll
put
it
on
the
agenda
today.
I'll
I'll
say
that,
like
we
want
to
just
I'll
put
right
in
the
agenda
like
we
want,
like
we've
like
been
iterating
on
this
duplication
issue,
when
we
want
to
this
new
direction
that
we're
mostly
agreed
on,
we
want
to
get
feedback
and
I'll
link.
I'll
put
this
document
in
there
too,
and
I'll
get
that
all
up
today.
So
hopefully.
F
E
C
All
right,
so
that's
all
I
have
for
now
yeah
and
we
do
have
another
meeting
next
Monday
which
is
before
that
working
group.
So
we
can
iterate
more
if
we
need
to,
but
so
yeah
hopefully
I'll
see
you
all.
Then.