Re: Oak Direct Binary Access pull request
On 2018-06-27 18:10, Matt Ryan wrote: 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. ... Keep in mind that redirecting to a cloud URI is likely to break relative references contained in a document Best regards, Julian
BUILD FAILURE: Jackrabbit Oak - Build # 1514 - Still Failing
The Apache Jenkins build system has built Jackrabbit Oak (build #1514) Status: Still Failing Check console output at https://builds.apache.org/job/Jackrabbit%20Oak/1514/ to view the results. Changes: [tommaso] OAK-7588 - added missing rat exclusion for fvs.csv test resource Test results: All tests passed
Re: Oak Direct Binary Access pull request
Hi Matt, On Thu, Jun 21, 2018 at 6:25 AM Julian Reschke wrote: > ...it would be helpful if you could link to example client code taking > advantage of this extension... +1, ideally as readable test code that one can use as examples. >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? -Bertrand
