Problem
gws has no way to issue a Google API batch request (multipart/mixed combining multiple calls into one HTTP request) — confirmed via gws drive --help and gws --help: no batch verb exists anywhere in the CLI surface, for any service.
This isn't just an efficiency gap. For Google Drive specifically, Google's own docs describe two independent reasons batching matters here, not one:
- Efficiency — the Improve performance guide lists "Changing permissions for a large number of files, such as adding a new user or group" as a headline batching use case.
- Correctness — the sharing guide states concurrent permission modifications on the same file aren't supported: "Drive evaluates and updates an item's permissions as a single ACL. Simultaneous operations cause race conditions where 'last write wins'... or trigger
sharingRateLimitExceeded errors. To avoid conflicts, execute permission changes on the same item sequentially, or use batch requests." Right now gws users have no way to follow this documented guidance except manual sequential calls.
What exists today
POST https://www.googleapis.com/batch/drive/v3 (and the equivalent per-API batchPath from each service's Discovery document) is a real, current, non-deprecated mechanism — distinct from the old cross-API global batch endpoint Google sunset in 2020. Format: multipart/mixed, each part a complete nested HTTP request (path-only URL, own headers/body). Limits: 100 calls/batch, 8000-char URL limit per inner request, no guaranteed execution order, no media upload/download/export support. Each inner call still succeeds/fails independently — it's not atomic, just fewer round-trips and (for same-file permission changes) race-safe.
Proposal
Add a way to submit a batch of same-service calls in one gws invocation — exact command shape is up to you; a few possibilities:
- A new top-level
gws batch command taking a JSON array of {resource, method, params, json} entries for one service.
- A
--batch-file <path> flag on existing commands accepting multiple param/body sets.
Not proposing a specific implementation here — just flagging that the underlying Google API capability exists, is current, and is Google's own documented answer to a real correctness problem (not just a nice-to-have), and gws has no path to it today for any service.
Motivation
Came up while building tools for gws-mcp-server (an MCP server wrapping gws) — a "share N files with one user" tool is worth having, but gws-mcp-server's own contribution rules require every tool to delegate to a single gws CLI call, no direct Google API calls. Without batch support in gws itself, the only implementable option there is a client-side loop, which doesn't get the correctness benefit above and isn't a good fit for that project's "thin wrapper" design. This would unblock that cleanly for Drive and any other service with a batchable Discovery-doc endpoint.
🤖 Generated with Claude Code
Problem
gwshas no way to issue a Google API batch request (multipart/mixedcombining multiple calls into one HTTP request) — confirmed viagws drive --helpandgws --help: nobatchverb exists anywhere in the CLI surface, for any service.This isn't just an efficiency gap. For Google Drive specifically, Google's own docs describe two independent reasons batching matters here, not one:
sharingRateLimitExceedederrors. To avoid conflicts, execute permission changes on the same item sequentially, or use batch requests." Right nowgwsusers have no way to follow this documented guidance except manual sequential calls.What exists today
POST https://www.googleapis.com/batch/drive/v3(and the equivalent per-APIbatchPathfrom each service's Discovery document) is a real, current, non-deprecated mechanism — distinct from the old cross-API global batch endpoint Google sunset in 2020. Format:multipart/mixed, each part a complete nested HTTP request (path-only URL, own headers/body). Limits: 100 calls/batch, 8000-char URL limit per inner request, no guaranteed execution order, no media upload/download/export support. Each inner call still succeeds/fails independently — it's not atomic, just fewer round-trips and (for same-file permission changes) race-safe.Proposal
Add a way to submit a batch of same-service calls in one
gwsinvocation — exact command shape is up to you; a few possibilities:gws batchcommand taking a JSON array of{resource, method, params, json}entries for one service.--batch-file <path>flag on existing commands accepting multiple param/body sets.Not proposing a specific implementation here — just flagging that the underlying Google API capability exists, is current, and is Google's own documented answer to a real correctness problem (not just a nice-to-have), and
gwshas no path to it today for any service.Motivation
Came up while building tools for
gws-mcp-server(an MCP server wrappinggws) — a "share N files with one user" tool is worth having, butgws-mcp-server's own contribution rules require every tool to delegate to a singlegwsCLI call, no direct Google API calls. Without batch support ingwsitself, the only implementable option there is a client-side loop, which doesn't get the correctness benefit above and isn't a good fit for that project's "thin wrapper" design. This would unblock that cleanly for Drive and any other service with a batchable Discovery-doc endpoint.🤖 Generated with Claude Code