ftr https://issues.apache.org/jira/browse/CB-852
(not scheduled) On Thu, May 31, 2012 at 11:39 PM, Dave Johnson <[email protected]> wrote: > 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) >>>>> > >>>>> >>>
