Steven Bergsieker

Definitely agreed that the Capabilities API is underspecified, and has never really fulfilled its purpose. My understanding of your questions, based on both historical context and (where applicable) RBE's implementation:...

I'm all for leaving this open and fixing in v3. I suspect we'll either eliminate the Capabilities API entirely in v3, or significantly overhaul it and possibly split it by...

@ola-rozenfeld What are your thoughts on moving these bindings to remote-apis-sdks?

Mostyn: yes, I believe this will fix that issue as well (by pushing it back to the consuming repo). At the monthly sync we determined that a large chunk of...

I think Alexis is actually referring to the historical design docs, so we have a record of decisions that we've made in the past. I think those docs should be...

I have tagged v2.1.0-rc1, v2.2.0-rc1, and v2.3.0-rc1. Assuming those releases look good, I will promote them soon. Given that we fell off the bandwagon on creating proper releases for a...

I have published the official release of v2.1.0 and v2.2.0. I have also published v2.3.0-rc2, which includes https://github.com/bazelbuild/remote-apis/commit/e95641649b5b4d3c582c89daabfaabeb8189dd77. I have not yet gone through the remaining commits to decide if...

I'm not familiar with the details, but from the description it sounds like the dictionaries are used to "speed up" compression by providing hints about the likely format of the...

Conceptually I have no objection to an explicit delete API. We originally opted not to implement one at least in part because constructing the digest to delete is relatively difficult,...

+1 to option 2. The client already has some knowledge (or makes assumptions) about what the remote environment looks like--for example, that executable /foo/bar/bas will exist in the remote environment--and...