cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tommy-Carlos Williams <to...@devgeeks.org>
Subject Re: Updating FileTransfer
Date Fri, 22 Nov 2013 23:44:24 GMT
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 <iclelland@chromium.org>wrote:
> 
>> On Fri, Nov 22, 2013 at 3:12 PM, Wargo, John <john.wargo@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.leroux@gmail.com [mailto:brian.leroux@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!
>>> 
>> 


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message