Problem: lack of storage destination settings

[sevein]

In e9a3398, a3m learned to write to object storage given these settings. When undefined, packages are left in completed/{name}-{uuid}.{ext}.

It may also be preferably to support request-scoped settings, i.e. storage settings that are included within the transfer request. For example, object storage can be used to generated a pre-signed URL with write permissions that a3m could use to store the object after the AIP is generated (as long as the URL has not expired).

Related: #55.

[joel-simpson]

I agree it would be good to support this as an explicit input (aka request-scoped setting).

I wonder if there is even a case for making this the only way to provide instructions for storage destinations?

If you have to provide storage settings as configuration of a3m, you are sort of hiding user or use case specific details in the application. Demanding that every user request includes storage location makes this much more explicit (and perhaps closer to the goal of 'stateless'?)

[sevein]

When using object storage, it is possible to generate signed URLs with write access so you don't have to share actual credentials. Maximum signature expiry setting for these URLs is 7 days.