We want to extend snap download (and related commands) to be able to:
use proxy configuration from snapd
use user credentials from snapd
use external user credentials
In the first iteration, we’ll make snap download on linux attempt (once) to download via snapd (which would pick up proxy configuration and user credentials from snapd). snap download --direct would skip the query to snapd and preserve existing behaviour [or do we want --remote to switch to the new behaviour?].
We’re going to add /v2/download endpoint, which will takes POST request with an action description in the body, e.g. {"snaps": ["foo"], "action": "download"} (exact action description TBD; do we want a "remote" bool in there as well to force things to only download local snaps a la /v2/snaps/foo/file?). This endpoint is synchronous and streams the file out.
Later the action description would grow flags to enable passing in credentials, but that’s not part of the first iteration.
Another bit of related work (but again not 1st iter) is that the /v2/assertions would also grow a remote flag that would allow us to implement snap known --remote via snapd instead of direct, again for picking up snapd conf and users.
What do you see the response format for the API being? Since even a download of a single snap results in multiple files (the snap plus its assertions), it’d seem you can’t return the snap as is. This is doubly true if you support downloading multiple snaps in a single request. I suppose a multipart/mixed response body might do the trick.
Is progress reporting for the download important? If you went the multipart/mixed route, it might not be possible to determine the size of the API response up front, which would also make it difficult for the client to show how far through the download it is.
this would only be for downloading the snaps, with assertions being retrieved from /v2/assertions (with an added “remote” flag). While we would like to support multiple snaps by using some kind of multipart, for the single snap case it would just be a stream of the snap.
For the progress bar, I hope we have multi-progress bars ready to go before we implement multi-snap download-from-snapd (and when I say “hope” I mean “let’s make it a dependency”).
There is value having a download that gives a stream of assertions, snap, assertions, snap etc. But for a first iteration we will simplfy support a single snap, no assertions. In the general case I imagine a multipart/mixed would be appropriate, then the first part could be a JSON object describing what comes later.
