AFAIK, on Android and iOS, it's not possible to create a native Blob / File object that points to a file on the filesystem. The exception is on Android *before* kitkat, we could maybe use the <input type=file> to do this. Without this ability, we'll need to keep FileTransfer around.
Neat! URLs enable non-upload/download use-cases. e.g. download from file:// to file://. Or download from asset-library: to file:. Maybe to underscore the API change, we could change the function signature entirely (maybe make it closer to xhr). E.g: var ft = new FileTransfer(); ft.source = 'file://...'; ft.dest = 'http://...'; ft.onprogress = ... ft.onload = ... ft.onerror = ... ft.method = 'POST' ft.transfer(); Might be possible to keep it backwards compatible. E.g. have an exec() method that converts a path to upload/download into a URL, then implement upload/download by calling ft.transfer() (assuming the above example). If it's that easy, then I think it's worth it. There are a lot of examples online and a lot of existing uses of the API. On Mon, Nov 25, 2013 at 2:00 PM, Jesse <purplecabb...@gmail.com> wrote: > Well, according to the caniuse link, it is already available in all current > platforms. > Of course we will need to investigate permissions when uploading from > file:// to server:// > as there are always some hoops, but having an available browser > implementation to patch is a great start. > > @purplecabbage > risingj.com > > > On Sun, Nov 24, 2013 at 5:47 PM, Brian LeRoux <b...@brian.io> wrote: > > > Ya, it was discussed some time ago to polyfill FileTransfer over to XHR2 > > but determined it was a thing we could solve w/ patience. Not sure what > > browser support looks like these days. Either way, we're talking less > about > > that part and more about the nature pathing in Cordova-land vs > > browser-land. > > > > > > On Fri, Nov 22, 2013 at 3:44 PM, Tommy-Carlos Williams > > <to...@devgeeks.org>wrote: > > > > > Since most recent-ish platforms support xhr2 (excluding the always > joyful > > > Android 2.x) [1], it would probably be a REALLY good thing for > > FileTransfer > > > to become a polyfill for xhr2. > > > > > > I know that would mean a major version bump and an api change… but > isn’t > > > that what we seem to already be discussing? > > > > > > 1. http://caniuse.com/#feat=xhr2 > > > > > > On 23 Nov 2013, at 9:02 am, Brian LeRoux <b...@brian.io> wrote: > > > > > > > Ya FileTransfer not a spec and this is mostly solved now by XHR2 > which > > > our > > > > File implementation predates. (Also why we split it out.) > > > > > > > > > > > > On Fri, Nov 22, 2013 at 12:16 PM, Ian Clelland < > iclell...@chromium.org > > > >wrote: > > > > > > > >> On Fri, Nov 22, 2013 at 3:12 PM, Wargo, John <john.wa...@sap.com> > > > wrote: > > > >> > > > >>> Brian, > > > >>> > > > >>> Nope to which part of his question? I thought the File API was an > > > >>> implementation of the W3C File API? Even the File API docs page > > > begins > > > >>> with: > > > >>> > > > >> > > > >> The question was about FIleTransfer, not File -- and I think that > the > > > nope > > > >> was to the published spec side of the disjunction. (But I'll let > Brian > > > >> clarify if I'm wrong) > > > >> > > > >> As far as I can tell, there isn't a FileTransfer.upload / > > > >> FileTransfer.download API anywhere else that's quite like the > Cordova > > > API. > > > >> > > > >> Ian > > > >> > > > >> > > > >>> > > > >>> "An API to read, write and navigate file system hierarchies, based > on > > > the > > > >>> w3c file api." > > > >>> > > > >>> John M. Wargo > > > >>> Twitter: @johnwargo > > > >>> > > > >>> > > > >>> -----Original Message----- > > > >>> From: brian.ler...@gmail.com [mailto:brian.ler...@gmail.com] On > > Behalf > > > >> Of > > > >>> Brian LeRoux > > > >>> Sent: Monday, November 18, 2013 5:11 PM > > > >>> To: dev@cordova.apache.org > > > >>> Subject: Re: Updating FileTransfer > > > >>> > > > >>> Answers inline. > > > >>> > > > >>> > > > >>>> Does FileTransfer implement any published standard, or is it our > own > > > >> API? > > > >>>> > > > >>>> Nope. > > > >>> > > > >>> > > > >>> > > > >>>> Does it make sense for FileTransfer to continue to use raw > > FileSystem > > > >>> paths > > > >>>> (and *not* go through File at all?) given that the File API will > > soon > > > >> be > > > >>>> returning only relative paths and filesystem:// URLs. > > > >>>> > > > >>>> Consistent w/ URL scheme makes sense to me but I'll let others > chime > > > in > > > >>> how this will break everything and our users will hate us. But > > > remember: > > > >>> plugins are versioned! > > > >>> > > > >> > > > > > > > > >
