I think its weird to add documents like this for only one item. Either do them all or none at all. It just creates weird documents that are narrow and confuse the readers.

Is there other item?

Using listing instead of table might be better?

I'll add GC labels after #1563

Want to add a TODO here with more information about how containerd is a client-heavy design?

Are we assuming the reader should know the pros and cons of gRPC and how it lends itself to implementing 3rd-party containerd clients? It may be helpful to provide an example.

We've already made the choice. ;)

@estesp has a talk somewhere where he discusses the decision. There are also some old discussions about how avoiding http specification time speeds up implementation.

A link to grpc.io would be good.

are push&pull interactions the only thing a 3rd-party client would need to reimplement?

No, there is a huge list. We should probably document that list here.

These aren't restricted to these types, are they?

@dmcgowan PTAL (why do we need timestamp here?)

@AkihiroSuda The timestamp tells you when the label expires, letting you reserve objects before they are referenced elsewhere.

Right now I am using the creation time. While garbage collection is done by the serve, a "prune" operation will be client side and these timestamps can be used to hint any client doing pruning as to which objects may be old. It is a client decision but by adding a timestamp here it gives clients more information it may need. This value is not read by the server, that should be noted, it is only for client use.

Also allow gc.ref.content.${something} to allow adding multiple links. It would be inaccurate to say "Digest string of children blobs." since each label may only refer to a single digest. To refer to multiple children multiple label keys must be used using a client define string after gc.ref.content..