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) >>> > >>> >
