►
From YouTube: Working Group: 2020-12-10
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
Document,
I
guess
it
looks
like
we
don't
have
any
new
faces
so
on
to
the
first
agenda,
item,
search
api
and
take
it
away.
Travis.
B
Yeah
I
made
some
changes
from
yesterday's
discussion
that
I
wanted
to
quickly
go
over
again
and
just
verify
that
there
weren't
any
other
outstanding
items
I'll
share.
My
screen.
B
There's
there's
three
things
that
really
stood
out
from
yesterday's
discussion.
One
was
about
versioning,
which
I
went
ahead
and
indicated
that
we
will
be
doing
versioning
right
now.
I'd
have
a
v1
version
value
right
now
into
the
url.
B
B
Name,
space
build
pack
name
in
point
right
here,
so,
as
you
can
see,
highlighting
is
not
working
really
well,
but
this
payload,
underneath
the
latest
section,
does
reflect
a
one-to-one
of
the
payload.
That
is
also
described
for
the
specific
version
and
that's
being
reused
in
these
other
endpoints.
C
C
B
Yeah
I
mean
I,
when
you
add
a
dashboard
to
it,
we'll
probably
want
some
meta.
So
I'm
just
thinking
high
level
here
when
we
have
a
dashboard
that
returns
a
list
of
results
like
in
a
web
client
we'll
want
to
show
some
high
level
metadata
for
each
of
those
results,
which
I
guess
we
could
get
yeah,
which,
from
an
individual
I
mean
as
well.
B
C
Like
collapsed,
like
each
build
pack
has
a
little
arrow
next
to
it,
you
click
that
and
then
it
follows
the
link
to
get
the
rest
of
the
data
on.
You
know
when
you
click
the
thing,
so
I
feel
like
there's
some
ui
things
we
can
do
to
avoid
getting
it
at
once.
You're
sort
of
I
mean
you
are
absolutely
pushing
that
on
to
the
client,
but
I
think
that's
the
trade-off
I'm
proposing,
I
don't
know
I
does
anybody
else
feel
strongly
about
that
latest
chunk.
D
I
mean
I
feel
like
there's
prior
art
and
like
stuff
like
json
api
or
other
things
where
they
have
concepts
of
the
ability
to.
If
the
client
wants
to
have
the
api
included,
you
can
basically
pass
params
in
a
certain
way
to
it
to
basically
get
that
data
back.
D
B
C
Right
right,
but
is
that
something
that
we
could
like
where
we
could
omit
it
for
now
and
then
add
that
later
on,
if
we
feel
it's
needed,
I
guess
like
I'm,
hoping
to
keep
this
as
simple
as
possible
on
the
first
iteration
you
know,
and
this
little
chunk
actually
yeah
really
changes.
The
implementation.
B
D
Yeah
I
mean
I,
I
know
a
big
part
of
that.
Those
designs
are
to
basically
minimize
the
number
of
api
calls.
B
D
D
C
D
D
It's
kind
of
the
counterpoint,
I
mean
there's
alternatives
to
json
api,
but
I
think,
like
basically,
they
serve
literally
to
solve
this
exact
problem
that
we're
trying
to
solve
here
right.
E
D
But
like
it's
a
basic
standardized
way
on
like
how
the
payload
gets
constructed
of
like
how
you
include
or
exclude,
and
it
centers
around,
like
the
thing
travs
was
shown
before
with
bill
packs
like
resources
right.
So
it's
like.
E
D
Want
to
include
multiple
resources
in
a
thing.
That's
how
I
do
it
if
you
want
to
do
pagination,
if
you
want
to
reference
links
and
other
things
like
it's
basically
standardizes.
What
the
json
payload
should
look
like,
so
adding
in
on
top
would
basically
be
revving
v1
to
v2,
because
it'd
be
a
totally
different,
payload
right.
C
I
guess
I'm
reluctant,
though,
to
complicate
things
and
for
the
sake
of
something
like
that,
because
this
isn't
really
meant
to
be
like
a
very
complicated
api
right
like
this
is
pretty
like.
This
is
meant
to
be.
Very
slim
only
do
a
few
things
if
we're
talking
about
a
more
complicated
api.
I
think
we're
talking
about
a
buildpack
registry
service,
which
is
what
we
were
avoiding,
which
maybe
we'll
do
one
day,
but
then
we're
gonna,
there's
a
whole
bunch
of
other
crap
we're
gonna
have
to
change
so.
B
So
I
think
that's
why
I'm
more
inclined
to
also
be
very
simplistic
in
my
initial
iteration
of
this.
So,
however,
that
looks
just
to
get
started,
and
then
you
know
iron
out.
Those
wrinkles
drive
the
requirements
based
on
how
like
this
rich
ui
experience
might
look
like
that's
actually
consuming
this.
D
C
I
think
I
mean,
I
think,
that's
still
the
case
right
like,
but
what
we're
saying,
though,
is
a
maybe
like
opinionated
ui
like
it's
not
meant
for
arbitrary
uis.
It's
meant
for
one
very
specific
one,
and
this
solves
all
things
we
need
for.
For
that
specific
ui.
It
doesn't
support,
like
a
bunch
of
other
things
that
somebody
else
might
want
to.
C
Do
so,
let
me
ask
this
if
we
were
to
change
latest
to
be
a
link
exactly
the
same
structure
as
what's
in
the
versions,
I
would
would
anybody
vote
against
that.
C
A
C
December
yeah
yeah.
You
can't
anyways,
however,
like
go
down
to
the
go
down
to
the
slash,
build
pack,
slash
namespace
name,
if
you
keep
the
latest
here,
which
I'm
fine
with
that.
Actually
that
would
be
sufficient.
But
if
you
want
to
do
a
slash
latest
too,
I
mean
that
seems
fine
to
me.
I
guess
I
I
would
base
it
on
what
you
think
you'll
need
for
the
ui
like,
if,
if
you
have
a,
if
you
have
a
pack
out
of
a
build
pack,
that
has
a
thousand
versions.
B
Yeah
I
do
like
these
two.
I
think
I
think
these
are
pretty
clean
and
they
make
sense,
but
yeah
talking
through
this
a
little
more.
I
am
torn.
B
B
D
C
C
Oh
because
the
query
doesn't
have
it
yeah,
I
was
thinking
the
query
would
have
it?
Yes,
yes,
I
am
then
okay,
so
personality.
B
C
The
url
or
or
why
parse
it
you
could
you
could
have
the
server
provide
the
the
id
as
part
of
the
the
structure
somewhere
without
having
to
make
without
having
to
go
anywhere
else
to
get
that
information,
but
I
think
from
the
ui.
Yes,
no,
it's
it's
all
the
description,
licensing,
that's
the
stuff
that
complicates.
B
B
I
think
that's
the
biggest
one,
otherwise
I
knew
I
noticed
through
discussion.
Yesterday
there
was
some.
B
D
B
C
B
C
Or
not
from
the
url
but
from
the
like
version,
yanked
an
address
you
can
get
from
the
index
and
it's
not
costly.
D
Are
you
tying
like
basically
the
implementation
detail
to
these
apis?
Because,
if
that's
the
case,
I
think
that
should
be
a
part
of
this
rfc,
then
of
like
not
necessary
details
of
it,
but
like
the
fact
that
you're
tying
what
these
endpoints
should
look
like
based
on
the
burden
of
implementation,
seems
like
this
like
hidden
thing
that
you
keep
pushing
back
against.
C
No,
it
totally
is,
I
feel,
like.
Okay
yeah,
that's
fair.
I
don't
think
that's
inherently
wrong,
though,
like
I
feel,
like
that's
inevitable,.
C
D
I
guess
I'm
curious
like
what
is
the
there's
clearly
like
a
thing
that
is
not
talked
about
in
this
rc,
but
what
is
the
implementation
that
we're
forcing
ourselves
to
stick
to?
That
is
determining
what
we
can
put
and
not
put
in
this
thing.
D
C
C
D
B
And
then,
after
each
successful
get
poll,
it
essentially
re-normalizes
the
in-memory
representation
of
that
of
the
entire
repository
for
the
build
pack
registry,
and
then
it
creates
indexes
on
these
different
fields
like
the
name
space,
the
name
that
can
then
be
easily
searched
against.
A
D
Well,
I
think
it's
pretty
common
for
indexes
to
be
behind
and
registries,
like
they're
gga
kind
of
delay,.
C
Yeah
so
think
about
you
have
a
search
and
you
search
for
the
letter
k
which
matches
all
the
heroku
build
packs
and
the
pacquiao
build
tax.
So
you
get
a
thousand
build
packs
back
and,
let's
say:
there's
no
there's
no
cash!
E
Yeah,
I'm
on
taran's
side,
I
feel
like
the
api
is
very
limited.
As
far
as
search
functionality
goes,
if
we
don't
have
the
additional
pieces
of
data
like
you
know,
something
very
useful
is
description
right
and
the
description
isn't
stored
in
the
registry.
It's
stored
in
the
image,
so
the
like,
when
you're
listing
out
and
even
for
searching
right.
If
you
wanted
a
search
description,
which
I
think
would
be
valuable,
I
think
when
you
get
the
list
back
of
results,
you
want
to
be
able
to
have
a
better
idea
on
what
it
is
versus.
E
Just
the
namespace
and
the
name
right
like
jvm.
Does
this
include
kotlin
right?
Does
it
have
scada,
kotlin
and
and
whatever
like
you,
wouldn't
know
that
until
you
drill
down
and
once
you
get
like
a
whole
bunch
like
if
I
search
for
java
right,
am
I
going
to
be
able
to
get
the
one
that
is
actually
named
jvm
but
happens
to
include
java
in
the
description.
E
A
Right,
I
just
sorry.
The
thing
that's
untenable,
I
think,
is
when
you
do
a
search
only
then
for
every
search
result
that
we
go
and
fetch
the
data
from
the
registry
like
if
the
cache
has
cold.
I
feel
like
that
can't
work.
So
if
the
two
options
are,
don't
return
that
from
the
search
and
do
it
when
people
request
a
build
pack
or
it's
when
I
update
the
index,
kick
off
some
background
drop,
that's
going
to
go
and
populate
this
cache
and
then,
if
you
search
before
it's
populated
you
just
don't
get
that
data.
E
C
D
Ridiculous
to
me,
I
I
mean
I,
I
feel
like
that's
just
the
state
of
how
you
build
an
api
to
back
a
registry
like
this.
This
is
the
way
and
if
that,
if
a
requirement
is
that
we
don't
want
any
of
that
stuff,
then
that's
fine,
but
I
feel
like
that's
not
actually
clear
in
this
rfc,
that
that
is
like
a
hard
requirement
here.
E
B
Yeah,
that's
where
my
head
is
at,
but
I
I
totally
hear
like
especially
javier
in
turns
where
you
guys
are
going
with
that,
because
I
think
down
the
road.
It
probably
doesn't
make
sense
to
have
some
sort
of
relational
database
where
we
can
have
more
meta
data
that
maybe
we
don't
want
to
include
in
the
index
itself
on
the
github
repo
and
you
know,
keep
that
up
to
date
in
caches
and
things
like
that.
D
C
Some
things
differently
right,
I
mean,
I
agree
with
uterus,
but
we
are
doing
some
things
differently.
I
think
the
other
factor
here
is
we're
talking
about
two
people
wearing
the
pager
for
this,
and
until
we're
talking
about
something
other
than
that,
I'm
hard
pressed
to
increase
operational
burden
beyond
a
process,
a
stateless
process.
E
I
mean:
is
there
a
way
to
expand
that
beyond
two
pagers?
Just
because
I
know
I
made
the
proposal
for
just
like
we
do
for
other
infrastructure
pieces,
we
give
it
to
not
just
maintainers
but
contributors
as
a
whole.
E
C
Don't
know
is
it,
though
we're
talking
about
a
description
like
literally
we
are
talking
about
a
description
and
all
of
this
to
get
a
description
like.
I
agree
it's
important
right
and
I
I
hope
we
are
successful,
such
that
people
need
to
be
able
to
search
the
description,
but
in
this
first
take
I
just
feel
like
we're,
adding
a
lot
of
we're
just
adding
a
lot.
If
we're
talking
about
contributors,
I
mean
figuring
out
how
contributors
and
maintainers
access
the
actual
service
and
operate
it
and.
D
D
C
E
C
Live
not
the
query
but
the
not
the
query,
but
the
hits
the
end
point
for
that.
C
I
mean
yes,
I
think
there
are
some
easier
caching
mechanisms
mechanisms
we
could
use,
though,
in
that
case,
rather
than
like
to
do
it
for
search,
you
have
to
have
a
database,
but
for
for
the
like
buildback
endpoint,
you
could
do
an
in-memory
cache.
You
could
do
a
redis
or
something
like
much
simpler.
That's
just
you
know
key
based.
D
C
Every
time
not
if
it's
in
a
redis
but
then
you
but
then
it
you
can
also,
I
think,
with
that
endpoint
you
know
if
something
fails
or
there's
a
cache,
miss
or
whatever
yeah.
D
C
But
I
think
we
can
do
that,
but
I
think
like
having
a
redis
to
to
just
reduce
the
number
of
api
requests
we
hit
or
api
requests
we
make
to
like
docker
hub.
That
is,
that
is
actually
not
as
big
a
deal,
because
if
the
redis
goes
down,
then
you
just
start
making
api
requests.
C
I
think
that's
a
slightly.
That's
that's
enough.
I
think
that's
a
burden
we
can
take
on,
but
I
mean
maybe
I'm
picking
hairs.
I.
B
B
C
Support
what's
what
the
sort
of
like
ideal
api
is
here.
D
Yeah
I
mean
I,
I
will
plus
one
a
thing
if
the
requirement
is
like,
if
one
of
the
goals
is,
we
don't
want
to
run
a
thing,
but
I.
D
Removing
redis
and
other
stuff
because
I
feel
like
you
want
to
minimize
basic
if
the
ultimate
goal
is
to
have
a
serviceable
thing.
That
is
a
single
process
that
doesn't
have
redis.
Then
I
think
that's
fine,
but
I
feel
like
the
moment,
you're
adding
a
another
database
like
like
another.
Like
kind
of
thing
like,
I
feel,
like
you're
kind
of
splitting
hairs
at
that
point,
yeah.
E
E
A
Complexity,
difference
between
populating
that
redis.
In
the
background
versus
on
request,
I
feel,
like
probably
isn't
that
high.
If
that's
the
that's,
the
difference
like
relational
database
for
serratus
might
be
a
big.
B
B
C
So,
let's
do
this,
though,
in
the
meantime,
can
we
leave
it
the
way
it
is
right
now
and
well.
Maybe
that's
not
fair,
I
would
say
you
can
all
vote
on
it
and
then,
if
we
decide
that
we're
not
comfortable
operating
that
thing,
we'll
just
back
out
of
it
or
something
like
that,
but
we'll
just
we'll
just
wait.
B
B
I
don't
have
anything
else.
I
think
this
is
the
big
topic,
so
once
we
resolve
this,
I
think
we'll
be
good
to
go
for
finalized
votes.
E
Sorry
I
I
pulled
up
the
the
mock-ups
that
I
did
for
the
ui
in
and
I
recall
we
talked
about
like
latest
updated
date.
Is
that
still
something
we
want
to
do?
I
know
you
would
be
able
to
maybe
do
that.
I
don't
know
the
exact
complexities
behind
that.
E
The
latest
the
updated
date-
it's
like,
oh.
E
Yeah,
okay
and
that
shouldn't
matter
to
the
conversation
of
whether
we
pulled
the
image
or
not
right,
because
it's
from
the
index
itself,
so
we
should
have
it
on
the
search.
Okay
and
just
for
the
sake
of
brevity.
This
is
the
the
mock-up
I
was
talking
about
right.
So
having
you
know,
possibly
description
and
license
would
be
great,
but
that's
a
separate
conversation.
E
Then,
when
we
drill
into
this
right.
If
you
look
at
some
of
this,
we
do
talk
about
supported
stocks
and-
and
I
know
like
it's
really
weird,
because
we
don't
have
this
information
about
like
yeah.
Well,
we
kind
of
do
but
yeah
anyways,
like
you
could
look
at
this
and
we
could
talk
about
it
further,
for
maybe
the
next
iteration.
E
I'm
thinking
long
term
we'd
wanna
also
index
builders
to
some
degree,
because
otherwise
I
don't
know
what
I
could
use
this
build
pack
with
builders
or
stacks
builder.
Well,
that
I
think
that's
part
of
the
conversation
right.
How
do
we
really
do
that?
Because,
essentially,
we
use
builders
in
a
lot
of
places,
but
ultimately
they're
composed
of
stacks
and
the
stacks
that
would
have
that
information.
A
E
Yeah
yeah
you're
right.
I
think
I
was
jumping
ahead
and
thinking
about
the
builders
or
how
I
would
actually
like
this
doesn't
tell
me
an
image
I
can
use
right.
It
just
tells
me
this
like
abstract,
or
I
guess
specification
of
an
id.
F
E
E
D
Yeah
this
is
this-
has
just
been
that
draft
that
I
guess
we
put
back
in
the
draft
and
I
just
want
to
we've
been
making
some
headway
on
some
stuff
internally
for
this.
So
I'm
just
want
to
bring
it
back
before.
I,
I
guess
make
some
changes
to
the
rfc
of.
D
Are
we
still
okay
with
or
what
are
people's
thoughts
on?
I
guess
just
making
stuff
outside
of
the
project
and
build
tables
flexible,
basically
changing
rc
to
remove
the.
D
I
think
the
controversial
like
project
kind
of
whatever
figure
out
the
table
name
thing
and
just
the
piece
that
is
like
somewhat
could
be
project
descriptor
compliant,
but
they
have
to
basically
comply
with
the
two
tables
we've
already
defined
and
we
can
change
those
at
will
and
we
don't
make
guarantees
about
not
adopting
new
stuff,
but
those
other
table
names
are
flexible.
B
E
F
I
think
the
disadvantage
there
is
that
it
forces
every
new
key
at
the
top
to
be
a
major
version,
change
for
the
file
instead
of
a
minor,
so
so
every
chain,
every
new
key
at
the
top,
is
considered
a
breaking
change
if
we
version
it
like
that,
right
or
like
that,
it's
the
same
thing
as
if
you
didn't
same
result
as
if
you
didn't
have
versioning
right,
the
user
still
has
to
do
something.
It's
just
communicated.
You
know.
F
D
Yeah
so
I
mean
I
guess
the
advantage
for
like
the
salesforce
side
is,
we
could
have
like
a
salesforce
key,
which
I
assume
the
bill
pack
project
would
never
take.
A
I
feel
like
one
other
concern
would
be:
let's
say
a
couple:
different
platforms
then
go
ahead
and
define
top-level
keys,
but
they
define
them
differently
now.
Can
you
not
push
your
app
to
different
platforms
because
they
have
different
meanings
in
a
way
that
could
cause
problems.
D
Is
that
any
different
if
they
did
the
same
thing
under
metadata
like
if
you
basically
just
replicated
that
functionality
but
name
space
it
under
metadata
and
platforms,
interpreted
the
things
and
metadata
differently
like
as
it
exists
today
that
the
statement
you
said
is
also
true
right
like
if,
under
metadata,
I
defined
a
table
that
was
like,
I
don't
know,
function,
endpoint
or
something,
and
I'm
a
faz
and
two
platforms
somehow
came
to
the
same
name
under
there
and
then
basically
handled
the
schema
differently.
A
Yeah,
I've
never
really
imagined
platforms
using
the
metadata,
if
I'm
being
honest,
it's
more
like
other
than
to
like
read
and
display
it.
I
know
we
have
built
packs
that
use
their
own
metadata.
F
A
Suggest,
like
maybe
a
slightly
different,
similar
to
just
putting
things
under
metadata,
but
if
we
had
a
platform
table
and
then
we
said
that
platforms
should
reserve
a
key
under
platform,
I
think
we
don't
have
to
worry
too
much
about
those
conflicting.
It's
like
platform.heroku,
but
you
can
put
whatever
you
want
in
there
and
then
you
could
all
you
could
have
one
app
or
you've
committed
a
project
tunnel
where
that
same
app
could
be
pushed
to
a
variety
of
different
places.
F
D
D
Well
like
for
like
salesforce,
implies
you'd
want
to
put
everything
under
just
salesforce,
but
if
you
make
it
open,
potentially
you
would
make
a
config
that
feels
more
native
platform
that
may
not
just
be
salesforce.
It
would
be
like
here's
function.
Configuration
here's
like
salesforce
has
a
bunch
of
products
right
so,
like
here's,
a
commerce
cloud
kind
of
configuration
versus
having
to
deeply
nest
everything
under
a
platform
that
then
like
starts
underneath
it.
If
that
makes
sense,.
D
Keys,
I
mean
yeah,
I
don't
know
if
we
have
that
today,
but
I
think
product
wants
that
flexibility.
F
We
could
we
could
like
say
that
keys
that
start
with
something
are
reserved
at
the
top
level
for
platforms,
as
opposed
to
you
know,
exact
key
names
so
like
platform
dash.
If
the
top
level
table
is
named
platform
dash,
then
it's
you
know
we're
never
going
to
claim
anything
at
the
top
level.
It
starts
with
platform
dash
right
and
then
you
could
have
platform
dash,
salesforce
functions
platform
dash
whatever
I
don't
know.
If
it's
the
prettiest
solution
in
the
world,
but
it
you
know,
meets
those
requirements,
sort
of.
F
E
I
mean
what,
if
we
did
the
opposite,
and
it
was
that
you
know.
Cnb
was
a
thing
within
project,
descriptor
right
and
then
anything
else
above
it
could
be.
You
know
free
for
all,
essentially
for
any
other
sort
of
platform
or
whatnot,
but
then
under
cnb,
then
you
have
build
and
and
all
this
very
you
know,
cnb
specific
stuff
and
so
we've
grouped
it
and
we've
allocated
a
namespace
essentially
for
us
and
then
others
could
crea
create
additional
namespaces
throughout
at
the
top
level.
F
It's
the
spec
for
project
hummel
would
be
weird
a
little
bit
then
or
like
it's.
What
that's
communicating
is
like
here's,
a
file.
There's
you
know
it's
because
it's
it's
called
project
tomlin.
It
seems
like
it's
like
it's
a
little
more
general
than
just
build
right,
we're
saying
here's
a
file
to
describe
your
app.
The
only
reserve
key
has
to
do
with
building
the
app
and
no
one
can
ever
you
know.
No
no
project
can
ever
say.
F
E
I
mean
I
feel
like
this
there's
kind
of
like
conflicts
on
on
both
sides,
whether
project
descriptor
is
like
agnostic
to
cnb
or
if
it
is
a
definition
of
the
things
that
the
cnb
project
cares
about
and
then
we're
just
allowing
others
to
add
their
information
as
well
right.
So
I
think
those
are
on
two
different
spectrums
and
I
don't
know
that
we've
answered
that.
I
think
joe
has
one.
You
know
like
one
preference,
but
I
feel
like
we're
at
this
moment
kind
of
on
the
other
side
right.
F
D
Yeah,
I
mean,
I
guess
part
of
this-
comes
from
not
wanting
to
have
yet
more
files
for
configuration
to
some
degree,
especially
because
already
in
the
project,
scripter,
there's
and
even
as
we
add
more
stuff,
especially
when
you
think
about
stack
packs
on
other
things.
I
I
feel
like
to
some
degree.
The
things
that
are
being
advocated
is
like
sales
sources,
just
have
a
salesforce.tamil
that
is
separate.
F
F
You
know
file
looks
one
way
and
it
it's
only
for
salesforce
platforms
right
and
if
you
have
a
you
know,
project
tamil
filed,
then
that
specific
kind
of
configuration
you
know
it's
more
generic,
but
the
salesforce
specific
configuration
has
to
be
platform,
not
salesforce
at
the
top
level.
Then
it's
the
user
chooses
whether
or
not
their
app
is
portable.
F
A
I
was
looking
for
this
prior
art.
I
remember
seeing
I
just
found
it.
There's
a
python
file
called
pi
project
tamil
that
has
a
tool
table
and
then
a
bunch
of
tools
have
their
own
schema
under
the
tool
table.
So
it's
like
tool.poetry
is
defined
by
the
poetry
project.
For
how
that
interacts,
I
thought
I'd
throw
that
out
there
as
an
example
that
would
be
similar
to
the
platform.
E
A
A
A
D
Yeah,
I
mean
it's
a
reasonable
suggestion.
I
think
the
the
only
part
that
gets
kind
of
scary
is
like
when
you
have
to
do
array
stuff
and
you
have
to
repeat
table
names
and
you're
typing,
like
potentially
three
nested,
like
two
dots
in
that
thing,
because
it's
like
platform.salesforce.something
else.
A
E
D
So
what
I'm
getting
is
you're
pretty
against
opening
up
the
top
level
keys.
A
E
E
A
A
D
A
Have
a
project
tunnel
in
there,
but
imagine
a
world
where
we
did
where
we're
trying
to
like
into
some
of
these
canonical
examples
like
push
easy
build
pack
configuration,
we
wouldn't
want
to
pick
a
platform
winner.
So
if
platforms
had
to
find
these
different
keys
differently,
then
it
rather
than
being
able
to
support
everything
you'd
have
to
pick
one.
E
But
I
think
best
practices
right
in
convention,
like
almost
naturally,
would
make
each
platform
sort
of
create
their
own
namespace.
D
I
know
we're
over,
so
if
people
need
to
go,
we
can
cut
this
short,
and
I
can
just
talk
to
emily
and
javier
about
it,
but
the
I
know
there
was
talk
at
least
from
rpm,
who
was
kind
of
doing
this
work
of
like
if
there
is
something
like
function,
it'd
be
nice
if
we
could
standardize
that
across
actually
all
the
platforms
and
have
that
be
a
thing
of
like,
is
there
a
way
we
could
standardize
like
that
kind
of
level
configuration
if
the
namespace
does
collide,
because
right
now
that
doesn't
exist
today
and
it's
kind
of
a
nightmare.
D
E
So
it
seems
like
if,
if
we
go
down
the
route
where
project
descriptor
is
not
the
cloud-native
build
packs
file,
but
maybe
its
own
standalone
thing,
then
I
think
a
lot
of
that
makes
sense
right
where
we
want
to
standardize
across
different
platforms,
different
tools
and
and
all
that-
and
I
think
that
would
be
overall
good,
but
then
to
kind
of
keep
that
kind
of
notion
of
having
you
know
that
build
packs,
yaml
file
or
something
that
is
very
project
specific.
E
But
then
pack
would
more
or
less
just
look
for
the
build
packs,
because
it
doesn't
really
care
about
the
other
stuff
right
unless
you're
thinking
and
proposing
otherwise,.
D
E
I
think
pack
would
just
look
for
the
build
packs,
tumble
right,
and
so
then,
if
you
wanted
to
incorporate
this
into
like
this
bigger,
you
know
more
standardized
project,
descriptor
and
then
those
platforms
that
do
support,
project,
descriptor,
right,
hypothetically,
like
heroku
or
or
I
don't
know
tons
of,
then
you
could
create
the
project
descriptor
file
and
then
within
that
project,
descriptor
define
or
or
point
to
the
build
packs
file.
E
D
Where
does
stuff,
I
guess
like
some
of
the
stuff
that
feels,
I
guess
off
to
some
degree
with
that
is
like
where,
like
would
the
project
table
go
in
that
bill?
Pax
toml,
because
that.
E
E
E
I
think
yeah,
so
I
think
source
url
and
licenses,
so
it
might
make
sense
for
those
and
that
that
might
be
the
thing
that
kind
of
makes
this
solution
not
work
but,
like
I
feel
like
everything
else
like
build
related,
is
like
a
very
specific
cnb
thing.
Right
like
I,
I
can't
see
anything
in
the
build
area
being
agnostic
to
any
other
platform
or
any
other
system.
D
Yeah,
I
think,
having
the
build
stuff.
There
is
the
part
that
for
sure
a
lot
of
folks
want,
because
it
includes
how
to
build
your
app.
D
Yeah,
that's
something
like
a
core
part
of
like
when
I
think
of
I
guess
I
think
of
like
I
don't
know
how
familiar
with
I
guess
like
app
json
from
heroku
or
some
of
our
other
attempts
of
kind
of
doing
some
of
that
stuff.
When
you
think
about
writing
a
file
like
that,
you
definitely
want
the
build
stuff
because
it
includes
stuff
like
yeah
the
build
packs
of
like
this
is
how
you
build
it,
but
then
also
like
environment
variables
are
used
at
build
time.
D
E
D
Yeah,
I
think
it
is
just
because
that's
what
we
expect,
and
that
was
the
easiest
thing
to
get
through
at
the
time,
but
you
can
imagine
like
an
equivalent
thing
where,
instead
of
build.buildpax,
it
was
like
build.dockerfile
and
it
pointed
to
some
docker
file
right
and
it
wasn't
even
like
a
table
right.
You
just
do
build.file
equals
path
or
something
right.
E
D
E
We've
talked
in
the
past
about
how
the
proliferation
of
docker
files
kind
of
does
promote
the
docker
ecosystem,
where
we
may
want
something
like
build
packs
that
you
know
kind
of
does
the
same
thing
for
the
build
packs
project,
and
then
I
think
that's
where
I
was
trying
to
maybe
marry
the
both
of
them,
but
I
think,
if
we're
trying
to
be
inclusive,
it
seems
weird
that
the
cloud
native
build
packs
project
is
creating
a
generic
file
for
every
platform.
If
I'm
being
honest,
that
just
doesn't
see,
I
feel
like
we're
struggling
a
lot
right.
E
D
Yeah,
I
feel
like
part
of
the
the
difficulty
with
that.
Is
you
either
can
project
tamil
but
then
you're,
forcing
basically
everyone
to
create
get
another
file
right,
because
at
that
point
you
would
basically
be
like
nope
like,
like
we
probably
wouldn't
even
have
project
like
get
rid
of
the
project.
D
Key
like
don't,
have
a
build
key
just
have
bill
pax
key
and
whatever
other
kind
of
keys
at
the
top
level
right
like
if
you're
looking
at
what
it
is
today
and-
and
we
want
to
do-
I
think
that
suggestion
right,
like
I
feel
like
if
pac
is
not
using
any
of
that
stuff
like
not,
that
pac
is
the
only
platform,
but
it's
like
it's
not
even
really
about
the
platform.
At
that
point,
it's
like
what
does?
What
does
the
bill
pack
project
need
to
know
to
build
your
thing?
That's
right
right!
D
I
know
it
like
to
some
degree
I
feel
like
docker
files.
Very
specifically
docker,
though
right,
like
there's
no
way
to
insert
metadata,
is
100
just
a
build
file
and,
to
some
degree
I
feel
like
build
packs,
because
dockerfile
doesn't
the
stuff.
I
think
we
put
in
buildpack
like
project
tamil
is
none
of
the
stuff
that
really
goes
into
a
dockerfile
right,
like
all
the
stuff
that
would
mostly
go
into
a
dockerfile,
goes
into
the
bill
pack
itself
that
a
bill
pack
author
creates
but
stuff.
That's
like
what
even
like.
D
E
Like
the
multi-stage,
build
yeah.
D
Kind
of
stage
stuff
where
you
like
from
and
then
like.
Eventually
you
build
the
container,
but
it's
still
like
very
tied
to
like
it.
It's
kind
of
a
weird
analogy,
because
it
it
mixes
like
implementation
with.
Basically
some
like
it's
like
marred
in
the
it's
like
baked
into
the
implementation
right,
yeah.
E
D
How
you
piece
that
stuff
together
but
like
if
you
want
to
say
like
exclude
files,
that's
docker,
ignore
right.
It's
a
separate
file.
So,
to
some
degree
I
feel
like
the
docker
file
thing
is
it
is.
It
is
a
it
is
what
it
is
mostly
akin
to
bill
packs
in
our
world.
I
think,
for
the
most
part.
D
And
like
how
you
even
manage
like
docker
file,
dot
like
multiple
docker
files
is
like.
That's
your
problem
right
or
how
you
pass
environment
variables
like
gotta.
Do
that
via
cli,
like
there's,
no
file
that
allows
you
to
kind
of
automate
that,
like
create
a
makefile,
make
that
happen
right.
E
Yeah
so
I
mean
yeah,
I
definitely
agree
and
I
think,
if
we're
only
going
to
be
losing
that
sort
of
notion
where
we
can
have
a
buildpacks.tamel
or
whatever
I
mean,
we
don't
technically,
have
that
right
now,
right
and
so
no.
D
Right
now
it's
called
project
tamil.
We
also
don't
push
it
very
hard
right
right.
I
think
it's
gonna.
I
think
it's
gonna
change
when
stack
packs
and
their
stuff
come
into
existence,
because
you'll
want
to
do
mix,
ends
and
other
things,
and
so
I
think
that
would
you
because
people
want
that
function
like
there's,
basically,
nothing
today
that
you
need
to
use
a
project
tunnel
for,
for
the
most
part
for
most
people,
doing
like
a
like
getting
started,
build
right
like
pac
lets.
D
You
do
a
lot
of
stuff
by
definition
or
by
design
like
you,
can
pass
all
these
as
arguments
right
to
yeah.
So,
like
you
technically,
if
you
never
learned
about
project
thomas,
you
don't
need
it,
and
you
could
probably
just
write
your
own
make
file
that
like
wraps
pack
with
the
right
flags
and
you
never
needed
project
tom,
all
right,
yeah
and
that's
kind
of
just
been
core
of
like
what
we
wanted.
You
know
and
private
is
just
like
a
way
to
basically
pull
that
together
and
something
you
could
check
in.
D
E
E
Thought
that
far
yet
definitely
haven't
thought
that
far,
but
now,
because
I'm
thinking
about
it,
I'd
I'd
like
to
see
what
one
of
these
you
know,
tumor
files
ends
up
being
looking
like,
because
I
think
that
maybe
at
some
point
there
may
be
a
shift
where
we
say,
like
certain
arguments
are
available
via
the
cli
and
maybe
even
all
of
them.
But
I
think
that
in
a
lot
of
cases
it
would
just
make
more
sense
to
say:
okay,
just
point
us
to
the
project
descriptor
or
just
create
a
project
descriptor
file.
E
If
you
really
need
to
you,
know,
adjust
some
of
these
things
and
from
a
ux
perspective.
That
would
be
a
lot
nicer
than
having
to
like
know
all
these
flags.
You
have
to
pass
in
every
single
time
just
to
build
your
project
right,
so
just
from
a
better
practice
that
might
be
overall,
a
much
desired
state.
D
Yeah
I
mean,
I
know
like
a
big
thing
so
like
we
introduced
app.json,
but
one
of
the
complaints
was
that
you
can't
get
bush
with
it.
It
was
just
for
like
rook
button
and
people
really
wanted
a
way
to
be
like
I,
I
want
to
define
the
stuff
in
app
json
part
of
my
build.
I
don't
want
to
like,
because
basically
equipment
was
like
you
had
to
literally
run
like
heroku
commands
to
get
the
same
functionality
and
just
like.
Let
me
check
in
so
like
when
someone
else
clones.
E
D
Of
set
up
infrastructure,
I
guess
you
have
like
terraform
now,
where
you
can
do
it,
but
there's
downsides
for
interest.
I
guess
like
services
and
things
that
aren't
like
kind
of
designed
to
work
in
a
terraform-like
fashion,
because
there's
it
you
know,
like
a
a
service,
can't
make
guarantees.
If
like
what
is
what
happens
if
this
thing
fails
when
it
tries
to
set
this
up,
do
you
like
bail
out?
Do
you
try
to
recover
from
it
like?
E
Yeah
for
sure,
and
and
I
mean
we
even
had
an
issue
recently
for
like
gid,
where
we
wanted
to
add
that
as
a
pack
argument-
and
you
know
I
thought
about
like
it'd-
be
kind
of
weird-
if
you
needed
it
for
this
specific
project
to
have
a
very
specific
gid.
E
But
then
it
only
works
on
pac
right
and,
like
you,
wouldn't
be
able
to
then
build
it
appropriately
with
the
same
parameters
in
something
like
tekton
or
you
know,
heroku
and
all
that
stuff.
So
it's
just
a
very
interesting
problem
that
I
do
think.
Maybe
we
should
be
leaning
more
towards
project
tamil
long
term.
D
I
mean
I
assume,
you've
thought
about
this
too,
just
like
in
that
particular
case,
it's
like
when
we
talk
about
even
like
salesforce
as
a
platform
for
doing
cb
or
heroku
or
tenzu
right.
It's
just
like
in
that
particular
case
for
pack
like,
should
there
be
a
thing
that
is
like
not
spec
now
saying,
project
descriptor
but
like
that
is
like
pac,
defines
a
schema
of
like
configuration
for
something
like
gid,
where
it's
like.
If
you
build
this
with
pac
like
it
functions
this
way,
because
you
want
it
to
work
that
way
right.
C
D
It's
specific
to
like
local
docker
or
blah
blah
blah
or
even
potentially,
some
of
the
stuff
we
have
in
pac
config.
That
is
not
like
a
global
level
setting,
but
as
a
project
level,
setting
could
go
in
kind
of
a
project,
tom
all
kind
of
key
or
table
space,
and
I
feel
like
we're.
The
service
is
not
the
right
word,
but
we're
definitely
not
pushing
project
descriptor
forward
by
not
having
pac
be
a
platform
that
can
leverage
it
beyond
the
stuff.
That's
in
the
spec.
E
E
E
So
therefore,
any
you
know,
platform
that
uses
a
builder
would
be
able
to
support
it
and
and
so
on,
right
so
yeah,
but
I
could
definitely
see
in
in
you
know
in
the
future,
like
certain
features
as
spec
grows,
where
it
is
very
specific
to
pac
if
pac
run
ever
becomes
a
thing
right,
for
instance,
that'd
be
nice.
D
As
well
or
if
you
potentially
support
multiple
well,
actually,
maybe
that's
a
global
configuration
of
just
like
the
multiple
ends
right.
Does
that
work
on
the
runtimes.
D
B
E
Yeah,
I
think
that
that's
more
based
on
like
local
development,
machine
versus
yeah
versus
anything
else.
I
I
think
we
could
talk
about
this
for
a
while,
but
I
am
curious.
You
know
we
talked
about
the
project
descriptor
being
maybe
more
generic
and
how
we
kind
of
limiting
it
to
build
packs
might
be
the
wrong
way
to
go
about
it.
I
know
joe
was
a
proponent
and
and
thought
about
the
project
descriptor
being
its
own
essentially
project
as
weird
as
that
sounds.
E
Is
that
something
that
is
no
longer
desired
completely
or-
or
I
guess
do
you
know
what
happened
there.
D
I
think
it
just
got
put
on
the
back
burner
for
priority
and
other
reasons
like
basically,
we
asked
we
asked
the
app
delivery
sig
and
the
cncf
like.
Do
you
have
a
thing
we
can
build
on
top
of
instead
of
us
creating
our
own
thing,
I
feel,
like
everyone
hates
having
multiple
files,
but
not
enough
that
you
just
create
your
own
file,
because
it's
easier
right.
D
It's
it's
like
it's
the
people
problem
right,
it's
just
like
so
like
you
know,
it
was
just
like
that
and
it
was
just
like
well.
D
It
seems
like
actually
a
lot
of
the
configuration
here
is
at
least
some
of
it
that
we
would
want
is
generic,
like
I
guess
I
was
thinking
of
when
you
look
at
your
like
even
packaged
json
or
cargo
tommel,
like
you,
have
all
this
like
identifying
information,
but
it's
fine,
it's
like
per
for
that
specific
language
right,
and
so
that
was
part
of
the
design,
at
least
of
that
project
table.
It's
just
like.
D
You
probably
want
some
of
that
info,
because
it's
like
a
app
or
something,
but
I
guess
if
we
were
to
go
and
kind
of
sunset,
that
kind
of
idea,
I
would
probably
rip
all
that
stuff
out
right
like
you
just
you
don't
need
it.
D
I
probably
would
just
rip
out
that
table
like
we
don't
need
it.
We
don't
even
need
nest
stuff
under
build,
probably
maybe
we
do.
We
probably
would,
because
maybe
you
want
to
have
stuff
at
run
time
or
something.
D
Stuff,
maybe
we'll
see
but
yeah
I
mean
so
I
think
that
was
kind
of
the
the
impetus
for
that.
But
then
it
was
just
like
I
don't
know
just
like
as
a
project.
It
never
became
a
priority
to
kind
of
push
it
to
some
degree
and
even
people
who
use
bill
packs
a
day
like,
I
guess
forget,
like
generic
adoption,
just
like
still
trying
to
get
adoption
within
people
who
are
using
bill.
Fax
right
of
the
file.
D
D
How
you
do
it
on
each
platform
right,
like
salesforce,
will
have
their
thing
and
clearly,
as
we
add,
more
features
and
stuff
like
they
will
need
parts
of
project
tom.
All
so
like
do
you
just
pat?
Do
you
just
have
a
thing
and
then
like
implement
what
you
need
to
do
to
pass
the
life
cycle
assuming
you're,
not
using
pack
under
the
hood
and
then
like?
D
I
like,
on
the
salesforce
end
for
implementation
right,
like
our
remote
build
service,
doesn't
use
pac,
but
the
local
cli
that
we
have
it
uses
docker
so
like
there's
no
benefit
to
rebuilding
all
the
work
pack
has
done
so
we're
you
know
using
pac
as
a
library
common
practice.
You
know
we've
yeah
people
do
that,
and
so
it's
just
like
it
would
be
nice
to
like
from
our
from
my
perspective,
from
engineering,
wise
and
from
kind
of
a
business
perspective.
D
It's
like
it
would
be
nice
if
the
thing
we
have
is
compliant
and
works
with
that
stuff,
because
we
want
it
to
work
natively
with
pac,
even
if
the
file
name
is
different
right
and
we
can
kind
of
pass
that
stuff
and
use
the
library
under
underneath
and
then
they
basically
have
to
make
no
changes
when
they
move
from
local
development
to
like
using
a
rope,
build
service
from
us
right
and
that's
kind
of
the
kind
of
desire
and
design
and
there's
going
to
be
stuff
in
there.
That's
salesforce
specific.
D
You
know
like
to
the
platform
like
one
the
example
we
have
is
like
permission
sets
between.
Basically,
this
function
that
you're
building
and
the
like
salesforce
org
itself,
right,
which
pac
or
cmb,
does
not
care
whatsoever
about
right
right.
But
for
that
one
particular
piece
of
configuration,
you
want
me
to
make
lily
a
separate
tamil
file
to
like
put
that
in,
but
it.
But
it
is
like
important
to
the
configuration
of
the
project
and
I
feel
like
building
all
that
stuff
for
how
you
build.
D
D
D
And
that's
like
from
the
product
side
like
originally,
I
proposed
the
thing
internally.
That
was
like
we
just
put
this
in
metadata,
but
then
they're
like.
Why
would
we
make
a
thing?
That's
called
like
a
salesforce
total
or
something
that
then
forces
you
to
put
everything
that
is
sales
for
civic
inside
of
another
table.
That,
like
makes
it
feel
like
a
second-class
citizen.
D
So
then
the
so
then
what
happened?
Was
we
literally
forked
project
tamil
and
changed
like
two
things-
and
I
was
just
like
this-
is
so
then
like?
What
now
we
have
to
do
is
we
will
have
to
transform
stuff
to
make
it
work
natively
with
pack,
and
I'm
like
this
is
silly
like
we
should
just
make
it
compliant
and
then
figure
out
a
way
to
like
not
upstream
what
specifically
we
want,
but
a
way
that
allows
us
to
build
on
it
as
like.
D
E
Cool
so
so
you're
not
on
the
extremist
side.
Like
me
right
where
I
feel
like
we're
stuck
in
the
middle
and
I'd
either
like
for
us
to
have
like
a
build,
packed
table
and
just
have
build
packs,
specific
information
or
the
other
side
where
it's
like
project
descriptor
and
it's
a
whole
different
project.
And
it's
like
you
know
something
more
well
defined
and
versatile
for
others
to
consume,
and
the
cmb
project
just
happens
to
not
only
endorse
but
actually
use
that.
D
C
D
You're
coming
from
from
both
those
things
and
those
make
sense
too
right,
like
I
think
all
those
are
valid
paths.
That's
just
not
like
the
angle
where
the
my
our
business
use
case
is
coming
from
of
like
we
need.
D
We
need
cmb
to
either
like
make
a
thing
here
or,
or
do
that
like
we,
we
have
a,
I
think,
there's
a
path
where
we
can
continue
to
use
it,
but
then,
like
basically
make
it
extensible
for
us
yeah,
but
the
I
mean
if
we
went
down
to
kind
of
like
a
separate
project
thing.
I
don't
know
I
I
guess
like
I
don't
know
exactly
what
that
would
look
like.
D
If,
basically,
nothing
else
is
adopting
it
yeah
or
whatever
I
feel
like
part
of
it
is
just
like
we're
still
trying
to
grow.
Cnb
adoption
like
I
don't
know
how
much
you
use
or
how
involved
you're
with
the
tanzu
build
stuff
but
like
where
does
where
do
people
configure
sufferer
tanzo?
D
Are
you
I
thought
I
heard
vmware's
not
using
project
home
at
all.
E
Yeah
yeah,
so
there's
like
a
gui
and
all
that
stuff.
So
there's
like
a
central
command
center.
I
think
that's
interesting
cool.
I
mean
yeah
like
to
me
still.
The
best
one
would
probably
be
like
I'm
thinking
long
term
like
I
see
why
we're
kind
of
stuck
in
the
middle
we're
kind
of
having
to
dog
food
at
first
before
you
know
pushing
it
out
right
it
might.
We
might
find
that
it's
not
really
as
useful
as
we
want
it
to
be.
E
But
if,
if
that
is
the
trajectory
right,
then
I
would
say
like
it'd,
be
again
very
opinionated,
but
I
would
have
like
a
cnb
top
level
key
and
then
put
build
inside
of
that
cmb
stuff.
Because
again,
this
structure
here
is
very
specific
to
the
cmb
project,
and
then
we
would
have
what
is
it
project
and
cnb
as
the
only
two
reserved
keys,
and
then
we
could
do
whatever
we
want.
E
As
far
as
like
minor
version
specs
for
the
cnb
right
or
at
that
point
like
it
could
be
specked
in
a
way
where
c
and
b,
like
that's
completely
different
structure,
managed
by
our
project
right
right.
But
then
you
could
have
heroku
and
then
the
heroku
structure
is
managed
by
rok
or
salesforce
right
and
and
you
don't
have
to
worry
about
it
and
at
the
high
level.
The
project
descriptor
spec
is
just
saying
these
are
the
three
reserved
keys,
and
these
are
the
things
that
are
kind
of
pre-allocated
yeah,
how
you
use
it.
Yeah.
D
E
D
E
D
E
E
D
That
that
would
be
pretty
cool,
actually
yeah,
I
don't
know,
I
definitely
am
plus
one
that
direction.
I
just
don't
know
if
the
rest
of
the
team
is.
E
Yeah
yeah,
I
guess
I
I
again
I
didn't
hear
too
much.
I
don't.
D
Think
they
strong
push
back,
it's
the
classic,
we're
talking
about
our
an
rfc.
So
let's
talk
about
everything.