►
From YouTube: WG API Expression Bi-Weekly Meeting for 20200609
Description
WG API Expression Bi-Weekly Meeting for 20200609
B
I,
don't
think
we'll
talk
about
it
in
depth
here,
but
I'm
going
to
add
a
link
to
the
agenda
so
that
anybody
wants
to
follow
along
can
look
at
the
examples
for
considering
what
we
were
very
interested
in
at
a
high
level
is
what
the
expected
behavior
bunsen
in
the
field
is,
should
do
we
have
ownership
of
a
field,
for
example,
that's
required.
Should
you
actually
be
deleting
the
field
and
there's
some
kind
of
corner
cases
that
are
the
were
looking
at
so
I'll?
Add
the
link
in
just
a
moment.
C
F
A
E
E
E
A
A
B
A
E
E
E
A
A
C
E
A
E
Yeah
so
yeah
we're
thinking
about
that
because
yeah
it
sounds
like
so
if
we
can
decode
decode
the
incoming
manage
fields,
we
use
the
existing
manage
fields
and
then
we
can
empty
one
and
I
suspect.
What
we
could
be
doing
is
that
if
we
fail
to
decode
anything
in
the
incoming
manage
fields,
then
we
should
try
and
decode
the
existing
manage
fields,
trapping
the
ones
that
are
invalid.
E
F
A
E
I
mean
week
yeah.
If
it's
coming
from
the
new
object
and
it's
invalid,
we
should
try
the
existing
object
and
if
it's
in
very
handy
then
there's
not
much
that
can
be
done.
We
should
trap
the
specific
entry.
We
shouldn't
block
everything
because
okay,
otherwise
it
means
you
meant
update
the
objective.
Oh
yeah.
A
C
E
A
H
E
E
E
G
A
E
B
B
B
C
E
B
Unset
it
that
you
give
up
ownership
of
it.
So
if
you
haven't
configure,
you
basically
have
the
mo
an
object
and
there's
an
optional
field
there
and
you
just
delete
it.
It
doesn't
actually
delete
the
field
or
its
content.
It's
still
there.
It's
just
you've
given
up
ownership
of
it,
but
if
you
said
it
explicitly
to
null,
then
you
will
delete
it.
If
it's
defaulted,
then,
when
you
set
it
to
null
it'll
reset
to
the
default,
the
behavior
for
required
is
fairly
consistent
with
that.
B
If
you
unset
it,
then
you're
just
giving
up
ownership
of
it,
which
is
the
same
behavior
as
you
get
with
optional.
Now,
if
it's
complex,
then
I
seem
to
observe
different
behavior
if
I
unset
the
object
or
set
it
to
no.
Both
of
those
would
remove
the
data.
This
is
one
that
I
tested
in
a
variety
of
different
cases
and
seem
to
be
the
behavior.
If,
if,
if
it
has
required
fields
in
it,
then
this
will
often
result
in
a
validation,
error.
B
Atomic
maps
and
lists
kind
of
worked
the
way
you
would
expect
if
you're
removing
an
item
from
yours,
you're
just
changing
the
contents
of
that
thing,
so
you
just
get
that
behavior
that
was
fairly
uninteresting,
so
6,
&,
7
or
not.
That
interesting
5
was
only
mildly
and
15.
That's
the
case
where
you
have
like
an
associative
list
and
the
behavior
seems
to
be
that
if
you
remove
the
item
it
gets
removed,
but
I
know
that
there
are
special
cases
there.
B
That
I'm
not
covering
Antoine,
pointed
me
to
some
of
the
logic
and
the
updater
that
accounts
for
the
history
of
an
object.
If
it's
an
associative
list
with
you
know,
that's
not
atomic.
So
there
are
were
some
special
cases
there,
but
the
thing
I
was
most
interested
in
learning
more
and
talking
to
others
about
was
the
difference,
seeming
difference,
behavior
between
case
1,
2,
&
3,
which
seemed
consistent
and
case
for
which
seemed
to
differ
from
them.
B
G
B
Yeah
I'm
happy
to
change
the
the
wording
here
to
whatever
makes
more
sense
for
people
also
gentleman
but
yeah.
If
you
actually
look
at
the
example,
what
I'll
show
is
I'll
show
the
in
strikeout
that
the
contents
that
was
deleted
from
that
object
in
this
case
I
deleted
like
a
Holstein,
so
the
whole
resource
to
stands
us
and
the
outcome
of
that
was
that
then
enough,
I
read
it
back.
The
resources
was
an
empty
map.
Then,
if
I
said
it
to
know
the
outcome,
was
this
same?
It
was
exactly
the
same.
B
That's
what
I
expected
too,
so
that's
why
I
was
surprised
by
that
one
okay,
so
that
was
one
of
the
big
findings.
I
think
then,
the
other
big
topic
on
this
is
a
little
higher
level
which
is
do
we
feel
that
these
semantics
give
us
the
ability
to
do
everything
we
want
is
the
goal
that
there
is
always
a
way
to
both
remove
a
dative
element
and
always
a
way
to
give
up
ownership.
E
B
A
B
Yeah
I
mean
you
could
almost
like
think
of
the
possible
things
somebody
might
want
to
do
so
one
would
be
say:
I
just
don't
care
about
this
field
anymore,
I'm,
giving
up
ownership.
That's
that's
one
thing.
Another
thing
would
be
like
I
do
want
this
to
be
nolde
like
I
want
to
clear
the
field,
but
I'm
not
saying
I,
don't
own
it
anymore.
I
still
think
I
own.
B
This
whole
thing,
I,
just
I,
just
want
that
to
be
the
value
right,
I
wanted
to
be
the
the
unset
value
or
the
emitted
value,
which
is,
you
know,
has
semantics
another
and
I.
Think
Anton's
point
might
be
that
there's
a
third
there's
there's
a
third
case,
which
is
you
might
want
to
do.
Some
combination
of
those
two
things
right
like
you
might
want
to
unset
and
give
up
ownership
as
well.
Is
that
if
I
say
that
right,
Antoine,
yeah.
E
G
Yeah,
let
me
just
a
little
bit
right
so
as
soon
as
you
talk
about
somebody
get
done
in
two
steps,
I
have
to
ask
it:
what
happens
if
the
guy
that
wants
to
do
two
steps
crashes
between
the
two
right?
We
have
this
level
based
way
of
processing
things.
People
are
not
writing
controllers.
Today,
they
examine
the
managed
fields
to
figure
out
whether
they
have
to
modify
the
manage
fields.
B
Okay,
yeah
I,
think
I
think
that's
a
very
valid
point
and
then
the
one
of
the
reasons
I
started.
This
experiment
was
there
was
some
concern
from
particularly
from
users
that
we're
doing
you
know
kind
of
like.
Maybe
you
have
a
checked
in
code
or
gamal
or
something
they
were
very
concerned
with
having
behavior.
That
seemed
to
be
consistent.
If
you
performed
a
series
of
operations
and
whether
or
not
you
actually
applied
those
two
kubernetes,
this
is
the
whole
operation
or
individually
as
a
series
of
operations.
B
So
like
does
operation
a
applied
and
in
an
operation
be
applied,
have
the
same
effect
as
like
a
squash,
commit
of
and
be
applied
all
at
once,
and
so
in
that
those
kinds
of
flows
doing
things
like
the
unset
here
was
a
concern
because
you
know
if
you
instead
a
field
and
then
set
it
again
and
well
it's
it
might
have
been
that
you
intended
to.
If
you
intended
to
delete
an
optional
field,
then
the
behavior
seems
right.
If
you.
B
Think
maybe
one
way
to
rephrase
that
question
is:
should
should
the
behavior
be
swapped
where
unsetting
removes
optional
fields,
and
you
don't
have
this
way
of
giving
up
ownership,
but
then
I
mean.
Would
that
be
better?
For
me,
our
users
or
and
if
so,
then,
how
would
we?
How
would
we
allow
away
to
unsub
feels?
Does
that
make
sense?
Is
that
a
reasonable
way
to
kind
of
ask
the
question
like?
If
you
saw
somebody
remove
an
optional
field?
B
People
yeah
one
fo
to
consider
might
be
that
you've
you've
got
it.
You've
got
a
llamo
and
it
doesn't
yet
have
a
field,
and
then
somebody
adds
that
field
with
a
value
and
then
somebody
else
cuz.
No,
we
don't
want
that
in
there
and
they
just
they
just
basically
revert
that
change.
Would
the
outcome
of
that
will
be
actually
that
you,
you
added
the
field
and
took
ownership
of
it,
set
it
to
value,
and
then
you
gave
up
ownership
of
the
bill
that
it
said
to
that
value.
I.
A
Think
one
of
the
things
we
initially
Edward
least
returns
to
the
work
we
initially
advertised
with
the
new
applied
Louis.
You
only
send
what
you
want
to
change
if
things
change,
because
you
don't
send
something
anymore,
that
might
be
off
the
path
from
what
I
understood
apply
to
me,
but
we
have
to
clean
up
ownership
at
some
point.
If
you
don't
applied
so
I
see
why
that's
like
just
leaving
something
from
your
applied
manifest.
B
What
I
think
I
can
do
is
there
had
been
a
couple
I
think
I
think
the
first
point,
I
think
Anton
made
was
really
good,
which
was
number
of
the
case
number
for
here,
not
being
possible
to
unset
I.
Think
proposals,
one
alternative,
or
we
just
make
that
consistent.
So
what
I
could
do
is
list
out
a
couple
cases.
One
is
where
we
make
this
a
little
more
consistent.
B
One
is
where
we
show
the
outcome
of
the
alternative
where,
like,
if
you
just
unset
something
you're,
removing
it
and
you
lose
these
kind
of
abilities
to
give
up
ownership,
which
I
don't
actually
think
it's
a
good
case
by
itself,
because
now
you
have
no
way
to
give
up
ownership,
but
I
can
still
list
it
out
kind
of
show
that
consequences
of
that,
and
then
maybe
try
and
one
option
I'd
heard
was
you
know
how
delete
options
in
kubernetes
allows
you
to
specify
how
believe
delete
behavior
works.
Maybe
there
should
be.
G
B
A
A
E
A
E
Or
something
okay,
there's
something
interesting
to
note,
though,
is
that
we
never.
We
have
master
magic
than
we
think
we
do,
because
we're
always
processing
the
patch
the
the
applied
patch
as
a
unstructured
object,
not
a
built-in
type.
So
we
have
the
ability
to
differentiate
between
unset,
know
and
MGE
right.
E
B
B
E
B
E
B
Yeah
I,
don't
think
it
actually
works
out
in
the
structure.
If
you're
talking
about
case
number,
five
I,
don't
actually
think
it
works
out,
is
to
to
have
an
OL
anywhere
because
you
always
have
to
have
the
key
somewhere
and
then
the
rest
of
its
just
filled.
So
you
just
act
in
those
fields.
At
that
point,.
B
B
Yeah
I
mean
that's
something
I
think
we're
gonna
have
to
decide
right
like
like
we
can
clearly.
We
can
clearly
support
making
it
possible
to
remove
datum
elements
everywhere
and
clearly
you
must
have
a
way
to
do
that.
Otherwise,
the
API
is
is
going
to
be
viewed
as
incomplete
and
but
then,
whatever
semantics,
we
have
laughs,
I
think
we've
been
trying
to
use
to
give
up
ownership
and
I,
don't
know
how
to
do
five,
yet
I
think
four
is
possible.
B
Right
now,
I,
don't
know
short
of
hacking.
The
manage
fields
from
the
climate
I,
don't
think
you're
supposed
to
be
doing
I,
don't
know
of
a
way
to
do
it.
So
if
anybody
does
please
tell
me,
but
you
can
see
my
examples:
I
tried
wall,
sending
it
to
Nolan
on
setting
the
fields.
I
couldn't
I
couldn't
find
a
way
to
give
up
ownership.
E
E
B
Well,
I
think
what
we
know
about
that.
What
would
you
guys
think
of
an
alternative
where,
instead
of
having
unsetting
or
emitting
an
applied
object,
give
up
ownership
that
by
default
deleted
the
value?
And
so
then,
basically
you
you
lose
the
ability
to
give
up
ownership
by
default.
But
then
maybe
you
had
like
a
apply
options
or
something
where
you
could
do
something
different.
What
do
you
guys
think
it'll
turn
like
that?
I'm.
E
B
Basically,
you
take
in
you,
you
take
the
unset
from
how
to
give
ownership
and
move
them
over
into
you
how
to
remove
data
element,
and
so
you
lose
the
like.
You
end
up
with
a
lot
of
not
Possible's
on
how
to
give
ownership,
but
then
you
get
like
if
you
remove
an
optional
field
from
the
applied
object,
it
just
deletes
it,
which
is
you
know,
the
reverse
of
the
operation
of
adding
the
fields
right.
B
G
E
D
A
G
E
G
You're
saying
it's
a
a
it's
really
a
problem
of
mismatch
between
the
version
that
the
client
is
speaking
to
and
the
version
that
is
stored,
yeah,
okay,
valid
point.
I
was
also
going
to
raise
the
concern
that
I
think
what
is
being
suggested
is
the
opposite
of
how
Jason
merged
patchworks,
which
is
going
to
be
an
intuitive
problem
for
a
lot
of
people.
G
B
E
G
E
You
all
right
go
ahead,
I,
don't
think
we'll
really
fell
away
from
well,
we
want
to
be
but
I
I
agree.
It's
not
gonna
be
perfect.
It's
not
going
to
do
everything
we
want
so
I
I
think
we
have
to
keep
that
in
mind
that
we'll
have
to
make
sacrifices
and
and
say.
Okay,
this
use
case
is
not
perfect.
Maybe
someone
is
gonna
have
to
apply
twice
because
they
need
to
go
in
this
intermediate
state.
G
G
Well,
let
me
just
put
it
this
way
today.
The
controllers
think
you
know
the
update
operation.
Is
you
know
it's
put
right
there
they're
stating
a
level,
not
it
not
a
edge,
and
if
you
you
know
infer
under
the
covers,
you
would
first
some
levels
from
it
and
that's
not
equivalent
to
the
sorry
if
you
first
some
edges
from
it
and
that's
not
equivalent
to
the
level
that's
set,
you're
you're
kind
of
you
know
subverting
the
intent.
B
B
Because
I
think
I
think
that's
kind
of
conceptual
you're
not
trying
to
do
right,
like
what
you're
trying
to
provide
to
a
user
is,
like
you're,
you've,
seen
part
of
the
object
and
you're
trying
to
set
the
level
of
that
part
of
the
object,
I
think
at
the
highest
level.
I
think
it
still
seemed
sane
to
me.
Let.
G
Me
try
another
approach,
but
what's
really
another
view
of
what's
going
on,
is
you've
you've
really
introduced
some
additional
metadata
here,
which
is
this
ownership,
metadata,
yeah
and
right.
So
the
concern
you're
really
having
is
that
we've?
We
we
now
need
a
way
for
controllers
to
express
the
levels
of
not
only
the
data
that
they
have
been
traditionally
my
setting,
but
also
the
metadata.
So
right,
maybe
the
way
to
do
it
is
just
face
up
to
it
that
way
and
say
hey
if
the
controller
wants
to
manipulate
the
metadata.
G
B
My
naive
expectation
was
that
if
I
said
an
optional
field
to
a
value
and
then
delete
it
again,
I
hacked
my
naive
one
was
actually
that
it
would
just
you
would
actually
delete
the
value.
So
I
was
actually
expecting
something
different
for
one
two
and
three,
but
then
you
know
if
there
is
a
really
good
reason,
like
I
think
you
know
the
fact
that
these
are
version
objects,
and
you
can
still
do
that
through
null.
B
That's
I
think
starting
to
get
there,
but
then
you
run
into
problems
where,
like
you've
got
case,
number
five
like
how.
How
would
I
express
that
I
want
to
give
up
ownership
of
a
item
in
the
associative
map
or
list
I?
Don't
know
how
to
do
that.
So
it
kind
of
feels
like
yeah
it's
starting
to
by
trying
to
allow
us
to
manipulate
both
the
seen
and
the
unseen
thing
at
the
same
time
through
the
same
objects
I'm
starting
to
get
a
little
challenging.
G
Yeah
I'm,
actually
good
yeah
make
this.
You
know
statement
a
little
bit
stronger
right,
I
mean
we're
we're
talking.
Http
right,
there's
is
we're
kind
of
trying
to
be
arrests
here.
Right
foot
says
I'm
supplying
the
the
state
the
level
right.
If
you
take
the
level
that
I
supply
infer
some
edges
and
the
net
effect
is
different
from
the
state
that
I
sent
I'm
gonna
be
offended.
G
E
A
If
we're
talking
about
controllers
and
they
want
to
explicitly
ownership-
and
they
can't
do
it
through
apply,
they
can
still
issue
a
patch
of
either
manipulate
either
an
update
which
is
put
to
change
the
managed
fields
or
do
what
they
want.
They're
I
think
focus
for
me
when,
when,
when
we
start
discussing,
this
was
the
actual,
a
user
and
not
controllers,
but
we
have
to
think
about
controls
as
well.
G
A
B
Well,
I
think
we're
out
of
time
so
I'm.
What
I'll
do
is
I'll
continue
to
break
out
the
possible
alternatives
that
we've
discussed
so
far
and
start
listing
out
all
the
problems
that
we've
hit
with
them
and
maybe
I'll
try
and
grab
a
couple
people
later
this
week
and
see
if
we
can
hammer
over
and
see
see
what
alternatives
are
left
and
how
we
can
make
the
best
of
them.