incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Filip Maj <...@adobe.com>
Subject Re: FileTransfer header support and options
Date Tue, 12 Jun 2012 00:18:11 GMT
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" <shazron@gmail.com> 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 <fil@adobe.com> 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
>>


Mime
View raw message