►
From YouTube: WG Component Standard 20190423
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
We
have
a
few
agenda
items
today,
but
it
looks
like
lei
isn't
here
and
I
think
he
added
those
so
I'm
going
to
say
let's
punt
most
of
those
to
next
week,
so
he
can
be
here
for
that
and
then
there's
only
one
more,
which
I
added,
which
is
the
first
legacy
flag
pr.
But
before
we
do
that,
I
was.
I
was
wondering
if
you
guys
have
anything
you
want
to
talk
about.
A
I'm
just
like
listening
here:
okay
cool
so
I'll,
take
a
look
at
that
pr,
then.
So
what
this
is
is
sort
of
the
first
version,
if
you
will
of
the
legacy
flag,
library
kind
of
an
example
of
what
a
more
complete
version
of
it
would
look
like
and
and
how
that
would
work.
A
A
B
So,
who,
who
are
the
owners
for
legacy
at
the
moment.
B
I
I
only
quickly
read
the
kept
for
legacy
flag.
Unfortunately,
I
didn't
have
the
time,
but
can
you
summarize
like
what
is
the
purpose
exactly.
A
Yeah
so
there's
a
few:
when
people
try
to
do
component
config
and
do
the
migration,
it
usually
happens
that
they
can't
just
do
it
all
at
once,
and
so
then
you
need
to
do
this
incremental
migration
from
flags
to
config,
and
even
if
you
did
it
all
at
once,
you'd
still
need
to
maintain
that
command
line
for
some
period
of
time,
just
due
to
the
deprecation
policy,
and
that
makes
a
few
things
challenging
around
maintaining
that
backwards.
A
A
Whenever
you
want,
wherever
you
want,
so
you
don't
have
you're
not
forced
to
to
copy
those
values
into
your
config
at
the
same
time
that
you
parse
them
and
the
reason
that's
important
is
because
the
way
that
you
kind
of
implement
that
backwards
compatibility
is
that
you
have
to
have
the
flags
take
precedence
over
the
config,
which
means
that,
like
you,
you,
you
know,
you're
gonna
load
a
config
file
and
then
parse
flags
into
it,
but
because
there's
other
flags
that
aren't
in
the
config.
A
Yet
you
had
to
parse
the
flags
before
you
loaded
the
config
files
now
you're
in
the
business
of
parsing,
the
flags
twice
in
the
current
model,
and
when
you
do
that,
you
have
to
do
other
things
to
be
careful
that
you
aren't
re-parsing
any
global
flags
from
third-party
libraries,
because
you
don't
know
what
those
flags
do
you
don't
know
how
they
behave
across
multiple
parses.
You
also
have
to
be
careful.
If
there
are.
A
A
And
I
we
think
we
can
make
it
a
lot
easier
by
just
having
a
structure
where
you
only
parse
the
flags
once
and
then
you
have
all
the
values
accessible
to
you
that
you
can
apply
arbitrarily
after
that
point.
So
that's
that's
one
goal
of
this
and
then
the
other
goal
is
there's
some
other
helpers
in
here
for
dealing
with
global
flags
and
that
I
think,
have
been
duplicated
in
other
areas
of
the
code
base
now.
A
So
those
are
the
main
reasons
I
think
there's
some
other
there's
some
other
details
in
the
cap
as
well.
If
you
go
look
at
that.
B
Yeah,
I
see
it
makes
a
lot
of
sense
definitely,
but
so
today,
some
somebody
raised
the
point
that
p
when
you,
when
you
have
a
flag
that
is
deprecated
pfuck
by
default,
prints
the
deprecation
mesh
message
to
a
standard
error-
and
this
is
like
walk
pipes
this
to
does
not
pipe
this
to
the
walk
file.
A
A
A
The
way
we
have
logging
set
up
for
the
cubelet
in
production
is
like
streaming
standard
air
somewhere
and
so
we're
just
seeing
it
anyway.
Yeah
people
who
use
the
file
based
logging
options
on
k,
log
yeah.
I
can
see
how
that
could
be
a
problem.
A
Lei,
you
have
some
agenda
items
here.
If
you
want
to
jump
into
those.
C
Yeah
it's.
These
are
definitely
worth
noting
the
kodak
factory
options.
One
is
a
continuation
of
the
work
for
the
strict
decoder.
The
codec
factor
is
necessary
to
produce
universal
decoders
that
do
fall
through
and
default
in
logic,
which
is
useful
for
when
decoding
big
files.
C
My
primary
concern
with
this
is
that
this
idea
of
like
using
width
options
as
an
extension
to
the
existing
constructor
name,
so
that
we
don't
break
the
the
interfaces
and
then
also
passing
a
struct
right,
which
has
to
be
instantiated.
That,
then,
is
not
also
called
like
something
options.
C
It
makes
the
incantation
for
creating
a
codex
factory
really
complicated,
because
then
you
are
codec
factory
with
options
scheme
like
and
then
you
have
to
create.
You
have
to
construct
an
object
with
like
factory
options.
I.
A
C
Yeah
after
I
worked
with
it
and
like
considering
how
many
times
serializer
and
codec
factor
have
changed,
I
don't
really
see
the
like
argument
that
people
were
making
that
we
were
going
to
have
to
maintain
two
to
two
times
n
constructors.
C
C
A
Right
so
that's
well
and
that
and
then
every
option
is
a
binary
option
and
you
have
a
constructor
per
option.
Combination.
B
D
Right,
or
was
it
the
other
way
around
codec
factory
will
give.
C
B
Yeah
my
point
was
that
pretty
was
only
useful
for
the
json
case
and
when
you
basically
write
a
json
file
as
a
structure.
Yes,
that
is
pretty
cool,
so
it's
not
useful
when
it
doesn't
make
sense
for
yama
and
also
it's
the
toggle.
The
binary
toggle
here
is
not
useful
when
you
put
jason
in
a
structure,
so
it's
kind
of.
C
A
C
Okay,
yeah,
I
mean
this
was
lava
suggestion
they
get
had
initially,
when
we
did
the
design
work,
he
and
lucas
were
just
making
more
of
instructors
and
that's
what
was
some
of
the
initial
like
feedback
we
got
on
the
original
json
prs
was
to
do
it
this
way.
So.
C
C
C
Yeah
and
I
can
do
follow-ups
later
right
to
clean
things
up
in
the
400
places
that
need
to
be
cleaned
up
right
right,
but
yeah
that
makes
it
really
hard
to
get
stuff
merged.
B
B
So
I
think
I
made
a
comment
about
that.
We
should
add
more
details.
I
mean
if
api
machinery
wants
the
pretty
to
be
asses,
you
should
probably
document
where
like,
in
which
cases
it
makes
sense,
because
this
is
a
visible
comment
in
godox.
B
This
is
my
first
comment.
I
mean
it's
kind
of
clear,
but
the
other
one
is
the
something
that
stewart
brought
up.
That's
the
that
we
always
have
to
create
the
pretty
serializer,
and
basically
that's
my
impression
when
previously,
when
I
looked
at
the
code
that
we
created,
even
if
you
don't
ever
use
it
and
so
look,
what
is
your
opinion
here.
C
C
So,
like
that's
total
jargon,
but
when,
when
you
need
to
like
hydrate
the
serializers
from
just
like
a
collection
of
structs
that
you've
initialized
and
constructed
into
serializers
that
actually
perform
defaulting
logic
that
happens
in
the
universal
decoder
function.
C
It
like
does
magic
in
the
encoding
package
and
it's
not
easy
to
trace,
but
basically
something
in
there
is
going
to
to
do
that.
Json
pretty
stuff,
and
it's
not
contained
within
this
package,
so
that
abstraction
is,
is
like
hidden
somewhere
else,
which
is
a
code
smell.
D
What
was
the
name
it
uses
in
the
back
end
in
json.
C
C
Oh
never
mind
and
oh
I'll
look
at
that
bit.
I
think
I'm
starting
to
like
the
pretty
portion
of
this
abstraction.
It's
just
like
really
weird.
I
kind
of
threw
it
in
there
because
I
was
like
well.
You
can't
just
have
one
option
but
yeah.
A
C
C
C
It's
like
it's
very
painful,
but
it's
been
a
good
learning
experience
for
sure
like
I,
I
never
imagined
how
sticky
these
problems
would
be
very.
A
C
A
C
B
I
have
no
idea,
that's
that's.
My
memory
basically
might
be
wrong
here.
Are
you
talking
about
the
proto
serializer.
C
A
C
So,
what's
nice
is
that
at
least
that
all
that
stuff
is
not
in
the
json
package,
which
means
that
all
of
these
abstractions
that
I'm
creating
now,
I
should
probably
go
read
that
stuff
again
and
see
how
alien
the
interfaces
we're
creating
look
in
comparison.
B
But
then
again
you
should
probably
just
I
mean
as
long
as
api
machinery
is
happy
with
the
pr
in
terms
of
hey.
We
want
this,
and
maybe
we
should
just
roll
with
the
work
and
merge
pr
instead
of
digging
deep
in
this,
because
it's
it's
kind
of
complicated
and
so
people
like
jordan
and
clayton
have
expressed
that
we
should
we
shouldn't
probably
like
dig
into
this
and
change
stuff.
B
A
That
makes
sense
to
me
as
well
yeah,
if
you
you
know,
I
it's
definitely
worth
making
sure
this
stuff
is
better
tested
in
a
follow
up,
if
you'd
like
to
do
that.
But
yes,
if
api
machinery
is
okay
with
merging
this
as
it
is,
then.
C
C
Yeah
and
I'm
I'm
fine
to
you-
know,
create
follow-up
issues
just
as
long
as
we
never
lose
track
of
them
right
and
they
almost
stay
prioritized
because,
ultimately,
the
goal
of
this
working
group
right
is
to
keep
the
longevity
of
the
project
in
mind
yes
and
improve
the
code
quality
of
what
is
a
code
base
in
need
really.
B
C
The
only
person
I
really
chatted,
much
regarding
like
the
manifesto
of
this
working
group,
is
like
with
lucas,
but
I
mean,
like
we've,
got
like
goals
with
conformance
and
security.
Really,
I
think
once
we
finally
have
like
config
and
flag
and
like
ultimately
like
having
a
central
place
to
manage,
mtls
and
delete
it
off,
like
that's
all
code,
cleanliness
for
security
problem
really.
C
Yeah
anyway,
that's
like
the
the
first
bullet
point.
A
C
C
Yes,
yes,
thank
you
guys
for
waiting
for
me
by
the
way
and
then
just
the
only
other
thing
was
stuart.
Has
a
request
for
design
on
the
controller
manager
thing
which
you
guys
may
have
chatted
about
so.