►
From YouTube: WG Component Standard Meeting 20190129
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
A
A
A
But
that's
I
think
we
now
got
the
the
label
work
group
standard
label
with
regards
to
infrastructure,
so
that
is
good.
We
should
be
able
to
start
using
or
we
should
be
able
to
start
using
that
and
I
still
have
to.
We
always
still
have
to
add
stakeholder
fix
thing
in
the
community
repo
to
get
this
off
the
ground,
but
yeah.
B
A
A
B
A
A
B
A
Strategically
the
next,
the
next
thing
to
do
is
a
new
cap
fork
like
well
the
cap
for
component
standards,
I
I
think
that
would
be
maybe
the
most
logical
thing
like
to
aggregate,
maybe
even
on
a
high
level
like
we
could
start.
We
study,
easy
and
and
just
list
here
are
all
the
things
we
think
should
be
in
a
convenient
component
or
whatever,
and
then.
B
A
A
That
also
makes
probably
will
make
this
group
more
structured
as
well,
because
because
we
can
see
that
oh,
this
is
the
five
things
we
think
every
component
should
have,
and
then
we
can
focus
on
these
five
items
and
say
like
okay,
let's
start
with
item
one
which
might
be
a
flag
and
config
merging
and
then
we'll
write
a
more
detailed
like
we
will
describe
in
a
high
level
that
this
should
work
like
this
and
then
in
details
with
all
the
edge
case
or
whatever
in
a
separate
cap.
If
needed,
I
think.
B
A
A
A
B
A
B
B
Okay
yeah,
so
we
can.
We
can
do
that
I.
Would
all
I
would
expect
as
well
that,
like
even
if,
as
we
enumerate
things
in
that
dock,
you
know
people
are
gonna
want
to
get
work
on
parts
they
care
about,
whether
they
show
in
there
or
not.
So
we'll,
probably
end
up
with
proposals
that
say:
hey
look.
This
is
a
good
idea
for
components.
Also,
it
wasn't
in
this
enumeration
and
you
know
we're
still
open
to
that.
Yeah.
A
B
Yes,
yes,
some
API
discovery
mechanism
for
the
components,
API
yeah
and
that
could
even
go
further
like
today.
We
were
in
LA
and
Cobra
a
lot
for
help,
text,
generation,
yeah
and
maybe-
and
that's
that's
I-
mean
excluding
q
control.
That
is
the
main
reason
we
use
Cobra
and
a
lot
of
our
components
like
it
shouldn't
really
be
necessary.
Otherwise,
because
the
only
other
things
use
it
for
like
parsing
flags
and
yeah.
So
it's
mostly
to
help
in
usage
flags
and
then
the
documentation
generator
that
directly
links
the
binaries.
A
A
B
B
The
main
like
so
there's
two
things
that
are
bundled
into
this
cap
two,
and
if
you
go
read
that
version
component
configuration
files,
doc
I
wrote
last
year
that
basically
goes
through
employment
component,
config
and
aquila,
and
all
the
problems
are
it
and
like
how
we
solved
them
there,
and
this
cap
is
targeted
at
two
of
those
making.
Two
of
those
problems
easier
to
solve.
B
So,
if
you've
been
incremental,
II
migrating
flags
into
a
component,
config
structure
that
read
from
a
file
or
read
dynamically
from
some
other
remote
source
for
backwards
compatibility
reasons,
you
need
to
overlay
the
values,
any
values
that
are
set
by
flags
onto
the
config
objects
before
you
make
decisions
based
on
that
object
and
the
way
it's
implemented
in
the
cubelet
was
rather
tricky
because
it
involves
re
parsing,
the
command-line,
but
also
you
have
to
do
all
these
things,
to
be
careful
not
to
reparse
parts
of
it.
You
don't
control
like
any
global
flags.
B
So
one
goal
of
this
is
to
provide
a
library
that
kind
of
moves
some
functionality
into
the
front
end
of
flag
registration,
so
that
you
can
actually
decoupled
step
of
registering
a
flag
on
the
command
line
from
applying
of
any
value
set
on
that
flag
to
some
arbitrary
object.
So
now,
instead
of
having
to
reverse
the
command
line,
I
parse
it
once
all
of
those
values
go
into
a
scratch
space,
that's
allocated
by
the
flag
registration
and
then,
when
I
want
to
actually
apply
those
to
a
config.
B
I,
just
clone
apply
function
against
an
arbitrary
config
and
that
just
lets
us
kind
of
clean
up
that
bootstrap
process
and
also
make
the
ability
to
enforce
Flag
precedents
accessible
to
everyone
without
them
having
to
do
their
own
implementations
of
it
rights.
Alright,
then
yeah,
so
that
was
one
problem
and
then
the
other
one
was
just
like
some
helpers
for
importing
any
globally
registered
30
third-party
flags
into
your
flag,
set
that
your.
A
A
So
if
I
understand
it
correctly,
you
will
also
provide
so
if
I
register
a
string
flag.
Just
on
my
own
customer
object,
I
pass
a
command
line
and
when
I
choose
to
apply
that
to
my
newly
credit
config,
it
will
apply
that
string
value
automatically.
That's
been
like
staged
in
between
between
parsing
and
applying.
So
it
will
apply
that
automatically.
But
if
I
want
and
only
if
I
specify
a
separate
thing
separate
function,
I
can
override
that
or
I
customize
that
apply.
Yes,.
B
So
I'll
send
it.
I
can
send
an
example
here
to
with
like
a
few
different
blood
types
implemented,
so
you
can
see
how
that
works,
but
yeah.
Basically
you
know
each
type
will
get
one
or
a
few
helpers
to
define
that
merge
functionality.
So
you
might
have
replaced
you
might
have
for
something
like
a
map.
You
might
have
a
merge
that
merges
Keys.
You
might
have
so
I
have.
In
the
current
example,
I
had
one
called
custom
that
just
takes
using
find
apply
function
as
an
extension
point
yeah.
So
that's.
A
B
B
B
A
A
B
A
If
I,
if
I
bind
my
thing,
I
create
a
new
the
empty
defaulted
object.
I
bind
my
flags
to
that.
If
I
parse,
a
command
line
set
just
the
config
and
defer
the
others,
I
will
check
the
config
and
realize
that
hey
I
have
I,
should
load
a
config,
then
I
low
the
config
and
get
a
new
object
so
either
I
decode,
the
config
I
somehow
into
the
earlier
populated,
flighting
or
I
I,
don't
know
like
every.
B
B
You're
juggling
strings
and
like
doing
storage,
I
tried
to
and
Stefan
have
some
comments
in
the
original
Docs
that
helped
me
mostly
avoid
keeping
explicit
maps
other
than
what
people
are
does
internally
and
I
think
the
way
I
have
to
do.
It
is
pretty
much
completely
type
safe
as
well
yeah.
So
I'll
share
that
later
today,
I
just
have
to
clean
up
the
docs.
A
A
B
A
Then
we
made
this
in
intermediate
step
in
if
to
arts
PR,
and
then
we
got
feedback
from
API
machiner
that
it's
no
better
than
like
moving
the
package.
The
config
close
to
the
controller
was
no
better
than
whatever
I
don't
remember,
exactly
I
have
to
follow
the
special
close
and
yeah
and,
and
they
suggested
that
we
should
rethink
or
like
they
suggested
that
we
should
think
about
just
using
external
types.
B
A
B
B
B
A
A
B
A
A
Yeah,
okay,
no,
no
David,
David,
so
so
I
mean
I
could
buy
the
idea.
At
the
same
time,
we
could
try
to
drop
all
the
because
the
controller
configs
are
so
small
like.
Is
it
just
like
it's
sink
whatever
so
so
I
would?
Maybe
we
be
willing
with
experimenting
so
that
we
would
only
use
the
types
that
are
published
in
the
case,
that
I
cube
controller
manager,
repo
and
we
would
reference
them
to
our
whatever
own
API
group
or
like
no?
A
B
A
Yes,
but
that
is
we
kind
of
we
actually
when
we've
used
you
kind
of
have
to
do
that
in
anyway,
so
a
large
extent,
although
you're
using
internal
versions,
what
we've
done
in
cubed
em
but
yeah,
let's
just
think
through
but
I'm,
just
putting
in
a
kind
of
on
our
agenda
is
that
is
the
PR.
Is
there
it's
technically
ready
to
be
merged,
but
with
those
comments,
although
I'm
I
was
for
it
like
before
doing
merging
that
PR,
but
at
the
same
time
I
could
see
us
experimenting.
B
B
Okay
with
it
as
like,
does
the
existing
API
machinery
support
doing
that,
I?
Guess
it
would
it's
just
a
scowl
yeah
yeah,
it
doesn't
look
like
there's
no
way
could
get
confused
by
the
JSON
annotations
on
the
internal
type
at
all
mm.
We
typically
don't
put
those
on
internal
types,
I,
don't
know
if
it
tries
to
read
them
or
if
there's
anything
I
can
see
there.
I.
A
Yeah
we
will
have
to
like
opt-out
for
conversion
on
that
thing
and
do
that
commercial
manually,
but
yeah.
It
should
work
like
in
theory
when
thinking
about
it
burning
in
practice,
I
don't
know
so
yeah.