incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dave Johnson <dave.c.john...@gmail.com>
Subject Re: [DISCUSS] API addition: aborting FileTransfer upload/download process
Date Fri, 01 Jun 2012 06:39:51 GMT
If we can build XHR2 on top of what's there for FileTransfer then that
might be best case -- we would probably have to add things like abort
to FileTransfer then anyhow.

-d

On Thu, May 31, 2012 at 10:19 AM, Brian LeRoux <b@brian.io> wrote:
> given the backwards compat and the fact that 2.x is really only a
> couple of months out maybe hold off until we do 3.x planning even
>
> On Thu, May 31, 2012 at 10:06 AM, Filip Maj <fil@adobe.com> wrote:
>> How about a compromise: slate use of XHR2 as the way to do it for 2.0 or
>> 2.x (documentation issue) and then fill in anything missing on
>> FileTransfer. This way both approaches work, existing apps don't have a
>> migration headache, and we can deprecate FileTransfer in 2.x and slate it
>> for removal in 3.0.
>>
>>
>>
>> On 5/31/12 7:31 AM, "Simon MacDonald" <simon.macdonald@gmail.com> wrote:
>>
>>>Right and since 90% of the Android phones don't support XHR2 we'd need to
>>>shim support for XHR2 into Android 2.X.
>>>
>>>Or we could just add an abort method to the already working/tested
>>>FileTransfer code. Since even if we shim in XHR2 support we'll still need
>>>to support FileTransfer for the foreseeable future as folks are currently
>>>using it in their applications.
>>>
>>>Simon Mac Donald
>>>http://hi.im/simonmacdonald
>>>
>>>
>>>On Thu, May 31, 2012 at 1:43 AM, Shazron <shazron@gmail.com> wrote:
>>>
>>>> Generally +1 on XHR2, but we're still planning on supporting iOS 4.2 in
>>>> Cordova 2.0, so we'll need to shim if not available.
>>>>
>>>> On Wed, May 30, 2012 at 9:39 PM, Dave Johnson <dave.c.johnson@gmail.com
>>>> >wrote:
>>>>
>>>> > Since XHR2 is now available in iOS 5 and Android 3+
>>>> > (http://caniuse.com/#search=xhr) we should probably change all of the
>>>> > FileTransfer API to be XHR2 instead of trying to fix the FileTransfer
>>>> > API.
>>>> >
>>>> > Less documentation on our part and standard API ftw.
>>>> >
>>>> > On Wed, May 30, 2012 at 2:45 PM, Brion Vibber <brion@pobox.com>
wrote:
>>>> > > On Wed, May 30, 2012 at 1:33 PM, Filip Maj <fil@adobe.com>
wrote:
>>>> > >
>>>> > >> Reference issue: https://issues.apache.org/jira/browse/CB-836
>>>> > >>
>>>> > >> I am just fostering discussion here. Maybe a simple `abort`
>>>>method, a
>>>> la
>>>> > >> XHR [1]? Seems the easiest.
>>>> > >>
>>>> > >> [1] https://developer.mozilla.org/en/DOM/XMLHttpRequest#abort()
>>>> > >>
>>>> > >
>>>> > > One difficulty is that FileTransfer.upload and FileTransfer.download
>>>> > don't
>>>> > > appear to return an object which can be used to refer to the ongoing
>>>> > > session.
>>>> > >
>>>> > > If it did, then having an abort method on it would seem perfect!
>>>> Existing
>>>> > > code that didn't understand the object should continue to just
work.
>>>> > >
>>>> > > This would also be a great object on which to addEventListener()
for
>>>> > > progress events... [2]
>>>> > >
>>>> > > [2] https://issues.apache.org/jira/browse/CB-622
>>>> > >
>>>> > > -- brion vibber (brion @ pobox.com / brion @ wikimedia.org)
>>>> >
>>>>
>>

Mime
View raw message