►
From YouTube: OCI Weekly Discussion - 2023-01-05
B
C
E
D
D
B
Sure
so
I
know:
we've
we've
been
beating
the
horse
on
this
topic,
but
reference
types
group
is
closed
and
are
suggested.
Changes
made
it
into
the
necessary
place
and.
B
We
have
we
have
these
GitHub
Milestones,
with
some
things
to
to
close
out
I
guess
I
just
want
to
get
a
general
gauge
from
especially
like
the
registry
providers
of
the
world,
like
we
talked
about
at
the
end
of
the
month
for
the
cloud
native
security
con
potentially
doing
a
release,
I
can
definitely
put
an
effort
to
get
the
conformance
stuff
off
the
ground,
but
how
do
we
feel
about
actually
doing
a
release?
C
I'm,
not
yeah,
I
mean
I,
have
a
PR,
open
and
I.
Think
Brandon
and
I
are
going
back
and
forth.
Well,
we
were
I
have
not
paid
attention
in
the
last
week
or
so,
but.
C
I
t
l
Dr,
don't
want
to
add
annotations
in
the
referrer's
response
and
Brandon
thanks
that
sucks
and
I
think
we
may
be
at
an
impasse.
So
I
don't
know.
Let
me
find
the
link.
A
A
My
gut
reaction
is,
if
it
if
this
went
out
without
including
the
annotations
within
the
oci
index
response
that
we
get
back,
that
I
would
probably
do
something
client-side
to
put
in
there
and
just
ignore
the
reverse.
Api.
F
I
don't
know
John
does
that
seem
that
bad
I
think
the
the
last.
The
last
comment
on
one
of
these
is
I.
Think
it's
reasonable,
John's,
saying
I
think
it's
reasonable
to
expect
clients
to
do
some
work
here.
I
think
that
more
or
less
is
what
you're
describing
right.
The
client
would
do
some
work
that
the
client
wants
to
do
to
make
this
into
a
format
that
they
can
process
better.
F
I'm,
not
I
I,
don't
think
that's
so
bad
as
a
workaround.
G
I
think
it's
quite
bad
I,
sorry
I'm
an
outside
developer,
using
oci
I'm,
an
engineer
at
palumi
and
we're
looking
at
using
oci
registry
as
a
distribution
mechanism
for
plugins
and
I.
Agree.
I've
read
through
the
thread
with
with
Brandon
and
John,
and
if
the
refers
API
doesn't
return
annotations
and
we
have
a
wide
variety
say
of
different
types
of
artifacts
being
referred,
then
we
have
to
make
a
select
n
plus
one
effectively
against
the
registry,
and
this
is
particularly
bad
for
rate.
Limited
Registries.
G
Right,
like
this
blows
up
your
Docker,
Hub
or
ghcr
token
rate
limits
extremely
quickly
and
the
the
compromise
I
think
would
be
probably
those
Registries
would
they
would
not
want
to
I
think
you
know
omit
some
API
calls
from
rate
limiting
right,
so
we
would
have
to
end
up
not
using
the
refers
API.
We
would
have
to
use
a
special
tag
format
and
push
our
own
indexes.
F
So
so
I
think
I
think
yeah
that
totally
that
totally
makes
sense.
Nobody
wants
to
require
folks
to
make
n
plus
one
requests
to
to
get
this
part
of
John's
proposal
was
to
instead
of
the
annotations
use.
The
data
field
that
already
exists
and
say
registries
I
forget
the
exact
phrasing
we
have
so
like.
Don't
listen
to
this
as
as
word,
but
Registries
can
respond
with
the
data
field,
including
the
entire
manifest,
which
includes
the
annotations
and
much
more
so
a
client
could
expect
the
registry
to
give
all
of
that
back.
F
F
I
think!
That's!
That's
my
that's
my
sort
of
best
guess
at
how
we're
going
to
un
Log
Jam
I'm
curious
again,
if
John
or
Brandon
think
that's.
C
I
have
a
question
for
I
think
it
was
Aaron,
the
so
n
plus
one.
Certainly
a
problem.
Will
you
say
if
artifact
type
filtering
existed?
Is
that
sufficient
to
help
you
out
or
do
you
anticipate
there
being
say
dozens
of
things
that
you'll
need
to
check
like
what
are?
What
are
you
trying
to
do
here
and
what
would
you
put
in
annotations
that
you
need
on
this
response?
If
you
can,
if
you
can
say
yeah
I.
G
Think
I
think
already
we're
seeing
some
conversations
about
things
like.
G
What's
the
appropriate
artifact
type
for
s-bomb
was
a
was
a
active
thread
and
whether
or
not
we
can,
what
that
type
is
going
to
be
is
is
going
to
return
one
or
potentially
many
different
s-bomb
types
for
our
case,
it
would
probably
be
n
would
be
at
least
so
on
the
order
of
probably
at
least
six,
because
we're
targeting
the
tuples
of
every
OS
and
architecture
that
we
support,
So,
Windows,
Mac,
Linux
and
x86
and
arm64,
and
it's
been
a
little
uncertain
whether
or
not
we
should
use
the
platform
field
in
that
case,
because
we're
not
technically
publishing
like
Docker
layers
or
Docker
image
manifest
or
publishing
artifacts.
A
F
Is
would
it
be,
would
you
accept
a
change
to
this
PR
Brandon?
That
said,
Registries
must
do
a
or
b
and
may
do
a
or
b.
D
F
Let's
start
with
John
John:
why?
Why
is
that
a
bad
idea.
C
I
want
the
registry
to
be
able
to
make
decisions
about
this
so
like
if
you've
pushed
something
that
is
very,
very
large,
always
inlining.
That
is
probably
a
bad
idea,
especially
if
you're
not
going
to
fetch
it
as
a
client.
But
if
an
artifact
is
small.
E
F
I
think
I
think
my
proposed
language
covers
that
case.
Like
a
registry
implementation,
May
return,
A
or
B
on
a
per
request
basis
on
a
you
know,
on
a
on
Tuesdays,
we
return
the
data
and
on
Wednesdays
we
return
the
annotations,
like
that's,
that's
a
valid
conformant
implementation.
According
to
my
idea,.
C
F
C
F
Oh
you're
saying
so
you
would
you
you're,
saying
you
either
want
to
return
the
data
or
nothing
and
make
people
yeah
go
again,
the
Manifest
in
that
case,
how
would
you
and
bouncing
back
to
Brandon
how
about
may
do
a
may?
Do
B
should
do
a
or
b.
A
Are
you
asking
if
I
would
accept
it
should,
if
I
get
a
referrals
response
back
that
does
not
have
all
the
data
I
want?
I'm,
probably
gonna
have
to
switch
to
client-side
management
of
my
own
index.
A
F
I
think
I
I
think
that's
a
reasonable
negotiation
between
the
registry
and
the
client
in
that
case,
right
like
if
the
registry
doesn't
want.
If,
if
John's
registry
never
ever
wants
to
return
an
annotation
and
is
fine
with
getting
more
requests
from
the
client
as
a
result
of
their
decision,
then
that's
I
think
a
reasonable
negotiation
between
the
two.
A
The
question
I
would
have
is:
do
we
really
want
to
do
that
in
the
first
place,
because
what
we're
saying
is
we're
going
to
make
an
API
that
we
know
that
a
lot
of
clients
aren't
going
to
find
useful
in
the
class
just
fall
back
at
that
point,
why
does
the
registry
have
to
implement
the
new
API?
Why
not
I
mean
not
implement
the
new
API
just
call
yourself
ociv1
instead
of
1.1,
that.
F
Is
also
a
perfectly
reasonable,
like
place
to
exist
and
I
think
John's
Place
to
exist
on
that
a
Continuum
might
also
be
enough
to
implement
1.1
I
have
no
idea,
I
think
that
there
is
still
a
benefit
to
returning
the
refers
API.
Even
if
it's
going
to
be
in
your
formulation,
incomplete
and
require
the
user.
The
client
to
like
do
more
work,
it's
useful
because
it
doesn't
pollute
the
tag
space.
Basically,
even
even
if
it
doesn't
remove
API
requests,
it
doesn't
pollute
the
tag
space,
which
is
nice.
F
Your
your
implementation,
your
your
proposed
idea
for
fallback,
would
be
to
do
that.
A
different
one
could
be
to
always
request.
You
know,
100
more
requests
than
it
needs
and
again
like
if
the
registry
doesn't
want
clients
to
do
that,
it
has
tools
to
do
that,
including
giving
it
the
information
it
wants
up
front.
C
C
Want
to
have
to
like
rely
on
a
cache
of
this
response
that
gets
generated
and
I
also
don't
want
to
index
and
store
arbitrary
annotations
that
the
client
provides
like
you
know.
This
is
much
less
flexible
for
clients,
but
if
say,
we
were
required
to
have
the
creation
time
annotation.
If
present
that's
something
I
would
be
amenable
to,
but
like
for
arbitrary
annotations
of
arbitrary
size,
it's
just
it's
very
annoying
to
implement
and
like
I'm
afraid
of
that
I'm
afraid
of
the
implications
of
indexing
and
filtering
on
arbitrary
key
values
like
that.
F
A
Have
this
manifest
either
create
or
delete
it
when
I
see
that
I
know
where
to
find
the
existing
index
response
that
I've
already
generated
in
the
past
and
add
a
remove
a
record
to
that
and
so
you're,
never
maintaining
other
than
just
that
whole
index
response
that
you
can
cache
you're,
never
maintaining
an
individual
table
of
all
the
different
annotations
and
everything
else.
You're
just
maintain
that
response
of
the
index
field.
H
C
That
pushes
our
consistency
guarantees
out
the
window.
H
H
Talking
about
that
being
an
uncomfortable
idea,
we
also
I
think
looked
at
various
ways
to
implement
this
and
we're
not
a
fan
of
keeping
a
bunch
of
little
pieces
of
data
in
sync.
F
C
That
is
much
more
palatable
than
arbitrary
key
values.
In
my
opinion,
like
I,
we
can,
we
can
do
that.
We
can
index
on
that.
We
can
store
that
since.
C
F
I
think
I
think
we
can
solve
some
of
the
well
with
only
a
little
bit
more
work
we
can.
We
can
solve
some
of
those
by
saying
annotations
must
be
under
a
thousand
bytes
or
annotations.
You
may
not
have
more
than
a
hundred
annotations
or
something
like
that.
B
F
I,
don't
think
that's
a
good
solution,
because
I
think,
like
the
way
that
we're
going
to
do
it
is
to
impose
a
ton
of
restrictions
on
people
for
the
Registries
benefit.
Your
registry
could
also
do
this
right.
Your
registry
could
just
say
you
gave
me
an
annotation
with
30
megabytes
of
data
in
the
value.
No
I'm,
not
gonna,
I'm
gonna
reject
that
right
away,
but
yeah
I
sort
of
to
go
back
to
the
bargaining
table
Brandon.
What?
If
we
had.
B
A
I,
don't
wanna
try
to
figure
out
what
the
keys
are
now,
because
whatever
we
picked
today
is
not
going
to
be
enough
for
what
people
want
to
do
with
it
tomorrow,
's
going
to
come
with
a
new
key
thinking
of
image
signing
they
want
to
know
who
the
signer
is
so
they're
going
to
have
a
sign
or
fingerprint.
A
The
next
person
comes
out
with
a
new
annotation
or
a
new
artifact
type
is
going
to
have
a
new
field
they
want
to
put
in
there.
So,
instead
of
going
that
direction,
because
it
makes
sense
to
index
and
track
the
full
descriptor
and
then
to
say,
the
full
descriptor
needs
to
have
some
kind
of
max
length
when,
when
you
Marshal
it
in
a
certain
way,.
A
A
Have
been
different
ways
to
look
at
it.
One
is
that
you'd
go
per
individual
annotation
I'm
thinking
about
it
as
like
for
an
entire
descriptor,
and
then
the
registry
is
just
saying:
hey
this
descriptor
references
this
other
one.
So
I
just
need
to
query
my
list
of
five
descriptors
I'm
going
to
find
do
a
quick
join
on
with
the
car
between
it.
Now
you've
got
your
index.
F
Question
that
might
derail
us
further
and
might
prove
that
this
is
moot
I'm
going
to
take
I'm
going
to
take
I'm
going
to
take
the
Gambit.
What
about
unknown
Fields
right
if,
instead
of
an
annotation
called
brandon.signature.com,
fingerprint
I,
just
add
a
field
to
my
descriptor
that
is
Brandon's
signature
fingerprint
is
the
references
response
required
to
include
that
unknown
field.
A
F
So
because
the
reason
we
don't
drop
unknown
Fields
when
you
push
a
manifest
is
because
that
is
content
addressed
and
important,
not
to
this
text.
You
would
push
that
manifest.
That
would
be.
That
would
exist
in
the
Manifest
that
unknown
field,
but
then,
when
the
references
response,
hoists
it
into
the
index
response,
it.
F
I'm
worried
about
the
the
fuzziness
of
that
assumption,
but
I
I
think
that's
fine,
I,
don't
think
my
Gambit
did
either
of
the
things
I
thought
it
would
do,
but
at
least
it
didn't
derail
us
further.
A
My
bigger
fear
kind
of
goes
down
that
path
of.
If
we
fall
back
to
clients
managing
this
that
clients
managing
the
index,
you
might
get
different
clients
putting
new
features
in
the
index,
that
old
clients
don't
know
about,
and
that's
fine
until
an
old
client
updates
the
index
and
drops
the
new
features,
and
so
I
really
want
to
push
to
get
us
to
a
point
where
the
registry
is
someone
maintain
the
index,
not
the
clients,
but.
F
B
F
Mean
maybe
Aaron's
on
your
side
too
I'm,
not
sure
and
Josh
is
just
sort
of
a
loose
cannon
but
yeah
I.
Think
like
in
general,
we
have
to
decide
whether
whether
the
registry
will
do
the
lifting
or
whether
the
client
will
do
the
lifting
someone's
got
a
lift
yeah.
A
F
I
think
I
think
you're
I
think
you're,
describing
your
your
own
personal,
specific
implementation
of
how
you
would
work
around
this
by
by
pulling
everything,
caching,
it
and
pushing
it
back
to
the
registry.
You
could
also
write
it
to
disk.
You
could
also
keep
it
in
memory.
You
could
also
do
nothing.
You
know
I
I,
don't
think
that
that
is
a
I.
Don't
think
that's
an
argument
for
why
the
registry
needs
to
do
this,
because
maybe
the
client
could
do
something
else
right.
F
D
So
a
general
question
does
I
would
think
that
John's
John's
request
for
not
processing
annotations
would
not
affect
another
Registries
implementation
of
the
spec.
D
The
suspect
now
say
that
it
must
include
annotations
or
may
include
annotations.
I
forgot
whether
the
the
refers
API
depends
on
The
annotation
or
not.
F
D
Yeah
I
mean
so
that
would
depend
upon
the
registry
implementation
Aaron
that
the
rate
limiting
part
I
mean
DACA,
Hub
May
rate
limit,
but
somebody
else
may
make
an
implementation,
but
might
that
will
do
the
heavy
lifting
instead
and
then
clients
are
free
to
choose
whatever
registry
works
for
them.
F
Yeah,
well
that's
what
I
was
trying
to
say
with,
like
the
negotiation
part
right
like
if
you
and
your
registry
have
a
different
idea
of
how
many
requests
you
should
be
allowed
to
make
or
not
even
requests
right
how
you
should
be
able
to
discover
this
data
efficiently,
but
also
quickly.
If
your
registry
says
ping
me
a
thousand
times
for
this,
oh
wait!
No,
you
can
only
ping
me
a
hundred
times
per
second,
then
you
are
free
to
find
a
different
registry,
or
at
least
complain
to
your
customer
service
person
at
that
registry.
F
To
like
be
more
consistent
with
their
feedback.
Sorry
Aaron,
you
were
about
to
say
something:
I
got
you
off.
G
That's
part
of
the
problem
is,
is
there's
an
artifact,
that's
published
somewhere
or
there's
a
popular
tool
of
maybe
some
open,
Search
tool
and
I'm,
just
a
regular
person,
I'm
Joe,
Schmo
and
I'm
downloading
my
artifacts
and
oh
I
ran
it
in
a
CI
script
and
now
it's
rate
limited-
and
this
is
has
the
potential
to
cause
that
real,
limiting
to
happen
much
much
more
quickly,
and
especially
when
you
talk
about
publishing
like
we
want
this
ecosystem
to
be
quite
large,
to
have
a
large
number
of
sort
of
associated
artifacts,
potentially
associated
with
a
manifest.
G
That
means
that
this
problem
will
only
get
worse
and
worse
as
it
goes
on
right
like
today,
it's
going
to
be
10,
Associated
artifacts.
Tomorrow
it
could
be
a
hundred
in
a
year
it
could
be
a
thousand,
and
so
you
can't
you
get
to
the
point
where
you
we
would
literally
would
not
even
be
able
to
query
an
item
in
all
of
its
related
artifacts
to
find
the
needle
that
you
wanted.
F
Yeah
I
think
at
some
point,
like
the
the
scale
argument
of
what,
if
I
have
100
billion
things
attached
to
something
right.
My
answer
to
that
becomes.
You
are
using
oci
wrong
like
like
not
not
you.
The
client
right,
like
somebody
somewhere,
is
using
oci
as
a
document
storage
of
arbitrary
size
and
those
don't
exist
in
this
plane
of
existence,
so
I
think
I.
Think
right,
like
I.
F
Don't
think
you
were
saying
that
that
that
scale
is
what
we're
talking
about,
but
somewhere
between
here
and
there,
oci
stops
being
a
good
solution
for
the
problem.
You're
trying
to
solve
I
think
I
jumped
the
line
on
hands.
I'm.
Sorry,
everyone.
H
Where
is
I
was
I
was
curious
about
maybe
pull
in
a
little
bit
more
on.
Registries
should
return
annotations
or
registry
to
return
a
data
field
as
long
as
it
doesn't
exceed
a
certain
size
and
then
it's
sort
of
a
I
don't
know
a
carrot
for
clients
creating
manifests
to
not
shove
a
bunch
of
stuff
in
annotations
and
it's
a
way
for
Registries
to
Maybe
store
all
their
manifest
stuff
in
the
in
a
performance
storage
system
that
doesn't
have
to
deal
with
unbounded
data
I.
F
If,
if
that
is
a,
if
that
was
a
thing
that
small
enough
descriptors
should
be
included
in
the
data
field
and
larger
descriptors,
that
John
doesn't
want
to
put
in
the
data
fields
are
allowed
to
be
offloaded.
Would
that
be
okay?.
H
Guess
my
first
suggestion
is
sort
of
closer
to
what
we
have
now.
We
return
a
bunch
of
descriptors,
they
have
annotations,
but
it
only
returns
annotations
if
the
size
is
under
a
certain
limit
is
my
first
proposal.
That's
still
not
good
enough,
then.
What
if
we
move
from
annotations
to
a
data
field
that
has
the
Manifest
encoded
in
it
and
stick
with
a
size
limit
of
some
reasonable
size,
foreign.
C
Yeah
from
like
a
purity
perspective,
it's
frustrating
to
be
like
oh
here's,
a
size
limit,
but
practically
there's
a
side
limit
of
like
what
I
would
be
willing
to
do
so
like
we,
we
could
store
and
serve
annotations.
C
That
would
be
okay
if
either
I'm
allowed
to
say
project
something
because
you
know
we
failed
to
store
it
right
or
you're.
Okay,
with
that
being
potentially
missing
like
we
could
store
an
annotation
that
says:
hey,
we
couldn't
serve
these
annotations
as
part.
B
C
Mean
if
there's,
if
I
can,
if
I
can
do
something
reasonable
when
my
size
limit
has
been
reached
and
not
like
an
arbitrary
one
that
we
all
decide
upon,
that
would
be
helpful
because
then
it's
not
just
like
you
know
in
2020
to
2023
we
decided
this
is
a
reasonable
size
for
a
thing.
G
C
F
I
think
when
we
talked
about
the
Manifest
size
limit,
the
this
exact
thing
came
up
and
I
think
the
language
I
would
have
to
go
like
borrow
that
language,
but
basically
Registries,
can
impose
any
arbitrary
limit
they
want
on
these
annotations.
Clients
should
expect
at
least
X,
which
doesn't
require
the
registry
to
do
anything.
It
just
says:
Hey
clients,
if
you're
pushing
a
10
megabyte
manifest
some
Registries
might
not
support
it.
A
E
F
E
To
go
yeah
then
we
have
a
deterministic
behavior
right,
like
clients
can
go
fetch
it
and
rate
limiting
aside.
That's
that's
a
costing
climb
problem,
but
the
client
can
deterministically
say
that
yes,
I,
didn't
get
this
and
I
can
construct
the
whole
API
and
expand
the
reference
on
on
the
client.
A
Now
previously
we
did
those
annotations
at
the
index
level,
not
the
individual
descriptor
level.
If
we're
going
to
do
this
for
individual
descriptors,
we
need
to
be
able
to
say
which
individual
descriptors
they
were,
and
so,
if
you
try
to
do
it
on
The
annotation
of
that
descriptor,
we've
got
a
conflict
there.
We
can
set
that
either
in
our
manifest
or
in
the
in
the
descriptor
from
the
registry
and
there's
potential
that
someone
can
make
a
manifest
that
just
sets
that
field.
E
Yeah
and
I
think
maybe
reserving
I,
don't
know
how?
If
you
want
to
do
that,
because
you
don't
have
a
property
that
says
that
right,
like
it's
one
of
those
things
that
The
annotation
can
be
present
in
the
Manifest
or
in
and
if
whether
we
hoisted
that
fake
annotation
from
the
Manifest
yeah
but
I,
don't
know
how
the
solution
should
look,
but
an
indication
that
this
was
not
returned
this.
E
A
E
Please,
please
don't
make
multiple
clients
update
the
same
index,
multiple
different
types
of
clients
as
bomb
clients,
different
lazom
clients,
as
well
as
it's
just
going
to
be
really
difficult.
So
I
really
hope
we
don't
lose
the
referral
API.
F
I
think
we
could
just
have
a
reserved
annotation
and
if
you
use
it
as
not
the
refers
response,
then
you
might
get
weird
Behavior,
though
you
know,
you
might
think
that
it's
that
it's
somewhere
else
and
it
isn't.
But
that's
on
you,
because
you
touched
the
electric
fence
I'm
a
little,
hesitant
to
start
adding
new
Fields,
because
we're
gonna
argue
about
those
two
yeah
yeah.
C
C
C
A
F
G
No
worries,
I
was
just
gonna,
say,
I'm,
very
much
in
favor
of
Registries
rejecting
and
artifact
manifest
if
it
would,
if,
if
it
would
violate
the
requirements
for
projecting
the
refer,
the
annotations
in
the
refers
API.
So
that
way,
clients
could
rely
on
always
having
annotations
available
and
I
guess
implementing
on
the
the
implementer
side
of
implementing
the
refers
API.
G
It
would
also
be
simpler
is
that
you
would
know,
for
example,
that
you're
going
to
have
a
bounded
size
there
as
well
right
so,
and
you
get
that
feedback
up
front
when
you're
pushing
the
artifact
that
you're
going
to
do
something
you're
blowing
up
clients
or
the
registry.
By
doing
this,
absurdly
large
manifest
push.
F
I
I
think
I
tend
to
agree
with
you.
I
think
the
reason
the
the
only
sort
of
hesitation
I
have
about
it
is
if
a
registry
changes
what
that
limit
is
like.
If,
today
it's
10
annotations
and
tomorrow,
I
lower
it
to
five,
then
your
pushes
start
to
fail
as
opposed
to
your
pushes
are
accepted,
but
your
references,
API
calls
will
require
you
to
make
another
request
to
get
your
the
last
five
annotations
or
whatever
I.
Don't.
E
G
If
they
change
that
limit
to
one-tenth
of
what
it
was,
I
should
still
get
these
like
the
existing
refers.
Api
should
be
unchanged.
I
would
hope
that
would
be
the
case.
A
A
And
so
that's
that's
a
big
key
thing
to
me
of
if
I'm
going
to
lose
functionality,
I'm
just
not
going
to
use
the
new
API
I'm
going
to
keep
going
with
the
old
thing,
and
so
the
value
to
me
having
the
server
do
it
is
that
I'm
going
to
gain
functionality
and
so
I
think
we
as
our
CI
and
we're
defining.
This
should
make
sure
that
that
we
don't
introduce
the
case
where
we're
going
to
say.
Okay,
you
lose
functionality
here
by
getting
this
new
feature.
A
H
A
A
But
when
I
go
from
that
fallback
tag
to
Hidden
the
refers
API
and
the
registry
is
now
generating
that
index.
I
shouldn't
lose
functionality
getting
that
new
index
from
the
Registries
API
versus
what
I
was
pushing
originally
as
a
client,
and
so
that
was
where
I
was
going
back
to
the
original
thing
of
saying.
Well,
if
the
registry
may
start
excluding
a
lot
of
these
things
in
there
I'm
going
to
lose
functionality
in
from
a
client
side
by
using
that
new
API
instead,
that's
a
degradation,
not
an
improvement
to
me
at
that
point.
H
D
D
C
G
Right
so
John,
just
if
you
would
reject
that
index,
then
would
the
proposal
to
reject
pushing
the
artifact,
which
sets
the
subject
field
just
rejected
at
that
point.
That
way,
you
have
feedback
at
the
point.
That
way,
the
the
producer
of
the
artifact
has
the
feedback
that
something
is
going
to
break
as
opposed
to
the
client,
because
I
think
the
problem
is,
if
I
can
push
an
artifact
that,
then
some
clients
will
not
see
or
feel
to
find
due
to
their
first
API
behaving
differently
and
I.
Think
clients
are
going
to
I.
G
Think
it's
a
gel.
It's
a
an
eager
assumption,
I
think
to
assume
the
clients
are
going
to
correctly
Implement
falling
back
to
querying
each
individual
one
if
they're
either
going
to
assume
their
first
API
works
and
returns,
annotations
or
they're
going
to
always
fall
back
and
always
query
every
every
manifest
I
think.
So.
C
Yeah
that
would
work
the
the
slight
wrinkle
of
a
difference.
There
is
like
the
refers
response
is
an
aggregate
of
all
these
things
and
so
like
when
you're
at
push
time
yeah.
C
We
could
reject
something,
that's
too
large
but
like
if
at
fallback
time
say
if
we
are
not
returning
annotations
for
some
reason
and
you're
constructing
an
index
that
has
multiple
things
with
say,
a
megabyte
size
annotations,
that's
more
likely
to
be
rejected
than
if
we
were
to
reject
the
initial
request
like
yeah
like
there
is
a
point
at
which
we
would
reject
the
artifact
outright.
C
Very
likely,
if
you're
constructing
a
giant
artifact,
it
is
almost
exclusively
going
to
be
annotations
or
emitted
data
so
like
we
could
reject
it,
and
we
will
at
some
point,
but
would
you
rather
it
be
rejected?
Let's
say
at
a
slightly
lowered
limit
on
the
order
of
megabytes,
or
would
you
rather
it
be
accepted
because
we
can
actually
store
it?
C
Add
this
extra
logic
to
fall
back
fetching
or
would
you
rather
get
rejected,
and
then
you
have
to
go
back
and
like
reconstruct
this
artifact
for.
G
Yeah
I
think
so
yeah
I
think
I'm
thinking
of
a
couple
things
here,
one
is
my
bias,
would
be
I
want
it
to
be
rejected
up
front
because
I
I
don't
want
to
have
to
have
a
more
complicated
client
implementation
and
I.
Think
that
there's
going
to
be
many
more
clients
and
there
are
going
to
be
servers,
and
so
my
bias
is
almost
always
sort
of
simpler
client
implementations
just
produces
fewer
faults
and
regressions
down
the
road.
G
G
G
A
Me,
my
fear
is
I'm
looking
at
different
extreme
use
case,
because
we've
got
the
extreme
use
case.
If
someone
makes
a
really
giant
manifest
with
thousands
of
annotations
and
I'm
comfortable.
Limiting
that
my
fear
is,
you've
got
a
thousand
artifacts
and
you're
trying
to
figure
out
which
one
you
want
to
pick
from
that
and
so
you're
going
to
have
an
index
with
a
thousand
entries.
Each
entry
is
going
to
be
500,
maybe
one
kilobyte
in
size.
That's
going
to
be
well
under
the
four
megabyte
limit
you
can.
A
If
you
had
500
bytes
per
per
descriptor,
there
you're
talking
8
000
entries
in
there
within
a
four
megabyte,
so
you
can
pack
a
lot
of
descriptors
with
within
that
four
megabyte
limit.
So
thinking
through
that
scenario,
I'm
looking
at
I
want
to
make
sure
we
don't
break
that
extreme
use
case,
because
I
can
see
what
we're
creating
now
extending
for
a
whole
lot
of
different
various
kinds
of
piece
of
metadata,
and
it
might
be
that
one
kind
of
metadata
might
have
a
lot
of
instances
of
itself.
A
You
know
pick
some
arbitrary
annotation
in
there
and
we
need
to
be
able
to
figure
out
which
one
is
from
that
list,
and
so,
if
we
need
to
limit
the
overall
size
of
the
scripture
I'm
good,
if
we're
going
to
say
that
we're
going
to
push
it
over
to
some
kind
of
fallback
where
the
client
is
going
to
have
to
fetch
each
one
of
those
manifests,
that's
bad
for
me
and
that's
where
I
would
want
to
fall
back
to
the
fallback,
because
that's
giving
me
more
functionality.
In
that
case,.
A
At
the
page,
Nation,
that's
definitely
something
that
we
get
out
of
having
the
reverse
API.
We
eliminate
race
conditions.
That's
another
great
thing:
we
get
a
lot
more
consistency,
so
there's
there's
a
lot
of
value
to
have
in
the
registry.
Do
this
for
us
I
just
want
to
make
sure
we
don't
lose
the
value
that
we're
having
right
now
within
the
fallback.
G
Yeah
I
just
took
a
glance
of
paging
HP,
thanks
Sanjay
for
for
pointing
me
to
that
it
looks
like
it.
It
doesn't
specify
that
there's
a
minimum
number
of
required
entries
in
each
page.
So
if
you
wanted
to
implement
the
you
know,
the
maximum
response
size
there
as
well
right
like
cap,
the
size
of
the
descriptor
on
that
you
embed,
and
if
you
get
to
and
entries
and
that's
more
than
for
mag,
then
you
truncate
there
and
that
any
future
entries
become
part
of
the
next
page.
H
H
A
A
So
in
that
case,
if
we've
got
four
makes
for
a
limit,
we
want
to
do
100
of
these,
and
we've
got
set
four
kilobytes
or
a
mile
of
five
factor
of
10.
F
Is
there
a
practical
change
to
John's
change?
We
wanted
to
make
or
propose
or
a
separate
change.
I
don't
want
to
I,
don't
want
to
lose
the
spirit
of
almost
coming
to
an
agreement
and
have
to
wait
until
next
week
to
have
the
same
almost
agreement.
F
Does
anyone
remember
what
we
agreed,
what
we
agreed
on
the
most
or
the
closest
to
so
that
we
could
put
that
in
in
a
PR
and
start
trying
to
agree
to
it
in
in
writing.
I.
C
F
It
it
sounded
from
this
discussion,
like
people
would
tend
to
agree.
People
would
tend
to
prefer
you
to
reject
it,
but
that
rejection
is
also
like
unspecified
right,
like
the
registry
is
now
rejecting
a
thing
that
is
otherwise
valid
due
to
its
own
preferences
and
whims
and
implementation,
and
that's
not
great
for
OCS
I.
A
A
A
D
A
If
it's
got
a
subject
in
that,
4kb
is
all
annotations
because
you're
looking
at
building
a
descriptor.
So
if
you
construct
a
descriptor
with
this
and
your
media
type
size
digest
and
all
the
annotations
together
exceed
40
kilobytes,
then
yes,
because
we
still
want
to
allow
Registries
to
support
the
data
field
for
other
stuff.
F
Let's,
let's
all
promise
to
argue
on
the
pr
before
next
week,
so
that
we
don't
have
to
wait
a
whole
week
to
argue
again.
This
has
been
fun
arguing,
though
I
feel
like
we
really
got
somewhere.
I
want
to
unironically
and
completely
genuinely
say,
I.
Think
we
made
progress
here.
A
And
as
much
as
we
like
to
strangle
each
other,
we
politely
strangled
each
other
to
a
good
place.
So
it.