Dan, We've been talking about aligning with cmis so the use of files may be misleading even if we add it as osapi On Feb 22, 2012 9:33 AM, "Dan Dumont" <ddum...@us.ibm.com> wrote:
> Similar to the proxied-form-post feature that I recently added to shindig, > there is a need to make an authenticated file download in a gadget. > Authentication for a file download is likely needed and since the shindig > server handles that for the gadget, requests directly to the remote > service would be rejected (without some monkeying around with one-time-use > tokens). > > It would seem that the content proxy (getProxyUrl) is inappropriate here, > as it doesn't look like it can or should accept headers and authentication > params. > makeRequest and osapi.http.* apis also seem inappropriate for this use > case, as they contain a bunch of extra information in the response that > isn't wanted (we just need the binary data to let the browser save the > file). > > So it looks like the only option is a new feature that would allow for > streamed file downloads through an OS proxy. Hopefully, like the > proxied-form-post feature, we can reuse most of the existing makeRequest > server logic to do this for us. I'm wondering if we create a > gadgets.files.* namespace to house these new functions, or if we should > keep them in gadgets.io? > > Any thoughts on all of this?
