Clarification: Ordering of entries in BatchReadBlobsResponse about remote-apis HOT 3 OPEN

You are correct that the current API does not specify an ordering. Note that there's no ambiguity here: each result includes a digest, so the client can understand which bytes/status belongs to each requested blob. I don't believe that the lack of ordering was by design, so we could potentially specify an ordering, although I'm not sure how much it would simplify clients in reality. @buchgr WDYT?

from remote-apis.

If the ordering is required, then the digests don't have to be set, reducing the response size. What about eliding successful replies? The client could implicitly assume that anything not mentioned was OK.

from remote-apis.

How about using a uint32 request_index in each response item? That would provide the same functionality as the current protocol, without requiring the server to send back the original digests.

edit: ah, this has already been suggested at #160

Something like this:

message FindMissingBlobsRequest {
  // [...]
  repeated Digest blob_digests = 2;
  bool respond_digest_indexes = 3;
}

message FindMissingBlobsResponse {
  // not populated if request's `respond_digest_indexes` was true
  repeated Digest missing_blob_digests = 2;

  // request::blob_digests[missing_blob_digest_indexes[N]] == missing_blob_digests[N]
  repeated uint32 missing_blob_digest_indexes = 3;
}

message BatchUpdateBlobsRequest {
  // [...]
  repeated Request requests = 2;
  bool respond_digest_indexes = 3;
}

message BatchUpdateBlobsResponse {
  message Response {
    // [...]
    uint32 request_index = 3;
  }
}

// same for BatchReadBlobsRequest / BatchReadBlobsResponse

from remote-apis.