Hi Bertrand, On June 27, 2018 at 4:33:05 AM, Bertrand Delacretaz (bdelacre...@apache.org) wrote:
Hi Matt, >From the Sling clients perspective I'm interested in making this somewhat transparent, maybe something like: For downloads, a client requests http://my.sling.instance/somebinary.jpg and is redirected to https://somecloudprovider/23874623748623746234782634273846237846723864.jpg For uploads, it's a bit more complicated - maybe the client POSTing to Sling receives a 307 status with a JSON document that describes where/how to upload. In this case the client requires some knowledge of this new API, unless someone has a better idea. Do you see any obstacles in implementing something like this on top of your suggested API? It seems to me the download case should work as you’ve described. Sling could ask for a download URL, and if it gets one Sling can send a redirect to that URL; if not, Sling can then issue the request as is currently done today. Upload is more complicated because of multi-part uploads. For example, Azure requires that a multi-part upload be performed for any binary larger than 256MB [0]. Both Azure and AWS require multi-part uploads to be done using a distinct URL for each part (instead of allowing the reuse of the same URL with Content-Range like Google does [1]). Thus the new Oak API needs to support multi-part uploading via distinct URLs. I’m not sure how Sling would manage to hide that away from a client via a redirect when there are potentially multiple URLs involved, without creating a stateful session or something like that. Of course Sling could take the return value from the call to initiate the upload and turn it into a JSON document that the client can then consume. As you say the client will need to have some knowledge of the new API to do this. [0] - https://docs.microsoft.com/en-us/rest/api/storageservices/put-blob#remarks [1] - https://cloud.google.com/storage/docs/json_api/v1/how-tos/resumable-upload -MR
