►
From YouTube: WG API Expression Bi-Weekly Meeting for 20210427
Description
WG API Expression Bi-Weekly Meeting for 20210427
C
C
D
Yeah
good
question:
they
can
maybe
and
that's
terrible
they
can
maybe
set
all
the
other
fields
to
know.
Okay,
but
that's
far
from
perfect,
I
agree
today.
That's
probably
the
only
option
you
have,
but
it's
not
very
different.
For
I
mean
I
think
the
the
prime
was
similar
if
you
were
using
client-side
apply
or
any
other
types
of
apply
right.
You
had
to
clean
up
the
the
thing
for
other
people
even
before
client-side
apply
or
even
without
server-side
advisor.
D
So
even
if
you
were
sending
a
patch
just
set
these
field,
this
is
the
one
I
want.
You
had
to
clear
all
the
other
fields.
The
problem
with
service.
Is
that
you're
not
supposed
to
look
at
the
objects,
so
you
don't
know
what
needs
to
be
cleared.
So
you
sort
of
have
to
clear
everything,
including
things
that
you
don't
even
know
yet
if
they
exist,
so
that
the
experience
is
not
great.
D
Here's
where
I'm
going.
We
have
a
specific
task
in
the
document
to
solve
server
side
apply
to
solve
unions,
one
of
the
ones
and
it's
very
easy
to
solve,
with
server
side
apply,
because
when
you
set
exactly
one
window,
that's
the
one
you
want
and
we
should
clear
all
the
others.
It's
not
that
easy.
When
it's
in
patch.
C
D
Yes,
we
don't
have
a
good
semantic
right
now
to
say
this
is
a
union,
so
our
side
of
why
doesn't
even
know
that
it's
a
union,
we
don't
know
what
a
union
is
right.
The
only
way
we
know
what
unions
are
today
is
because
it's
written
in
the
comments
that
says
we
should
have
this
all
that,
oh,
we
should
have
at
most.
One
of
these
fields
said,
but
obviously
we
don't
pass
comments,
at
least
not
the
the
ones
written.
C
D
A
B
D
D
Kind
of
yeah,
so
we
have
so
first
of
all
for
built-in
types
we
don't
use
the
open
api
v3.
We
only
usb
2.
v2
doesn't
have
the
one
of
the
field,
so
there's
no
way
in
v2
to
say
this
is
a
one-off
first
of
all
and
we
use
it
for
client-side,
but
we
for
crds,
sorry,
but
it's
it's
very
hard
to
extract
the
right
information.
D
This
has
a
lot
of
complexity,
with
maintaining
backwards,
compatibility
and
again
trying
to
guess
what
people
are
trying
to
do,
and
so
we've
done.
We've
spent
a
lot
of
time
trying
to
see
how
we
could
guess
what
people
want
to
do
and
we
kind
of
fell
short
doing
that.
On
the
other
hand,
what
we
don't
have
is
a
good
recommendation
for
people
writing
types
that
may
have
a
one-off
later.
C
D
C
D
A
C
Okay,
this
one
it
just.
We
don't
need
to
go
details
in
this
machine.
I
just
wanna,
see
we'll
give
you
guys
a
update
about
my
next
step.
So
I
revisit
this
topic
again
recently
and
I
found
two
previously
kept
attempts
one
is
from
antoine.
The
other
is
from
sofia,
so
I
there
are
some
good
conversations
in
those
original
caps,
so
I
captured
some
use
cases
from
those
those
original
caps
and
but
I
I
also
see
there
the
base
on
those
use
case.
C
Should
we
support
it
as
a
part
of
the
immutability
check.
One
critical
example
is
that
it's
continuous
someone
thinks
okay,
we
shouldn't
support
that.
It's
not
a
it's
a
general
validation,
it
shouldn't
be
a
part
of
the
immutability,
but
someone
think
we
should
support
it.
The
complex
case
that
you,
you
can
keep
the
keys,
but
you
can
change
the
value
for
the
keys
things
like
that,
so
I'm
gonna
click.
This
is
my
approach.
C
I'm
gonna
collect
those
use
cases
and
do
an
evaluation
first
and
let's
draw
some
assumptions
or
conclusions
to
see
okay,
which
one
we're
going
to
support
generically.
Then
we
work
from
work
to
design
from
here.
Otherwise,
if
the
desire
is
just
gonna
explode
too
many
videos
and
then
we
cannot
get
a
clean
solution
so
yeah.
This
is
my
plan
and
my
next
step.
Let's
just
give
an
update
when
you
don't
need
to
do
the
evaluation
here.
D
You,
I
think
it's
a
good
plan,
I'm
saying
general:
let's
do
the
right
thing
for
the
future
types
rather
than
trying
to
solve
all
the
plans
we
have
with
existing
types,
because
existing
types
work
already
anyway,
so
we
don't
definitely
desperately
need
it
for
them.
But
let's
do
the
right
thing
for
people
who
write
new
types
in
the
future:
okay,
yeah!
That's
a
good
strategy.
C
A
A
A
A
D
D
A
D
D
A
A
D
C
A
D
A
A
A
D
D
D
D
A
D
A
D
C
D
C
A
A
D
A
The
thing
is
the
the
thing
I
I
it
could
be
more
complicated,
more
controversial
is
be.
What
we
talked
about
for
cuba,
city
generate
would
be
some
kind
of
templating
in
the
examples
that
we
would
or
examples
are
a
map,
so
we
can
have
more
of
them,
but
the
end
goal
would
be
to
have
some
kind
of
templating
that
you
can
provide
parameters
to
cubesat
generate,
and
it
knows
where
to
put
that
stuff.
So
that
could
be
the
harder
part
if
we
want
to
make
that
a
part
of
it
already
yeah
different.