incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian LeRoux...@brian.io>
Subject Re: [DISCUSS] API addition: aborting FileTransfer upload/download process
Date Thu, 31 May 2012 17:19:47 GMT
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