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 <[email protected]> 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 <[email protected]> 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" <[email protected]> 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 <[email protected]> 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 <[email protected] >>>> >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 <[email protected]> wrote: >>>> > > On Wed, May 30, 2012 at 1:33 PM, Filip Maj <[email protected]> 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) >>>> > >>>> >>
