►
From YouTube: WG Component Standard 20190528
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
may
28
2019
working
group
component
standard
meeting.
We
do
have
a
few
items
on
the
agenda
today,
so
we'll
get
into
those.
I
think
you
added
those.
Let
me
let
me
screen
share
here.
A
B
Yeah
I
haven't
read
this
patch,
but
if
we
open
it
up
lucas
kind
of
said
that
it
was
related
in
some
way
to
the
credit
factory
and
yeah.
His
description
says
that
this
enables
us
to
peak
okay,
so
to
component
configs
with
multiple
documents.
But
I
know
lucas
was
pretty
adamant
about
having
some
kind
of
multi-doc
support.
I
assume
that
this
does
it
in
a
good
way
that
doesn't
just.
B
Yeah,
I
believe
that
there's
there's
no
support
for
those
okay,
if
I'm
not
mistaken,
because
we're
not
like
based
on
go
yaml
or
anything
like
that.
I
think
we
we've
written
our
own
right.
B
Yeah,
I
think,
the
last
time
I
looked
at
that
it
literally
splits
the
document
on
the
separators
which
that's
like
pretty
bad,
because
you
can,
you
can
fool
it
since
the
ammo
is
so.
A
B
I've
definitely
seen
code
in
kubernetes,
that's
splitting
on
hyphen
hyphen,
hyphen
and
dot
dot
dot,
which
is
obviously
not
it's
not.
A
B
So
yeah
yeah
what's
happening
here,
so
he's
changed.
The
marshall
package
to
probably
use
yeah
this
new
meta
factory
and
the
marshall
package
is
being
used
by
kubernetes.
A
Is
the
deserializer
basically
so
to
one
that
supports
multi-dock?
Is
that
the
idea
looks
like
that's
what
he's
doing
and
he
switches
this
library
to
animal
serializer
and
then
unwatching.
It
he's
calling
this
interpret
method.
B
Is
this
in
this
is
a
completely
new
file,
this
yaml
meta
go,
I'm
pretty
sure.
B
B
Yeah-
and
it
just
calls
it
until
it
returns
an
error.
B
A
I
I
guess
this
reader
supports
multi-doc
and
is
reading
one
document
at
a
time.
Okay,
this
is
really.
This
must
just
be
the
yeah
split.
Yellow
documents
must
just
be
the
thing
that
does
multi-doc
and
for
some
reason,
lucas
wants
to
switch
to
this
thing
to
pull
the
gbk
information
out
instead
of
whatever
we
were
doing
before.
B
A
B
B
A
Or
if
these
these
look
like
they
might
have
just
been
redundant
checks
like
empty
version
and
kind
might
just
be
in
the
other
offers
already
so
but
yeah.
That's
that's!
For
code
review!
Okay!
Let's
go
to
the
next
one.
B
A
B
We've
seen
this
patch,
probably
like
four
times
already:
it's
been
open
for
ages
and
I'm
not
sure
when
api
machinery
reviews
gonna
get
back
to
this
again.
B
Yeah
lucas
and
stefan
took
a
look
at
this
last
week
and
gave
me
a
little
bit
of
feedback.
I
ripped
out
some
stuff
and
oh
actually,
yeah.
I
don't
know.
Maybe
you
would
have
some
input
on
this.
If
this
like
looks
same
to
you,
can
you
open
the
code
really
quick.
B
Json
type
serializer
type,
pretty
serializer
that
comes
from
this
like
internal
package,
so
if
it's
not
pretty,
then
that
field
doesn't
get
set
and
this
serializer
type
gets
converted
on
init
into
a
serializer
info,
and
the
field
for
pretty
serializer
is
a
interface
for,
I
think
runtime
serializer,
which
means,
I
think,
that
that
defaults
to
a
nil
interface
sure.
B
B
What's
weird,
is
that,
like
the
the
serializing
logic
that
actually
uses
the
serializer
info,
it's
pretty
decoupled?
I
read
it
at
one
point
and
it's
kind
of
hard
to
find.
A
B
Yeah,
I
guess
I
I
thought
that
maybe
just
leaving
the
serializer
off
and
letting
it
default
would
mean
that
the
json
package
would
not
serialize
with
pretty.
If
the
serializer
info
did
not.
I
actually
have
a
pretty
on
it,
but
it's
yeah.
It's
like
very.
A
B
Yeah,
so
the
serializer
info
carries
potentially
multiple
serializers.
You
can
put
the
main
one.
You
can
put
a
pretty
one.
You
can
also
put
a
streaming
one.
I
see
and
yeah
like
for
different
use
cases
you'll
have
some
or
none
of
those
but
yeah.
That's
the
only
thing
that
I
I
need
to
look
into
more
and
test
out
in
this
patch,
because
this
patch
doesn't
have
any
tests
right
now.
I
need
to
generate
a
bunch
of
stuff.
B
But
yeah,
basically,
we
removed
some
public
constructors,
something
that
you
may
have
an
opinion
on
is,
if
you,
I
believe,
scroll
up.
B
So
here's
the
options
stuff
previously
we
were
gonna,
have
a
constructor,
a
new
one
called
codec
factory
with
options
that
was.
B
Yes,
so
now
we
do
have
the
options
struct,
but
then
lucas
and
stefan
kind
of
said:
hey.
Let's
do
this
mutator
funk
thing
since
the
since
it's
convenient
that
the
current
constructor
does
not
have
any
options
in
the
arguments.
A
A
B
So
you
can't
do
that
here,
because
the
codec
factory
is
set
up
when
it's
constructed
and
you
have
to
do
well.
You
could.
B
Basically,
by
the
time
you
receive
the
codec
factory,
it's
already
generated
a
bunch
of
serializers
and
done
a
bunch
of
type
conversion
and
created
a
pretty
complex
structure.
Where's.
A
B
Yes,
and
that
allows
us
to
keep
the
same
constructor,
but
it
it
complicates
the
maintenance
and
like
if
anything
in
an
option
was
never
wasn't.
A
A
A
A
A
B
Yeah,
I
mean
that's
really
all
I
have
to
say
on
this
patch.
We
just
really
need
to
get
it
merged,
because
a
lot
of
other
work
is
dependent
on
using
codec
factory,
so
but
whatever
it
ends
up
being
I'm
not
we.
We
actually
cannot
do
this
pattern
for
serializer,
which
is
unfortunate
that
it's
not
uniform
because
serializer,
it
already
has
options
in
the
constructor.
B
Yes
yeah,
so
the
the
constructor
like
doesn't
even
make
sense
to
add
mutator
funks
when
it
already
has
an
options
field
so
that
just
required
a
new
signature
but
yeah
this
is.
We
can
do
it
here
so.
A
Yeah,
so
the
the
legacy
flag
stuff
got
merged
woohoo.
A
A
So
I
knew
I
was
hoping
like
lucas-
or
stefan
would
be
here
today
to
talk
about
this
because
they
both
brought
up.
I
think
like
cube.
Adm
is
one
option
and
cube
proxy
is
another,
and
I
think
you
you're
relatively
familiar
with
cube
adm's
code
right
yeah,
so
somebody
who
actually
understands
those
components
should
go
give
that
a
shot
if
they
can.
A
B
A
That
you
implementing
flag
precedence
should
basically
be
and
apply
of
the
flags
onto
the
config
object,
and
not
all
this
magic
to
re-parse
the
flags
without
like
breaking
other
things
like
a
good
example
where
that
gets
tricky
is
last
week
or
the
week
before,
we
had
an
issue
where
all
of
the
k-log
arguments
were
being
reset
to
their
defaults
in
cubelet
after
flags
were
parsed,
and
it's
because
k
log
was
resetting
its
defaults.
A
Every
time
you
called
kellogg.net
flags
which
the
cubelet
ended
up
doing
twice,
because
it
was
constructing
trying
to
construct
a
fake
command
line
to
re-parse
the
flags
as
part
of
its
precedence
enforcing
path,
so
that's
been
fixed
in
in
k-log,
but
there's
just
there's
just
so
many
ways
that
it
has
to
be
too
perfect
when
components
are
re-parsing
the
command
line
that
you
can
get
these
little
bugs
that
cause
significant
issues.
So
this
is
designed
so
that
you
only
parse
the
command
line
once
and
then
you
have
all
the
values
in
a
scratch
space.
A
Apply
them
arbitrarily
as
many
times
as
you
need,
so
this
and-
and
this
was
brought
up
a
number
of
times
as
a
blocker,
especially
in
q,
proxy,
to
adopting
component
config
and
moving
to
beta
with
their
component
config,
because
they
didn't
want
to
go
through
the
process
of
copying.
The
keyboards
rather
complex
flag,
reparsing
implementation.
A
B
A
A
If
we
could
just
wholesale
switch
to
config
it'd
be
fine,
the
problem
is
even
if
we
could
just
wholesale
switch
in
like
one
release
cycle
to
a
config
and
say
now
use
the
config,
and
then
all
the
flags
will
be
deprecated.
That
would
work
pretty
well.
The
problem
is
that
there's
so
many
flags,
and
so
many
conversations
around
those
apis
that
you
can
never
get
all
of
them
in
a
single
release
cycle,
and
so
you
have
to
have
a
way
of
iteratively
migrating
sort
of
flag
by
flag
over
to
the
config
file.
B
A
At
that
point,
you
need
to
support
both
and
then
you
need
this
merge
and
it
turns
out
merging
flags
into
a
structure
when
the
flags
need
to
take
precedence
is
tricky
because
in
order
to
load
the
file,
you
need
to
parse
the
flags
to
get
the
name
of
the
file,
and
then
you
need
to
layer
the
flags
back
over
the
configuration
from
the
file
right
and
the
way
we
currently
do,
that
is
by
re-parsing
the
flags,
because
there's
so
much
magic
that
happens
in
there.
A
And
I
would
like
to
not
re-parse
the
flags,
because
it's
really
complicated
and
air
prone
yeah,
and
so
this
is.
This
is
a
way
to
register
flags
so
that
after
you
parse
them,
you
maintain
those
references
to
the
values
that
got
parsed
separate
from
anything
any
object.
You'd
want
to
put
them
into
which
lets
you
repeat
that
apply
on
top
of
foo
operation,
so
you
can.
It
makes
it
a
lot
easier
to
parse
the
flags
once
okay,
let
me
load
my
config
file
here.
A
I'll
just
do
the
apply
and
it
should
look
pretty
clean
and
that
so
hopefully
this
is
abstracting
away.
Like
all
the
complexity
of
of
dealing
with
the
layering
that
maintains
compatibility,
we
just
need
somebody
to
go
prototype.
It
now,
and
I
I'd
love
to
do
cuba
at
some
point,
but
I'm
just
super
busy
for
the
next
month,
because
I'm
moving.
B
Yeah
and
what
what
time
is
it
now,
it's
ten
or
three
I
have
to
join
the
add-ons
call
all
right
thanks
for
syncing
up
mike
this
is
this
is
good.
A
Yeah,
you
bet
make
sure
you
ping
those
guys
on
slack
today.
B
Yeah
I'll
I'll
be
able
to
talk
with
lucas
today,
cool
all.