Mailing-List: contact dev-help@cordova.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cordova.apache.org
Received-SPF: pass (athena.apache.org: domain of tommy@devgeeks.org designates
 209.85.160.50 as permitted sender)
From: Tommy-Carlos Williams <tommy@devgeeks.org>
Content-Type: multipart/alternative;
 boundary="Apple-Mail=_0B1DAE5F-CDB7-4313-A390-0902CE4B2F4A"
Message-Id: <4A8488A3-8A14-4C0D-AFF7-88C37D4A654E@devgeeks.org>
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1812\))
Subject: Re: Updating FileTransfer
Date: Sat, 23 Nov 2013 10:44:24 +1100
References: 
 <CAK_TSXKZd+NWjzDdJfigNs35P7kNCym+6GnFTC75vTYVOOpJUg@mail.gmail.com>
 <CADVgkyNDHQU9aOBWpFB1wOf9HnaXuzWjTQyVS7kfUDddz3oH2w@mail.gmail.com>
 <5900F9BCB827854FB01CA94BA718810D1E73DE7E@USPHLEMB11A.global.corp.sap>
 <CAK_TSXLkwPth9Nr6nTKLJNsOMcq8f1MePaaAXShON9NSuiyJ7A@mail.gmail.com>
 <CADVgkyN9gyTGi4c6iL+719z9-3h0i2o6eqskP=7D19jkEi=N6Q@mail.gmail.com>
To: dev@cordova.apache.org
In-Reply-To: 
 <CADVgkyN9gyTGi4c6iL+719z9-3h0i2o6eqskP=7D19jkEi=N6Q@mail.gmail.com>

--Apple-Mail=_0B1DAE5F-CDB7-4313-A390-0902CE4B2F4A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

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=85 but =
isn=92t that what we seem to already be discussing?

1. http://caniuse.com/#feat=3Dxhr2

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.)
>=20
>=20
> On Fri, Nov 22, 2013 at 12:16 PM, Ian Clelland =
<iclelland@chromium.org>wrote:
>=20
>> On Fri, Nov 22, 2013 at 3:12 PM, Wargo, John <john.wargo@sap.com> =
wrote:
>>=20
>>> Brian,
>>>=20
>>> 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:
>>>=20
>>=20
>> 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)
>>=20
>> As far as I can tell, there isn't a FileTransfer.upload /
>> FileTransfer.download API anywhere else that's quite like the Cordova =
API.
>>=20
>> Ian
>>=20
>>=20
>>>=20
>>> "An API to read, write and navigate file system hierarchies, based =
on the
>>> w3c file api."
>>>=20
>>> John M. Wargo
>>> Twitter: @johnwargo
>>>=20
>>>=20
>>> -----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
>>>=20
>>> Answers inline.
>>>=20
>>>=20
>>>> Does FileTransfer implement any published standard, or is it our =
own
>> API?
>>>>=20
>>>> Nope.
>>>=20
>>>=20
>>>=20
>>>> 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.
>>>>=20
>>>> 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!
>>>=20
>>=20


--Apple-Mail=_0B1DAE5F-CDB7-4313-A390-0902CE4B2F4A--