Yeah, but I'm wondering if we should put more effort into filling in the platform gaps for FileTransfer now, or if we should slate this work as a larger effort to polyfill XHR2 ?
On 6/11/12 5:13 PM, "Shazron" <[email protected]> wrote: >For [2], it is for iOS upload (based on the pull request), just like >the undocumented Android one. Not sure if there was a issue filed for >iOS download headers as well. > >On Mon, Jun 11, 2012 at 10:54 AM, Filip Maj <[email protected]> wrote: >> Hey all, >> >> There's an issue for adding HTTP header support for the download method >>in >> Android [1]. There is another one for doing the same on iOS, but am not >> sure for which method this is [2]. Finally, there's a parent task for >> adding support in Android for headers during upload [3], but it is >> resolved and I am not sure that this is the case. >> >> I want to take a step back for a second. For our own homegrown >> FileTransfer API, we have upload and download methods, but we only >>provide >> FileUploadOptions for the upload method. It looks like the patchy header >> support in upload is not documented. Would it make sense to provide a >> generic "FileTransferOptions" that encapsulates options for both upload >> and download? Or even a different take, there was mention of trying to >>go >> the XHR2 route, so perhaps transforming FileTransfer to an XHR2 polyfill >> makes more sense. >> >> Discuss! >> >> [1] https://issues.apache.org/jira/browse/CB-861 >> >> [2] https://issues.apache.org/jira/browse/CB-765 >> >> [3] https://issues.apache.org/jira/browse/CB-78 >>
