V3 idea: Let {BatchRead,BatchUpdate,FindMissing}BlobsResponse use indices instead of digests (or none at all?)
The {BatchRead,BatchUpdate,FindMissing}BlobsRequest messages contain sequences of digests that need to be processed. The responses also contain the digests. The downside of this construct is that it requires some defensive code on the client side to account for the following scenarios. Think of the following cases:
- What if these responses contain digests that weren't part of the request?
- What if the same digest is reported in the response twice?
- In the case of Batch{Read,Update}BlobsResponse: what if the response lacks entries that were part of the request?
- What if the response contains elements in a different order?
Would it make sense to switch to different encodings that prevent (some of) these cases from existing? For example:
- FindMissingBlobsResponse could use a
repeated int32to report blobs that are absent. That makes it easier to deal with case 1 by doing simple integer bounds checking. By requiring that these numbers are sorted, you can easily rule out case 2. - Batch{Read,Update}BlobsResponse could simply omit the digest and require that the order corresponds with what was part of the request. That makes it easier to deal with case 1-4 by comparing just the length of the list in the response.
Something similar applies to ActionResult. I've noticed that these messages can get unnecessarily big due to the repetition of pathname strings that are already part of the original Command. It may make more sense to also use integer indices here.
Out of curiosity, why would this need to be deferred to v3? If a new "please send indexes" field were added to the requests, then the client could opt-in within the existing protocol.
request := FindMissingBlobsRequest { ... }
expect_indexes := false
if server_capabilities.high_api_version >= v2.X {
request.respond_digest_indexes = true
expect_indexes = true
}
...
To avoid checking the API version, the response can also have a bool uses_indices.