It needs to stay for now; does no harm. Looks like xhr2 basically everywhere http://caniuse.com/xhr2 On Jul 26, 2012 10:47 AM, "Filip Maj" <[email protected]> wrote:
> As much as I would like to see it gone, it is a necessity at this point. > How to upload binary files, for example? Need to make sure we cover our > users' core use cases, binary upload being one of them. > > Agree with Jesse that would also need to see the viability of moving to > xhr2 across our supported platforms. > > I am leaning towards keeping it around for now (maybe discussing a > deprecation plan, and how to replace it with other structs), but would > love to see it gone. What would we need to do to get rid of it long-term? > > On 7/26/12 10:17 AM, "Jesse MacFadyen" <[email protected]> wrote: > > >I don't see polyfillin this as an easy feat. > >How can we implement ArrayBuffer? > >Also, without web workers, file transfers would block the ui thread, > >or am I missing something? > >I think we need to go a little further into the 'how' before we can > >see if it makes sense. > > > >Personally I think there will always be a place for the FileTransfer > >API as it is simple and dedicated. > > > >Cheers, > > Jesse > > > > > >On 2012-07-26, at 9:42 AM, Joe Bowser <[email protected]> wrote: > > > >> Hey > >> > >> There are a lot of requests to improve file transfer to support > >> multiple files, and have the same header format on upload and > >> download. I know that Andrew has been doing work on it, but I want to > >> know if we should take on the multiple file ticket (CB-200), or if > >> we're going to deprecate this and go with XHR2 for our File > >> Upload/Download needs. I'm assuming moving to XHR2 will require > >> polyfilling it on Android 2.x, which is fine, but I kind of want to > >> see some movement on this, since I don't want to give people this as a > >> First Ticket just to have it deprecated. > >> > >> Thoughts? > >> > >> Joe > >
