►
From YouTube: Implementations Sync: 2021-02-18
Description
Meeting notes: https://bit.ly/38pal2Z
A
I'm
happy
to
facilitate
or
if
someone
else
wants
to.
Okay
awesome,
oh
help.
If
I
opened
up
the
document
all
right,
so
we
started
the
recording
reminder
to
everyone.
Please
sign
in
status
updates.
C
So
yeah
I
had
planned
to
work
on
some
of
the
life
cycle
stuff
today
and
tomorrow.
I
don't
know
how
it's
gonna
work
out.
My
house
is
currently
leaking,
so
I'm
sort
of
dealing
with
that.
So
I
don't
really
know
what
my
timeline
is
for
getting
back
to
doing
the
one
ticket
that
has
my
face
on
it,
but
I
may
do
it
as
a
distraction.
If
there's
some
time
in
between,
I
may
start
kind
of
messing
with
it.
So.
C
E
E
A
D
E
The
I'm
working
on
a
draft
of
the
changes
to
the
spec
for
the
windows
sid
stuff
and
then
starting
on
an
implementation
of
that
already
kind
of
being
juggled
along
with
other
priority.
But
it's
definitely
the
top
top
of
two
items
that
I'm
working
on.
A
Now
we
can
move
on
to
our
release
planning.
I
don't
know
if
we
talked
about
this
as
a
team
yet,
but
we
were
thinking
of
cutting
a
patch.
I
guess
it
would
be
life
cycle,
0,
10
3,
to
include
jesse's
fix
for
the
issue.
I
guess
like
treating
a
mounted
directory,
siblings,
assembling
figuring.
C
It's
not
it's
not
a
huge
deal,
but
I
figured
it
would
have
been
a
good
exercise
to
get
a
patch
out
for
it,
but
but
I'm
I'm
really
okay
with
it,
if
it
waits
until
next
week
or
whatever,
I'm
not
gonna
rush.
D
If
we're
gonna
cut
a
patch,
are
there
other
bug
fixes
we'd
want
to
get
in?
I
know
there
was
the
layer
size
issue
that
was
fixed
in
ggcr.
A
A
So
we
had
so
this
is
the
one
we
just
talked
about,
and
this
says
bug,
but
this
is
really.
This
is
a
feature
and
then
the
other
one
was
this
confusing
bash
error
codes,
which
I
have
yet
to
to
make
my
spec
pr.
That
probably
will
take
some
time.
C
C
A
D
A
Oh,
I
I
put
that
on
the
discussion
for
today
yeah,
depending
on
how
how
hard
that
is,
that
might
be
a
good
one.
C
D
Micah
contributed
some
functionality
to
image
util.
That
should
make
this,
I
think,
fairly
straightforward.
It's
sort
of
what
build
packages
use
in
some
ways,
it's
a
little
funny,
because
we
only
use
cache
images
for
remote
images
and
they're,
not
really
runnable.
We
sort
of
use
them
as
like
a
convenient
blob
store.
So
the
fact
it's
not
a
windows
based
image
in
some
ways
shouldn't
matter,
but
I
do
see
the
point
that,
like
people
expect
to
be
able
to
pull
it
and
the
way
the
windows
demon
works,
it
won't
pull
it.
C
These
will
be
probably
considerably
larger
images
because
of
the
necessary
craft,
but
I
think-
but
I
don't
know.
E
I
did
throw
and
sorry
if
this,
if
this
is
getting
ahead
of
it,
if
we
want
to
talk
about
it
separately,
but
there's
a
kind
of
a
out
of
left
field,
option
where
we
could
try
out
a
hybrid
image,
one
that
would
be
pullable
the
same
exact
image,
which
should
be
pullable
by
a
linux,
siemen
or
a
windows
demon
and
involves
sim
linking
things
inside
of
the
image
to
make
it
to
make
the
windows
things
be
where
they
need
to
be
in
the
linux
directories,
be
where
they
need
to
be,
but
it'd
be
the
same
content,
but
as,
but
I'm
also
not
certain.
C
E
D
E
C
All
right
yeah,
I
think
I
agree
that
makes
sense
to
me.
Do
the
simplest
thing
now
that
we
know
will
work
and
then
and
then,
if
we
want
to
get
fancy
later
for
convenience
reasons,
we
can.
E
I
think
there
was
a
question:
is
this
simple
enough
to
qualify
for
trying
to
tackle
in
the
in
this
milestone?
Do
we
feel,
like
that's,
that's
feasible,.
C
E
It
is
changing
the
interface
the
constructors,
for
the
is
that
is
that
true,
that
we
would
have
changed
the
constructors
for
the
image
util
images
to
set
the
os
type.
E
I
think
you
could
change
it
after
the
fact,
but
right,
but
I
guess
I
didn't
see
the
error
enough
to
know-
maybe
maybe
it's
failing
prior
to
when
we
could
even
call
cetera
on
it
but
yeah.
It
does
feel
like
if,
if
we
do
end
up
changing
the
constructor,
maybe
that's
maybe
that's
significant
enough
to
maybe
put
it
on
a
scope
for
for
this
timeline,
but
yeah,
I
don't
know
sorry.
I'm
kind
of.
D
I
don't
need
to
look
at
it
have
an
opinion,
but
my
guess
would
be
that,
because
we
already
make
windows
build
package
images.
This
is
basically
the
same
thing
that
whatever
we
need
already
exists
in
this
retail,
and
we
just
have
to
change
a
couple
lines
in
the
main
of
wherever
we're
constructing
the
cash
image.
C
E
Yeah,
I
bet
I
bet
it
is
gonna,
be
super
similar
to
what
pack
does
for
that
for
those
packet
build
packages
I'll
see.
If
I
can
dig
up
the
the
code,
but
do
we
do
we
feel
like
that's
worth
trying
to
squeeze
into
the
milestone.
A
Is
that
something
mike
are
you,
do
you
have
the
bandwidth
to
to
look
into
it,
or
we
can
also
put
it
up
for.
E
It's
a
question:
the
the
higher
priorities
for
me
right
now
are
the
windows,
sed
change
and
the
dropping
privileges
for
for
like
priv
dot,
redness,
and
my
gut
feeling
is
that
sids
will
land
first,
the
privileged
stuff,
because
it
is
probably
cleaner
to
make
based
on
that.
I
will
land
after
that
and
then
probably
maybe
the
cash
images
might
be
lower
priority.
But
that's
that's
my
take
on
it
if
y'all
feel
differently.
I'd
be
all
yours.
D
E
D
E
Yeah
and
in
that
sense
too,
do
we
know
the
main
use
case,
and
I
forget
my
ignorance
dude.
You
all
have
the
the
main
use
case
for
these
captions,
just
it's
not
like
capec
or
anything
right.
C
Implementing
it,
I
believe
right,
like
they're,
trying
to
support
using
images
instead
of
volumes
from
the
pack
interface.
Lifecycle
already
does
this,
but
pack
does
not.
Okay,.
D
I
think
kpac
uses
this,
but
probably
doesn't
matter.
Well,
I
don't
know
how
many
kpac
users
are
then
going
and
pulling
the
cash
images.
I
feel
like
it's
probably
not
something
people
interact
with
this
directly,
but
in
pack,
because
you're,
specifically
passing
the
image
with
a
flag.
D
People
are
more
inclined
to
be
like.
Let
me
look
at
that.
E
Yeah
that
makes
sense
yeah,
then,
if
y'all
feel
feel
comfortable
prioritizing
this
over
the
windows
sid
stuff,
even
if
I
mean
it
is
likely
to
be
small
or
infeasible,
in
which
case
I
would
probably
put
it
down
but
yeah.
I
might
take
a
look
at
this
first
then,
before
the
windows
sid
stuff,
I
mean
I'll-
probably
put
this
spec
change
in
for
the
windows
sid.
Let
that
work
its
way
through
before
before
I
start
implementing
the
windows
sid
stuff,
I
would
I
can
take
a
take
a
whack
at
this
thing.
A
Let's,
I
guess
we
took
a
winding
road,
but
I
think
we,
I
think
we
covered
release
planning
and
I
think
we
actually
also
covered
our
niche
discussion,
because
that
was
a
thing
so
great
and
standing
item
rfcs
that
relate
to
implementation.
I
believe
we've
discussed
them
all
great,
and
now
we
have
some
new
topics.
C
B
C
Don't
have
super
strong
opinions
here.
I've
just
got
in
the
habit
of
doing
lots
of
squashing
and
you
know
rebasing
like
npr's
just
it
doesn't,
it
doesn't
affect
the
reviewers
the
same
way
it
does
in
this
group
here,
but
I
don't
mind
just
doing
like
fix
up
commits
and
but
then
I
was
you
know
thinking.
C
Oh
maybe
we
can
just
squash
those
all
when
I
get
merged,
but
the
stephen
brought
up
some
points
on,
like
you
know,
outside
collaborators
or
whatever,
and
they
may
not
feel
comfortable
with
that,
and
that
makes
sense
to
me.
So
I
don't
really
have
a
strong
opinion
here.
I
just
know
the
the
history.
You
know
if
you
get
a
long-running
pr,
it's
gonna
be
a
lot
of
convincing
to
the
main
line
and
so
the
so
it
was
just
something
I
wanted
to
at
least
bring
up.
But
if
we.
D
B
Personally,
I
don't
mind
like
squashing
a
few
commits
together,
but
when
I
do
a
review
to
someone
it's
hard,
I
mean
you
need
to
like
take
the
both
commits
hashes
and
just
compared
both
of
them.
Well,
if
you
just
com,
I
mean
push
commit,
then
you
can
just
pick
the
last
commit
that
you
reviewed
and
then
you'll
see
all
the
changes
since.
D
C
A
different
you
know
workflow
than
some
of
the
folks,
so
I
just
wanted
to
make
sure
we
align
so
I'm
cool.
D
D
C
Totally
be
fine
if
we
enabled
it
on
github
and
then,
if
we
so,
I
had
the
squash
button
like
there
just
for
convenience,
but
an
understanding
that
I
wouldn't
push
it
on
anything.
C
But
was
that
wasn't
my
pr,
but
it
would
just
save
me
some
annoyance
of
squashing
locally
and
then
having
to
push
it
after
someone
has
reviewed
it
because
I
think
it
feels
nicer
to
have
done
all
the
fix
up
commits
to
your
point
you
as
far
as
like
for
review
purposes,
and
then
a
big
squash
button
from
github
means
that
I
don't
have
to
do
anything
special
on
my
end
and
it
doesn't
look
like.
I
changed
everything
after
you
approved
it,
which
is
also
sort
of
a
concern.
C
Yeah,
when
you
hit
the
squash
button,
it
dumps
all
the
individual
commit
messages
just
kind
of
like
it
does.
If
you
were
to
do
a
rebase
locally,
it
dumps
them
all
into
the
thing,
and
then
you
have
a
chance
to
like
edit
it.
There.
C
Exactly
yeah
yeah
because
then
that's
the
only
commit
that
makes
it
into
the
main
line
and
you
still
have
to
remember
to
do
the
dco
stuff.
I
guess
because
otherwise
I
guess
the
ci
would
fail.
Maybe
on
name
like
so
there
are
some
there's
some
automation
stuff
that
I
don't
exactly
know
how
it's
going
to
look
if
we
just
enable
the
squash
button,
but
I'd
be
I'd,
be
the
guinea
pig
there.
If
we
wanted
to
try.
A
E
Just
I
personally
have
gone
away
from
squashing
and
force
pushing
recently
because
of
a
mistake.
Emily
pointed
out
to
me,
which
is
that
if
you
reference
a
another
issue
from
another
repo
in
your
commit
message
or
in
your
issue
message
pr
message,
it
makes
a
bunch
of
spam
on
that
separate
issue,
just
a
bug
in
github
that
gets
exacerbated
by
force
pushing
and
it
wouldn't
be
a
problem
if
you
squash
at
the
end.
B
I
guess
we
can
move
next
one,
so
it's
another
thing
that
I
put
last
week
and
emily.
I
think
that
you
were
not
here
or
you
were
only
part
of
the
meeting.
B
B
B
The
build
pack
will
need
to
set
them
back
to
either
true
or
false,
during
the
export
will
save
the
layers
based
on
the
the
settings
that
the
build
pack
made
and
then
we'll
from
some
reason,
we'll
save
them
for
the
next
round,
but
again
in
the
next
build
we'll
set
them
all
to
false
again.
B
So
after
I
tried,
I
started
working
on
the
actual
code,
I
saw
that
during
the
both
the
restore
and
the
analyze
phase,
we're
actually
reading
these
flags
and
we're
using
them
in
order
to
decide
whether
what
layers
we
need
for
our
current
build,
but
I
was
wondering
whether
we
actually
need
these
flags
or
can't
we
just
see.
Okay.
These
are
the
layers
that
I
have
for
my
previous
build.
Do
I
need
to
use
them
or
not,.
D
They
do
matter.
I
had.
D
One
of
the
examples
were
that
I
think
it's
sort
of
obvious
why
it
creates
problems,
even
though
it's
not
obvious
when
you're
thinking
about
the
process
coming
into
it
is
in
like
take,
for
example,
a
layer.
That's
build
true
launch
true
and
cache
false,
so
it's
in
the
image,
but
we
don't
have
a
copy
of
it
in
the
cache.
D
D
So
in
that
case
we
don't
restore
the
metadata
at
all,
so
the
bill
pack
knows
it
needs
to
provide
the
layer
again,
because
otherwise
you
can
imagine
the
build
pack
looking
at
the
layer,
metadata
and
being
like
this
is
exactly
the
layer.
I
wanted
I'm
not
going
to
make
a
new
one,
but
but
it's
not
there,
so
it
really
does
need
to
make
a
new
one.
B
D
Build
container
right
so
if
the
layer
contains,
if
it's
build
true,
it
means
it's
providing
something
that,
like
a
downstream
build
pack
needs.
So
maybe
you
know
a
tool
that
another
build
peck
uses.
D
So
even
if
that
layer
is
in
the
previous
image,
because
it's
also
needed
at
launch
the
same
tools,
you
did
at
launch.
It's
not
satisfying
the
requirements
of
the
downstream
build
pack.
If
it's
not
actually
on
disk
at
build
time.
B
D
So
right
now,
if,
if
we
were
in
this
case,
we
don't
restore
anything
because
we
think
the
only
thing
we
could
give
the
build
pack
is
useless,
like
just
the
metadata
isn't
useful.
We
don't
wanna
if
there's
no
chance
that
the
build
pack
could
avoid
doing
work
based
on
something
we
restored.
We
don't
wanna,
restore
anything.
B
So
when
will
we
restore
the
metadata.
D
It
would
be
like
if
it's
if
it's
launched,
true,
build
false
cache,
false
or
restore
only
the
metadata,
because
the
build
pack
could
reuse
the
layer,
decide
to
reuse
a
layer
without
needing
a
local
copy,
or
if
it's
launched
true,
build
true
cache.
True,
then
we
can
restore
the
metadata
and
the
contents
from.
B
D
Cache
from
the
cache,
if
it's
in
the
cache,
if
it's,
if
there's
no
copy
in
the
cache,
because
it's
you've
deleted
your
cache
or
something
we'll
restore
nothing.
So
you,
if
it's
launch
only
you
can
get
just
the
metadata
for
any
other
type
of
layer.
D
You
will
either
get
both
the
contents
in
the
metadata
or
nothing.
We
never
restored
just
the
metadata
if
the
contents
are
needed.
B
And
the
reason
about
so,
if
build
equals.
True
this
all
these
flags
are
very
confusing.
I'm
sorry,
if,
if
launch
is
true,
build
is
true.
Cash
is
false.
Let's,
let's
leave
cash
oh
like
inside,
so
if
launch
is
through
cash
belt
is
true,
then,
in
the
previous
build
we
saved
the
layer
in
the
app
image
right,
but
the
layer
was
used
by
the
next.
I
mean
one
of
the
next
build
packs
right
in
the
chain.
D
C
It
is
weird,
though
I
mean
it,
it
is
super
confusing,
but
now
let
me
just
kind
of
explain
some
of
it.
I'm
like
okay,
maybe
now
I
sort
of
understand
it,
but
I
think
we
have
to
have
the
metadata
so
that
we
know
that
it
gets
restored
at
launch
time
right,
but
we
don't
want
to
restore
it
during
build
time.
In
this
case,
even
though
build
is
true,
because
cache
is
false,.
B
A
D
Like
I
need
ruby
at
runtime
to
run
my
ruby
app
a
downstream
build
pack
that
executes
bundler
also
needs
ruby
to
be
available,
so
that
would
be
a
build
true
launch,
true
layer,
but
like
a
launch
true
build
false
example,
might
be
something
like
the
jre
like
I
use
the
jdk
at
build
time.
I
don't
need
a
jre
at
build
time.
I
only
need
it
in
the
image
so
on
the
next
build
my
java
build
pack,
it
doesn't
need
a
copy
of
the
jre.
B
So
when
launch
is
true,
it
means
that
we
we're
going
to
put
it
in
the
app
image,
but
you're
saying
that
if
build
was
true,
so
in
the
next
build,
we
won't
get
the
metadata
of
this
layer
because
we're
actually
needing
the
the
data
itself.
B
C
B
But
we
want.
We
won't
be
able
to
restore
the
metadata
in
the
next
build,
and
I'm
not
sure
I
understand
it
because.
D
It's
to
make
the
life
of
the
build
pack
a
little
bit
easier.
So
let's
do
just
the
launch
true,
for
example,
and
let's
let's
do
the
concrete
like
jerry
example.
So
the
first
build
I'm
a
jerry
rebuild
pack,
I
put
a
generator
layer
and
in
the
layer
metadata
I
say
what
version
of
the
jre
it
is.
It
gets
put
in
the
final
app
image,
great
it's
available
at
runtime
on
the
next
build.
D
The
analyzer
gives
me
the
metadata
from
the
previous
layer.
So
I
go
read
the
metadata
and
I
say
what
version
of
the
jre
was
that
and
if
the
version
is
still
the
version
I
want.
I
say:
okay,
I'm
going
to
do
nothing
in
a
case
where
it's
now
we've
moved
from
jerry
to
ruby.
So
I'm
the
ruby
build
pack.
D
If
I
do
the
first
build
contribute,
ruby
write
the
version
in
the
metadata
it
gets
stored
on
the
image
and
then
let's
say:
let's
do
something.
The
lifecycle
doesn't
do
right
now,
but
what
we
would
do
if
we
didn't
save
this
information,
so
let's
say
now
the
next
run.
The
analyzer
gives
me
that
layer
metadata
as
a
ruby
build
pack.
I
might
go,
look
at
it
and
say:
oh
it's,
the
version
I
want.
D
I
should
do
nothing,
but
but
that
would
break
downstream,
builds
because
there's
no
ruby
on
disk
at
this
point,
so
the
bundler
bill
pack's
going
to
fail
and,
yes,
a
build
pack
could,
in
addition
to
reading
the
layer
matter
that
go
check
if
the
layer
exists,
but
it's
putting
more
com
responsibility
on
the
build
pack
where,
as
the
life
cycle,
we
already
knew
up
front
that
the
bill
pack
couldn't
avoid
work,
because
if
it
didn't
build
time-
and
we
don't
have
it
it's
impossible
for
the
bill
pack
to
avoid
doing
the
work
so,
instead
of
making
it
more
complicated
for
the
build
pack
to
ask
the
do,
I
need
to
do
the
work
question.
B
B
Maybe
a
follow-up
question:
why
don't
we
restore
the?
Why
do
we
only
get
the
metadata
and
not
the
full
layer.
D
So
we
use
the
cache
to
be
a
place
where
we
can
say
these
are
things
that
are
available
to
restore
and
a
lot
of
times
in
most
platforms,
the
most
performant
way
to
do.
That
is
a
volume
like.
Yes,
if
you
had
a
cash
image,
it's
probably
equivalent,
but
if
it's
a
volume
it's
not,
and
we
want
to
be
explicit
about
where
we're
willing
to
pay
the
penalty
of
fetching
a
layer
from.
B
And
and
back
to
my
original
question,
so
this
is
why
we
actually
need
the
flags,
because
we
want
them
to
know
whether
we
should
read
the
metadata
or
not
or
the
actual
data
or
not
yeah,
I
mean
actually
we
so
it
means
it
kind
of
means
that
we
can
save.
Only
the
build
flag
doesn't
make
sense,
or
it's
just
too
complicated,
to
think
about
all
these
like
options.
B
C
B
But
you
can
read
the
cache,
so
you
can
read
a
cache.
You
can
see
whether
you
have
this
layer
and
then,
if
you
have
this
layer,
it
means
that
cache
was
true
in
the
previous
build
and
you
see
whether
you
have
this
metadata
in
your
app
image.
So
you
know
whether
launch
was
true
in
the
previous
build,
so
you
only
need
to
know
whether
build
is
true
or
false
to
actually
but
probably
it's
easier
to
just
have
these
three
flags
and
like
okay,.
D
I
think
that's
true
for
launch
like
if
it's
in
the
image
it
was
launched
through,
like
every
layer
that
ends
up
in
an
image
in
its
types,
is
going
to
say,
launch
true,
because
that's
the
only
way
it
ends
up
there,
like
that's
just
always
true.
So
in
some
ways
it's
meaningless
data,
although
I
do
like
it,
it's
explicitness,
okay,
cache
layer
is
similar
to
a
build
layer.
D
In
that
a
cache
layer
is
always
available
at
build
time,
but
we
might
not
make
its
contents.
We
might
not
expose
its
contents
to
downstream
bill
packs
so
like
in
our
ruby
example.
If
it's
a
build
way,
you
know
ruby
ends
up
on
the
path
and
then
downstream.
Build
pack
can
use
it
in
a
cache
layer.
That's
not
true,
but
the
build
pack
itself
might
have
a
runtime
dependency
on
a
cache
layer.
D
C
The
relationship
between
building
cash
is
confusing
because
yeah,
but
I
can't
think
of
too
many
reasons
why
I
would
do
build
true
and
cash
false
like
because
in
our
example,
you
would
want
the
rubies
to
be
able
to
be
pulled
from
cache
next
time
so
that
you
don't
have
to
do
that
work,
and
I
guess
if
that
layer
isn't
available
in
cache,
we
don't
write
the
metadata
right
or
like
we
don't
write
the
layer
tunnel,
so
it
has
to
redo
it.
So
it's
kind
of
like
as
if
nothing
existed,
to
begin
with.
D
Yeah,
I
can
think
of
reasons
I
might
want
catch
true
and
build
false.
The
opposite
doesn't
come
up
very
often,
and
all
the
examples
I
could
come
up
with
are
pretty
contrived.
It's
like
every
run
generate
a
random
liar
or
something
crazy
like
that
right.
It's
like
I
never
want
it
back,
but
other
build
packs
need
to
use
it.
D
Actually,
I
do
one
real
world
example:
the
ca
certs
build
pack
takes
certificates
from
a
binding
and
creates
a
directory
that
has
a
bunch
of
correctly
named
sim
links
pointing
to
certificates
and
sets
an
environment
variable,
and
that
needs
to
be
build
true,
because
you
want
that
environment
variable
to
be
set
for
downstream
build
packs,
but
we
don't
actually
want
to
recover
this
data.
We
only
want
to
do
this
on
the
next
build
if,
if
again,
a
binding
is
supplied
at
build
time.
So
that's
a
real
world
example
of
build.
True
cash
falls.
B
A
B
D
D
B
B
C
B
A
No,
no,
I
I
was
trying
to
capture
this
in
a
table
that
we
could
refer
to
later,
but
I'm
not
sure
if
I
I
might
have
to
go
back
and
watch
the
recording
to
make
sure
I
kind
of
got.
I
got
all
the
examples.
B
Now,
if
you
want,
we
can
review
it
together.
The
table
that
you're
very
great.
A
I
think
we've
we've
exhausted
our
topics
right,
I
I
was
curious.
We
don't
have
to
do
this
now
because
we're
12
minutes
left,
but
I
I
was
curious
to
to
continue
the
discussion
that
we
were
sort
of
having
on
different
ways.
We
can
approach
validating
our
tomml
right
with,
like
api
version,
structs
or
some
sort
of
validator
service
like
I
think
there
was
sort
of
competing
and
it
might
be
worth
just
sort
of
like
I
don't
know,
vaguely
sketching
it
out
so
that
we
can
form
an
opinion.
C
C
Guest
somewhere
that
I
don't
know
where
it
is
anymore,
but
I'm
sure
I
could
find
it
yeah,
I
don't
have
strong
opinions
there.
I'm
definitely
not
a
go
expert
on
like
organization.
I
just
know
like
interfaces.
Look
like
the
right
path,
like
just
from
an
external
consumer
of,
like
you,
know,
a
build
pack
package
like
exposing
those
trucks.
I
think
will
eventually
cause
us
some
pain.
Like
you
know,
it's
life
cycle
does
stuff,
but
I
I
know
having
all
those
strucks
is
a
huge
pain
too.
So
I
don't
know.
B
A
C
The
single
struct
way,
which
I
think
is
fine,
but
I
think
it
does
potentially
leave
us
open
for
you,
know
parsing,
but
right
now
we
parse
the
tomb
on
multiple
places.
I
think
that's
the
biggest
problem
I
have
with
what
we
currently
do,
regardless
of
what
we
do.
I
think
if
we
make
a
nice
interface
for
parsing
structs
and
returning
even
if
we
return
a
struct,
I
think
that
makes
sense.
C
Validation,
because
right
now
we
can
have
some
gifs
that
are
like
deciding
logic,
and
I
think
that's
that's
the
main
concern
I
have
with
the
current
approach.
We
have
so
like
as
long
as
we
centralize
parsing.
I
think
we
can.
We
can
make
anything
work,
but
I
know
right
now:
it's
really
easy
to
write
it.
The
if
statement
the
wrong
way
and
not
write
a
you
know
else
to
kind
of
set
it
the
default
correctly
and
then
you
like
accidentally,
get
mixed
feature.
D
Sets
this
is
crazy.
I
haven't
thought
this
through
all
the
way
yet,
but
I'm
wondering
like
we
want
to
wrap
sort
of
tommle,
encoding
and
decoding
in
our
own
encoder
decoder
that
understands
more
struct
annotations
like
if
we
could,
in
the
you
know
where
we
have
things
that
could
be
like
tamil
emit
empty,
like
that
kind
of
struck
the
annotation.
If
we
could
have
built
back
api
version,
you
could
set
like
min
and
max
and
stuff
like
that,
and
then
we
could
just
add
these
things
on
different
fields
and
hope
they
work.
D
I
think
it'd
be
convenient.
I
don't
know
if
it
makes
the
best
like
code
interface.
If
people
want
to
be
importing
lifecycle,
though,
but
maybe
we
could
make
private
versions
of
stuff
that
have
that
and
then
do
something
more
clever
in
the
interface
yeah.
I
haven't
quite
thought
it
all
the
way
through
yet.
C
Because
there's
the
json
serializing
stuff
or
whatever
that
you
can
like
by
implementing
a
method,
you
can
change
how
it
works,
and
that's
really
useful
if
you
have
a
bunch
of
structs
that
sort
of
inherit
other
structs
so
that
you
can
control
emitting
and
not
emitting
certain
things,
because
yeah,
if
we
ever
need
to
like
write
out
a
lyritaml,
then
like
I
can
imagine
it
being
complicated
to
like
make
sure
that
we
have
the
struct
set
up
so
that
we're
not
writing
values
that
you
know
an
older
life
cycle
might
not
understand,
or
something
like
that.
C
A
C
C
Wrong
I'd
like
to
see
the
custom
stuff
you're
talking
about
emily,
like
if
it's,
I
wonder
how
hard
it
is
to
write
that
that
behavior,
that
you're
talking
about,
because
could
you
like
embed
version
numbers
in
it
or
something
like
that?
My
api
version
numbers,
like
you,
know,
that'd,
be
kind
of
interesting,
so
they
would
always
serializing
it
to
a
certain
version.
Number
would
omit
it
or
reading
it
would
be
similar.
It
would
just.