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