►
From YouTube: WG Component Standard Office Hours 20200623
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,
good
morning,
everyone
welcome
to
the
tuesday
june
23rd
2020
working
group
component
standard
office
hours.
This
is
our
hour
for
folks
to
drop
in
and
ask
questions.
I'm
mike
taffen
and
I'll
be
hanging
out
in
the
channel.
A
Doing
well,
your
sound
is
a
little
bit
like
low.
A
Better
yeah,
okay,
okay,
so
you
had
some
questions
on
the
prototype
that
you
sent
over.
A
B
B
A
Yeah,
that's
one
way
to
do
it.
I
think
it's
what's
tricky.
Is
we
have
this
convention
of
like
not
using
pointers
on
the
internal
types
so
that
they
always
have
a
value
so
that
the
runtime
doesn't
have
to
do
no
pointer
checks
once
it's
converted
to
the
internal
so
yeah?
So
I
I
have
to
think
about
how
to
do
this.
A
A
Well,
let's
see,
no,
that's
not
when
defaulting
happens
that
would
only
work
for
the
flags.
I
was
trying
to
think
if
we
could
somehow
start
with
a
defaulted
object
where
the
quote
default.
Values
were
copied
out
of
the
shared
one
and
then
parse
the
like
deserialize
the
config
over
that
there
might
be
a
way
to
decode
it
without
defaulting
happening.
A
A
And
it
happens
so
we
basically
decode
into
the
external
type
and
there's
this
defaulting
function.
That
has
the
custom
logic
to
like
check
what
values
set
and
if
it's
like
a
value,
that's
basically
not
a
user
is
not
expected
to
set.
It
defaults
it
right,
so
it
could
be
like
something
is
set
to
zero.
That
is
never
zero.
It's
a
non-pointer
type
so
like
we'll
set
it
to
one
as
the
default
or
it
could
be.
A
It's
a
pointer
type
and
it's
set
to
nil
so
like
we'll,
set
it
to
an
actual
value
as
the
default.
If
we
and
when
you
and
that's
after
it's
been
decoded.
So
before
it's
been
deco
like
decoded,
you
just
have
this
external
type
struct
that
has
all
of
the.
A
Just
like
zero
values
in
it
right
so
no
pointers
zeros
for
numbers
empty
strings
like
all
that
right,
empty
lists
if
we
skip
it.
So
if,
if
instead
of.
A
A
Like
that's
the
thing
we
decode
on
top
of,
if
we
set
all
the
values
in
that,
like
all
the
shared
values
in
that
to
the
same
value
that
was
already
decoded
from
the
shared
configuration
and
then
decode
on
top
of
it
and
then
copy
all
those
back
into
the
shared
configuration
we,
I
think
we
should
end
up
if
the
user
did
not
set
the
value
in
the
instance
specific
configuration,
we
should
end
up
keeping
the
value
in
the
shared
configuration
the
same,
which
is
what
we
want.
A
It's
it's
super
complex
flow,
but
I
think
it
it
achieves
what
we
want.
A
Yeah,
it's
kind
of
like
like
there's,
you
know,
I
don't
know
like
if
you
play
with
like
bit
twiddling
tricks
like
you
can
do
some
stuff
like
that.
I
think,
but
basically
we,
instead
of
starting
with
a
zero
value,
obstruct
we
start
with
the
values
that
were
already
set
in
the
shared
configuration.
A
And
then
we
parse
the
yaml
over
that
so
that
if
a
value
was
set
in
the
shared
configuration
and
not
set
in
the
yaml,
the
value
in
the
instance,
configuration
is
already
the
same
as
the
shared
configuration.
And
then,
when
we
copy
the
instance
configuration
back
over
the
shared
configuration,
nothing
gets
modified
because
they're
already
the
same.
B
B
Okay,
do
you
think
that
customizing
other
tools
like
these
can
solve
this
easier.
A
It's
possible
yeah,
so
there's
there's
two
angles
on
that
cap
right.
If
you
read
the
discussion
on
there
and
one
is
like
you
know,
try
and
do
what
we're
doing
right
now,
which
I
think
is
going
to
get
increasingly
complicated,
but
I
think
I
think
it
helps
our
argument
if
we
can
show
how
complicated
it
is
with
an
implementation
right-
and
we
can
say
yes,
this
is
this
is
all
the
requirements.
We
discovered
that
we
need
to
implement,
like
this
case
by
case
basis,
and
look
how
complicated
and
hard
to
maintain
it
is.
A
B
B
A
A
A
A
Yeah,
there's
not
there's
not
that
many,
but
the
oh
that's
true
yeah.
We
could
just
say
if
it's
gonna
be
a
field
that
if
it's
or
here's
what
we
could
do,
here's
what
we
could
do.
This
is
much
easier.
We
just
have
a
requirement
that
every
field
in
the
instance
configuration
must
be
a
pointer
field
in
the
external
type
of
the
instance,
configuration.
A
And
then
our
merge,
we
have
to
figure
out.
Maybe
we
we
just
choose
to
carry
that
through
to
the
internal
type.
Maybe
we
have
a
rule
that
says:
if
it's
a
shared
field,
it
must
also
be
a
pointer
on
the
internal
type,
and
when
you
read
it,
you
always
read
it
out
of
the
shared
configuration,
not
the
instance
configuration
it's
a
little
complicated,
but
at
least
it
would
carry
through
the
whether
or
not
somebody
said
it.
Information.
A
A
You
could
add
additional
fields
to
the
internal
type
to
indicate
whether
or
not
it
was
set
on
the
external
type
and
write
custom.
Conversions
that
maintain
that
information.
But
that
would
I
I
the
conversion
in
is
easy
because
you
just
convert
in
with
like
unset
equals
true,
but
the
conversion
out
of
an
unset
is
weird
because.
A
A
I
mean
if
it's
well,
I
guess
if
it's
a
pointer
type,
it's
not
super
weird.
If
it
stays
a
pointer
type
in
the
external,
your
round
trip
would
would
still
work
as
long
as
like
unsaid
equals.
True
results
in
no
player,
but
then
you
still
have
the
problem
of
needing
to
like
effectively
do
a
no
pointer
check,
because
you
have
to
check
this
unset
bit.
So
it's
like
the
same.
A
It's
like
the
same
same
thing
as
having
a
pointer
on
the
internal
from
like
a
semantics
perspective
right
like
as
as
a
user.
Well
as
a
user
I
either
I'm
either
told
I
should
only
read
certain
fields
out
of
the
shared
configuration,
which
is
the
same
thing
we'd
do
with.
If
we
had
a
pointer
on
the
internal
type
just
for
safety,
or
I'm
told
I
have
to
always.
You
know
check
this
bit
before.
A
A
Like
metadata,
like
you
can
in
the
you
can
use
the
backticks
right
after
a
field
and
save
like
json.
You
know
field
name
emit
empty
all
that
stuff.
I
wonder
if
those
are
immutable
at
runtime,
if
we
could
apply.
B
A
A
I
want
users
to
read
it
out
of
like
a
cons
like
I
want
the
code
in
cubelet,
for
example,
to
read
it
out
of
the
same
place
every
time
I
don't
want
random
things.
Reading
it
some
things
reading
it
out
of
the
instance
config
and
some
things
reading
it
out
of
the
shared
config
yeah.
I
agree
and
I
like
some,
but
some
of
that
might
be
unavoidable.
A
If
we,
if
we
take
for
granted
that,
like
we
might
miscategorize
something
right,
we
might
miscategorize
something
as
instant
specific
and
then
discover
it
should
be
shared
or
we
might
miscategorize
something
as
shared
and
then
discover.
It
should
be
instance
specific
in
some
cases,
and
then
you
you're
in
that
situation.
So
unless
you
refactor
the
code
that
was
using
it
at
the
time
that
you
make
it
available
on
the
other
one.
You
still
end
up
with
things.
A
Reading
it
from
both
places
and
it's,
and
if,
if
you
discover
that
that's
the
case,
it's
really
tricky
like
say
we
were
using
pointer
fields
right
so
the
say
the
instance
specific
one
has
like
some
shared
fields
and
we
made
those
pointers
so
that
we
could
do
this
overlay
and
some
non-shared
fields.
So
we
didn't
make
them
pointers
because
we
didn't
think
it
was
necessary.
But
then
we
discovered
that
one
of
those
non-shared
fields
that
wasn't
a
pointer
actually
should
be
in
the
shared
config
too.
A
So
we
have
to
put
it
there
and
then
we
have
to
make
it
a
pointer
in
the
like
internal
instance
config,
and
then
we
have
to
go
find
all
the
code
that
referenced
it
in
the
internal
instance
config
and
make
sure
that
all
that
code
is
doing
no
pointer
checks.
B
A
A
B
Okay,
so
before
the
cobra
command
start,
we
are
initiating
this
new
configuration.
Newcomb
instance
configuration-
and
here
that's
where
of
course,
the
the
initial
load
of
the
cube
instance
in
cubic
feet,
but
in
the
middle
of
the
command
they
start
to
decentralize
this
information,
so
the
like
the
middle
of
the
command.
That's
where
that's
where
we
need
to
find
this.
A
Yeah
I
mean
it's
not
a
big,
it's
it's
nothing
as
long
as
they're
all
set
it
shouldn't
break
any
anything
that
already
exists.
A
A
Well,
so
here's
another
interesting
interesting
point
like
it
would
wonder
if
that
would
break
the
round
trip
tests
if
we
set
them
because
they
were
unset
in
the
external,
the
round-trip
tests
say
that
you're
supposed
to
be
able
to
read
something
in
and
then
write
it
back
out,
and
it
should
be
the
same
as
you
write
it
in,
and
so,
if,
if
it's
like
a
mid-empty,
then
we
read
in
say
we
read
in
an
empty
file
or,
like
the
kind
is
set,
so
you
know
what
type
it
is,
but
you
read
it
in
and
none
of
the
fields
are
set.
A
A
A
It's
just
going
to
read
it
in
so
it
might
not
actually
be
a
requirement
of
this
use
case
that
we
satisfy
that
and
the
test,
I
think,
would
still
work
because,
whatever
magic,
we
do
to
make
sure
the
pointers
are
set,
isn't
going
to
make
it
into
the
round
trip
test,
because
all
the
round
trip
the
road
trip
test
is
already
built
to
say.
Like
okay,
like
you
know,
here's
it
uses
a
fuzzer
so
like
here,
here's
a
random
object.
A
Read
it
in
right
back
out
is
the
same
thing
so
like
we
might
technically
get
around
that.
A
It
well,
I
guess,
there's
there's
multiple
because
tossing
added
those
other
those
tests
that
are
like
round-trip
yaml,
but
I
don't
think
those
tests
would
would
hit
this
either
like
whatever,
whatever
magic.
We
do
to
make
sure
the
pointers
are
all
set.
It's
just
going
to
be
a
like
a
function.
We
call
in
the
bootstrap.
A
So
we've
we've
we've
read
in
only
to
the
external
types.
Can
we
then
merge
it
gets
like?
We
have
to
maybe
write
more
merges
the
more
api
versions
we
have
or
we
need
to
convey.
The
thing
is
conversions,
go
through
the
internal
type
between
api
versions?
So
if
we
got
to
multiple
api
versions
like
say
you
got
a
v1
alpha
1
instance
config
and
a
v1
beta
1
cubic
config,
and
do
we
want
to
even
allow
that?
I
guess
is
another
question.
A
We
could
just
disallow
that
you,
if
you
providing
two
config
files
they're
both
the
must
be
in
the
same
api
version,
might
be
just
a
better
decision.
A
A
That's
the
stage
where
we
do
our
merge
onto
the
shared
external
type
and
then
we
convert
to
the
internal
types.
A
So
at
this
point
the
shared
internal
type
has,
whichever
values
you
know
were
set
from
that
merge
and
the
merge
was
based
on
information
about
whether
or
not
the
user
actually
set
the
field,
because
it's
like
maybe
pre
a
pre-default
merge.
A
A
And
then
maybe
we
have
one
more
step
after
that
to
copy
the
any
values
back
from
the
shared
config
into
the
instance
config,
so
they're
the
same
values
when
it's
a
shared
field
and
any
pointers
and
there's
there
doesn't
have
to
be
any
pointers
on
the
internal
types.
Then,
because
we
did
the
merge
on
the
external
types.
B
That
works,
if
you
get
the
shared
as
pointers
and
merge
the
instances
pointers
before
defaulting,
then
we
default,
and
then
we
merge
again
the
the
fields
with
values
so
again,
like
the
defaults
fixing
and
then
the
user
define
it
fixing
merge.
A
Right
so,
let's
see,
if
that's
possible,
let's
see
if
that's,
let's
see,
if
that's
possible,
without
making
any
changes
to
the
existing
like
api
machinery,
core
code.
B
Okay,
okay,
I
think
I
think
we
have
a
plan
above
this.