You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cordova.apache.org by Becky Gibson <gi...@gmail.com> on 2012/02/17 20:36:43 UTC
Changes to File API
I was running the mobile-spec after Shaz completed and checked in the iOS
name change (THANKS, Shaz!) and found that several file tests fail. The
issue is the name change of the <Entry>.toURI() api to <Entry>.toURL().
Checking on the W3C File API: Directories and Systems spec. this API was
indeed renamed from the October, 2010, version of the spec that we
implemented to the April and May, 2011 versions. The FileError codes have
also been reassigned - although that has not been updated in the unified-js
implementation.
Other than the API name change and FileError code reassignments, I don't
see major changes in the specification. However, this will certainly break
existing apps and I question making that change. I realize it has to be
made sooner or later, but it might be best to wait for the api to be
finalized. If we are going to make this api change, then we should
probably also make the FileError changes to be consistent. And update the
docs and make sure this is well documented.
my two cents,
-becky
Re: Changes to File API
Posted by Brian LeRoux <b...@brian.io>.
I'd like us to keep drawing our attention to that world 'everything is
a plugin'. That said, having tagged versions that target specific api
releases would be the way to go.
On Mon, Feb 20, 2012 at 10:10 AM, Dave Johnson <da...@gmail.com> wrote:
> In the land of "everything is a plugin" I guess those old versions just
> become another plugin that's available for use?
>
> On Monday, February 20, 2012, Patrick Mueller wrote:
>
>> On Mon, Feb 20, 2012 at 11:57, Dave Johnson <dave.c.johnson@gmail.com<javascript:;>
>> >wrote:
>>
>> > Yah I think that makes sense. We can even remove the old one when we hit
>> a
>> > major release.
>> >
>>
>> It's not clear what the lifetime of such "versioned spec'd APIs from
>> somewhere" should be.
>>
>> While it seems that we would certainly "drop support" for "old" versions of
>> spec impls, not sure that we'd want to remove them entirely. Maybe "old
>> versions" require a bit more work to "add" to your project - you have to
>> point to a repo with a version-specifc URL or something, rather than just
>> run a simpel command which does an "add the File API plugin".
>>
>> --
>> Patrick Mueller
>> http://muellerware.org
>>
Re: Changes to File API
Posted by Dave Johnson <da...@gmail.com>.
In the land of "everything is a plugin" I guess those old versions just
become another plugin that's available for use?
On Monday, February 20, 2012, Patrick Mueller wrote:
> On Mon, Feb 20, 2012 at 11:57, Dave Johnson <dave.c.johnson@gmail.com<javascript:;>
> >wrote:
>
> > Yah I think that makes sense. We can even remove the old one when we hit
> a
> > major release.
> >
>
> It's not clear what the lifetime of such "versioned spec'd APIs from
> somewhere" should be.
>
> While it seems that we would certainly "drop support" for "old" versions of
> spec impls, not sure that we'd want to remove them entirely. Maybe "old
> versions" require a bit more work to "add" to your project - you have to
> point to a repo with a version-specifc URL or something, rather than just
> run a simpel command which does an "add the File API plugin".
>
> --
> Patrick Mueller
> http://muellerware.org
>
Re: Changes to File API
Posted by Patrick Mueller <pm...@gmail.com>.
On Mon, Feb 20, 2012 at 11:57, Dave Johnson <da...@gmail.com>wrote:
> Yah I think that makes sense. We can even remove the old one when we hit a
> major release.
>
It's not clear what the lifetime of such "versioned spec'd APIs from
somewhere" should be.
While it seems that we would certainly "drop support" for "old" versions of
spec impls, not sure that we'd want to remove them entirely. Maybe "old
versions" require a bit more work to "add" to your project - you have to
point to a repo with a version-specifc URL or something, rather than just
run a simpel command which does an "add the File API plugin".
--
Patrick Mueller
http://muellerware.org
Re: Changes to File API
Posted by Dave Johnson <da...@gmail.com>.
Yah I think that makes sense. We can even remove the old one when we hit a
major release.
-dave
On Monday, February 20, 2012, Patrick Mueller wrote:
> On Fri, Feb 17, 2012 at 15:33, Dave Johnson <dave.c.johnson@gmail.com<javascript:;>
> >wrote:
>
> > For all of these sorts of changes lets endevour to maintain backwards
> > compatibility and put in deprecation notices. Ideally the deprecated APIs
> > are removed at a major version change, e.g. when we hit 2.0.
>
>
> This will always be a problem for us, in terms of tracking developing APIs
> as they change over time.
>
> I think my take would be that what we want to do is support specific
> versions, and not have a version which is somehow morphing over time. Eg,
> we should have two versions of the File API for the following "versions" of
> the spec that I noticed:
>
> * http://www.w3.org/TR/2010/WD-FileAPI-20101026/
> * http://www.w3.org/TR/2011/WD-FileAPI-20111020/
>
> The default is that you get the latest one. If for some reason, you need
> the old one, then you would need to do something special:
>
> cordova add-plugin file-api@w3c-20101026
>
> or something.
>
> --
> Patrick Mueller
> http://muellerware.org
>
Re: Changes to File API
Posted by Patrick Mueller <pm...@gmail.com>.
On Fri, Feb 17, 2012 at 15:33, Dave Johnson <da...@gmail.com>wrote:
> For all of these sorts of changes lets endevour to maintain backwards
> compatibility and put in deprecation notices. Ideally the deprecated APIs
> are removed at a major version change, e.g. when we hit 2.0.
This will always be a problem for us, in terms of tracking developing APIs
as they change over time.
I think my take would be that what we want to do is support specific
versions, and not have a version which is somehow morphing over time. Eg,
we should have two versions of the File API for the following "versions" of
the spec that I noticed:
* http://www.w3.org/TR/2010/WD-FileAPI-20101026/
* http://www.w3.org/TR/2011/WD-FileAPI-20111020/
The default is that you get the latest one. If for some reason, you need
the old one, then you would need to do something special:
cordova add-plugin file-api@w3c-20101026
or something.
--
Patrick Mueller
http://muellerware.org
Re: Changes to File API
Posted by Dave Johnson <da...@gmail.com>.
For all of these sorts of changes lets endevour to maintain backwards
compatibility and put in deprecation notices. Ideally the deprecated APIs
are removed at a major version change, e.g. when we hit 2.0.
On Friday, February 17, 2012, Filip Maj wrote:
> I like that idea, Simon. Simple to add a method copy from toURL -> toURI,
> add a console.log, tag for 1.5, done.
>
> As for updating the error codes - can we shelve that for 1.6?
>
> On 12-02-17 11:52 AM, "Simon MacDonald" <simon.macdonald@gmail.com<javascript:;>>
> wrote:
>
> >For the 1.5.0 release can we support <Entry>.toURI() and <Entry>.toURL()?
> >We'll mark toURI as deprecated and remove it in 1.6.0 or 1.7.0. What do
> >you
> >think?
> >
> >As for the FileError codes. Grrrrr...why did they have to change them.
> >
> >Simon Mac Donald
> >http://hi.im/simonmacdonald
> >
> >
> >On Fri, Feb 17, 2012 at 2:36 PM, Becky Gibson
> ><gibson.becky@gmail.com <javascript:;>>wrote:
> >
> >> I was running the mobile-spec after Shaz completed and checked in the
> >>iOS
> >> name change (THANKS, Shaz!) and found that several file tests fail. The
> >> issue is the name change of the <Entry>.toURI() api to <Entry>.toURL().
> >> Checking on the W3C File API: Directories and Systems spec. this API was
> >> indeed renamed from the October, 2010, version of the spec that we
> >> implemented to the April and May, 2011 versions. The FileError codes
> >>have
> >> also been reassigned - although that has not been updated in the
> >>unified-js
> >> implementation.
> >>
> >> Other than the API name change and FileError code reassignments, I don't
> >> see major changes in the specification. However, this will certainly
> >>break
> >> existing apps and I question making that change. I realize it has to
> >>be
> >> made sooner or later, but it might be best to wait for the api to be
> >> finalized. If we are going to make this api change, then we should
> >> probably also make the FileError changes to be consistent. And update
> >>the
> >> docs and make sure this is well documented.
> >>
> >> my two cents,
> >> -becky
> >>
>
>
Re: Changes to File API
Posted by Simon MacDonald <si...@gmail.com>.
Okay, here is the updated commit.
https://github.com/macdonst/callback-js/commit/bd36b200f61754e15467cb3617738f410018f451
If I don't get any objections I will push it up after my next meeting.
Simon Mac Donald
http://hi.im/simonmacdonald
On Wed, Feb 22, 2012 at 1:01 PM, Filip Maj <fi...@adobe.com> wrote:
> +1 to taking it out - not even exactly sure what it's there for
>
> "Users may supply mimeType in order to simulate the optional mime-type
> header associated with HTTP downloads."
>
> On 12-02-22 9:42 AM, "Simon MacDonald" <si...@gmail.com> wrote:
>
> >It is in this spec which is the working draft:
> >
> >http://www.w3.org/TR/file-system-api/#widl-Entry-toURL
> >
> >but not in the editors draft:
> >
> >http://dev.w3.org/2009/dap/file-system/file-dir-sys.html
> >
> >so I'm happy to take it out if everyone is okay with that.
> >
> >Simon Mac Donald
> >http://hi.im/simonmacdonald
> >
> >
> >On Wed, Feb 22, 2012 at 12:33 PM, Drew Walters <de...@gmail.com>
> wrote:
> >
> >> mimetype is not a parameter of toURL either though right?
> >>
> >> On Wed, Feb 22, 2012 at 11:30 AM, Simon MacDonald
> >> <si...@gmail.com> wrote:
> >> > Okay, I've just put a change that adds toURI back into the Entry class
> >> for
> >> > backwards compatibility. I also removed the success/error parameters
> >>from
> >> > toURL as they are not according spec and they are never used.
> >> >
> >> > Take a look at the change and let me know if anything else is needed:
> >> >
> >> >
> >>
> >>
> https://github.com/macdonst/callback-js/commit/de67a919af0aa5bdc81ab3c2ee
> >>ce1ed17a7fd9de
> >> >
> >> > If I get a +1 I'll merge the code into the Apache cordova-js repo.
> >> >
> >> > Simon Mac Donald
> >> > http://hi.im/simonmacdonald
> >> >
> >> >
> >> > On Fri, Feb 17, 2012 at 2:55 PM, Filip Maj <fi...@adobe.com> wrote:
> >> >
> >> >> I like that idea, Simon. Simple to add a method copy from toURL ->
> >> toURI,
> >> >> add a console.log, tag for 1.5, done.
> >> >>
> >> >> As for updating the error codes - can we shelve that for 1.6?
> >> >>
> >> >> On 12-02-17 11:52 AM, "Simon MacDonald" <si...@gmail.com>
> >> wrote:
> >> >>
> >> >> >For the 1.5.0 release can we support <Entry>.toURI() and
> >> <Entry>.toURL()?
> >> >> >We'll mark toURI as deprecated and remove it in 1.6.0 or 1.7.0.
> >>What do
> >> >> >you
> >> >> >think?
> >> >> >
> >> >> >As for the FileError codes. Grrrrr...why did they have to change
> >>them.
> >> >> >
> >> >> >Simon Mac Donald
> >> >> >http://hi.im/simonmacdonald
> >> >> >
> >> >> >
> >> >> >On Fri, Feb 17, 2012 at 2:36 PM, Becky Gibson
> >> >> ><gi...@gmail.com>wrote:
> >> >> >
> >> >> >> I was running the mobile-spec after Shaz completed and checked in
> >>the
> >> >> >>iOS
> >> >> >> name change (THANKS, Shaz!) and found that several file tests
> >>fail.
> >> The
> >> >> >> issue is the name change of the <Entry>.toURI() api to
> >> <Entry>.toURL().
> >> >> >> Checking on the W3C File API: Directories and Systems spec. this
> >>API
> >> was
> >> >> >> indeed renamed from the October, 2010, version of the spec that we
> >> >> >> implemented to the April and May, 2011 versions. The FileError
> >> codes
> >> >> >>have
> >> >> >> also been reassigned - although that has not been updated in the
> >> >> >>unified-js
> >> >> >> implementation.
> >> >> >>
> >> >> >> Other than the API name change and FileError code reassignments, I
> >> don't
> >> >> >> see major changes in the specification. However, this will
> >>certainly
> >> >> >>break
> >> >> >> existing apps and I question making that change. I realize it
> >>has
> >> to
> >> >> >>be
> >> >> >> made sooner or later, but it might be best to wait for the api to
> >>be
> >> >> >> finalized. If we are going to make this api change, then we
> >>should
> >> >> >> probably also make the FileError changes to be consistent. And
> >> update
> >> >> >>the
> >> >> >> docs and make sure this is well documented.
> >> >> >>
> >> >> >> my two cents,
> >> >> >> -becky
> >> >> >>
> >> >>
> >> >>
> >>
>
>
Re: Changes to File API
Posted by Filip Maj <fi...@adobe.com>.
+1 to taking it out - not even exactly sure what it's there for
"Users may supply mimeType in order to simulate the optional mime-type
header associated with HTTP downloads."
On 12-02-22 9:42 AM, "Simon MacDonald" <si...@gmail.com> wrote:
>It is in this spec which is the working draft:
>
>http://www.w3.org/TR/file-system-api/#widl-Entry-toURL
>
>but not in the editors draft:
>
>http://dev.w3.org/2009/dap/file-system/file-dir-sys.html
>
>so I'm happy to take it out if everyone is okay with that.
>
>Simon Mac Donald
>http://hi.im/simonmacdonald
>
>
>On Wed, Feb 22, 2012 at 12:33 PM, Drew Walters <de...@gmail.com> wrote:
>
>> mimetype is not a parameter of toURL either though right?
>>
>> On Wed, Feb 22, 2012 at 11:30 AM, Simon MacDonald
>> <si...@gmail.com> wrote:
>> > Okay, I've just put a change that adds toURI back into the Entry class
>> for
>> > backwards compatibility. I also removed the success/error parameters
>>from
>> > toURL as they are not according spec and they are never used.
>> >
>> > Take a look at the change and let me know if anything else is needed:
>> >
>> >
>>
>>https://github.com/macdonst/callback-js/commit/de67a919af0aa5bdc81ab3c2ee
>>ce1ed17a7fd9de
>> >
>> > If I get a +1 I'll merge the code into the Apache cordova-js repo.
>> >
>> > Simon Mac Donald
>> > http://hi.im/simonmacdonald
>> >
>> >
>> > On Fri, Feb 17, 2012 at 2:55 PM, Filip Maj <fi...@adobe.com> wrote:
>> >
>> >> I like that idea, Simon. Simple to add a method copy from toURL ->
>> toURI,
>> >> add a console.log, tag for 1.5, done.
>> >>
>> >> As for updating the error codes - can we shelve that for 1.6?
>> >>
>> >> On 12-02-17 11:52 AM, "Simon MacDonald" <si...@gmail.com>
>> wrote:
>> >>
>> >> >For the 1.5.0 release can we support <Entry>.toURI() and
>> <Entry>.toURL()?
>> >> >We'll mark toURI as deprecated and remove it in 1.6.0 or 1.7.0.
>>What do
>> >> >you
>> >> >think?
>> >> >
>> >> >As for the FileError codes. Grrrrr...why did they have to change
>>them.
>> >> >
>> >> >Simon Mac Donald
>> >> >http://hi.im/simonmacdonald
>> >> >
>> >> >
>> >> >On Fri, Feb 17, 2012 at 2:36 PM, Becky Gibson
>> >> ><gi...@gmail.com>wrote:
>> >> >
>> >> >> I was running the mobile-spec after Shaz completed and checked in
>>the
>> >> >>iOS
>> >> >> name change (THANKS, Shaz!) and found that several file tests
>>fail.
>> The
>> >> >> issue is the name change of the <Entry>.toURI() api to
>> <Entry>.toURL().
>> >> >> Checking on the W3C File API: Directories and Systems spec. this
>>API
>> was
>> >> >> indeed renamed from the October, 2010, version of the spec that we
>> >> >> implemented to the April and May, 2011 versions. The FileError
>> codes
>> >> >>have
>> >> >> also been reassigned - although that has not been updated in the
>> >> >>unified-js
>> >> >> implementation.
>> >> >>
>> >> >> Other than the API name change and FileError code reassignments, I
>> don't
>> >> >> see major changes in the specification. However, this will
>>certainly
>> >> >>break
>> >> >> existing apps and I question making that change. I realize it
>>has
>> to
>> >> >>be
>> >> >> made sooner or later, but it might be best to wait for the api to
>>be
>> >> >> finalized. If we are going to make this api change, then we
>>should
>> >> >> probably also make the FileError changes to be consistent. And
>> update
>> >> >>the
>> >> >> docs and make sure this is well documented.
>> >> >>
>> >> >> my two cents,
>> >> >> -becky
>> >> >>
>> >>
>> >>
>>
Re: Changes to File API
Posted by Simon MacDonald <si...@gmail.com>.
It is in this spec which is the working draft:
http://www.w3.org/TR/file-system-api/#widl-Entry-toURL
but not in the editors draft:
http://dev.w3.org/2009/dap/file-system/file-dir-sys.html
so I'm happy to take it out if everyone is okay with that.
Simon Mac Donald
http://hi.im/simonmacdonald
On Wed, Feb 22, 2012 at 12:33 PM, Drew Walters <de...@gmail.com> wrote:
> mimetype is not a parameter of toURL either though right?
>
> On Wed, Feb 22, 2012 at 11:30 AM, Simon MacDonald
> <si...@gmail.com> wrote:
> > Okay, I've just put a change that adds toURI back into the Entry class
> for
> > backwards compatibility. I also removed the success/error parameters from
> > toURL as they are not according spec and they are never used.
> >
> > Take a look at the change and let me know if anything else is needed:
> >
> >
> https://github.com/macdonst/callback-js/commit/de67a919af0aa5bdc81ab3c2eece1ed17a7fd9de
> >
> > If I get a +1 I'll merge the code into the Apache cordova-js repo.
> >
> > Simon Mac Donald
> > http://hi.im/simonmacdonald
> >
> >
> > On Fri, Feb 17, 2012 at 2:55 PM, Filip Maj <fi...@adobe.com> wrote:
> >
> >> I like that idea, Simon. Simple to add a method copy from toURL ->
> toURI,
> >> add a console.log, tag for 1.5, done.
> >>
> >> As for updating the error codes - can we shelve that for 1.6?
> >>
> >> On 12-02-17 11:52 AM, "Simon MacDonald" <si...@gmail.com>
> wrote:
> >>
> >> >For the 1.5.0 release can we support <Entry>.toURI() and
> <Entry>.toURL()?
> >> >We'll mark toURI as deprecated and remove it in 1.6.0 or 1.7.0. What do
> >> >you
> >> >think?
> >> >
> >> >As for the FileError codes. Grrrrr...why did they have to change them.
> >> >
> >> >Simon Mac Donald
> >> >http://hi.im/simonmacdonald
> >> >
> >> >
> >> >On Fri, Feb 17, 2012 at 2:36 PM, Becky Gibson
> >> ><gi...@gmail.com>wrote:
> >> >
> >> >> I was running the mobile-spec after Shaz completed and checked in the
> >> >>iOS
> >> >> name change (THANKS, Shaz!) and found that several file tests fail.
> The
> >> >> issue is the name change of the <Entry>.toURI() api to
> <Entry>.toURL().
> >> >> Checking on the W3C File API: Directories and Systems spec. this API
> was
> >> >> indeed renamed from the October, 2010, version of the spec that we
> >> >> implemented to the April and May, 2011 versions. The FileError
> codes
> >> >>have
> >> >> also been reassigned - although that has not been updated in the
> >> >>unified-js
> >> >> implementation.
> >> >>
> >> >> Other than the API name change and FileError code reassignments, I
> don't
> >> >> see major changes in the specification. However, this will certainly
> >> >>break
> >> >> existing apps and I question making that change. I realize it has
> to
> >> >>be
> >> >> made sooner or later, but it might be best to wait for the api to be
> >> >> finalized. If we are going to make this api change, then we should
> >> >> probably also make the FileError changes to be consistent. And
> update
> >> >>the
> >> >> docs and make sure this is well documented.
> >> >>
> >> >> my two cents,
> >> >> -becky
> >> >>
> >>
> >>
>
Re: Changes to File API
Posted by Drew Walters <de...@gmail.com>.
mimetype is not a parameter of toURL either though right?
On Wed, Feb 22, 2012 at 11:30 AM, Simon MacDonald
<si...@gmail.com> wrote:
> Okay, I've just put a change that adds toURI back into the Entry class for
> backwards compatibility. I also removed the success/error parameters from
> toURL as they are not according spec and they are never used.
>
> Take a look at the change and let me know if anything else is needed:
>
> https://github.com/macdonst/callback-js/commit/de67a919af0aa5bdc81ab3c2eece1ed17a7fd9de
>
> If I get a +1 I'll merge the code into the Apache cordova-js repo.
>
> Simon Mac Donald
> http://hi.im/simonmacdonald
>
>
> On Fri, Feb 17, 2012 at 2:55 PM, Filip Maj <fi...@adobe.com> wrote:
>
>> I like that idea, Simon. Simple to add a method copy from toURL -> toURI,
>> add a console.log, tag for 1.5, done.
>>
>> As for updating the error codes - can we shelve that for 1.6?
>>
>> On 12-02-17 11:52 AM, "Simon MacDonald" <si...@gmail.com> wrote:
>>
>> >For the 1.5.0 release can we support <Entry>.toURI() and <Entry>.toURL()?
>> >We'll mark toURI as deprecated and remove it in 1.6.0 or 1.7.0. What do
>> >you
>> >think?
>> >
>> >As for the FileError codes. Grrrrr...why did they have to change them.
>> >
>> >Simon Mac Donald
>> >http://hi.im/simonmacdonald
>> >
>> >
>> >On Fri, Feb 17, 2012 at 2:36 PM, Becky Gibson
>> ><gi...@gmail.com>wrote:
>> >
>> >> I was running the mobile-spec after Shaz completed and checked in the
>> >>iOS
>> >> name change (THANKS, Shaz!) and found that several file tests fail. The
>> >> issue is the name change of the <Entry>.toURI() api to <Entry>.toURL().
>> >> Checking on the W3C File API: Directories and Systems spec. this API was
>> >> indeed renamed from the October, 2010, version of the spec that we
>> >> implemented to the April and May, 2011 versions. The FileError codes
>> >>have
>> >> also been reassigned - although that has not been updated in the
>> >>unified-js
>> >> implementation.
>> >>
>> >> Other than the API name change and FileError code reassignments, I don't
>> >> see major changes in the specification. However, this will certainly
>> >>break
>> >> existing apps and I question making that change. I realize it has to
>> >>be
>> >> made sooner or later, but it might be best to wait for the api to be
>> >> finalized. If we are going to make this api change, then we should
>> >> probably also make the FileError changes to be consistent. And update
>> >>the
>> >> docs and make sure this is well documented.
>> >>
>> >> my two cents,
>> >> -becky
>> >>
>>
>>
Re: Changes to File API
Posted by Simon MacDonald <si...@gmail.com>.
Okay, I've just put a change that adds toURI back into the Entry class for
backwards compatibility. I also removed the success/error parameters from
toURL as they are not according spec and they are never used.
Take a look at the change and let me know if anything else is needed:
https://github.com/macdonst/callback-js/commit/de67a919af0aa5bdc81ab3c2eece1ed17a7fd9de
If I get a +1 I'll merge the code into the Apache cordova-js repo.
Simon Mac Donald
http://hi.im/simonmacdonald
On Fri, Feb 17, 2012 at 2:55 PM, Filip Maj <fi...@adobe.com> wrote:
> I like that idea, Simon. Simple to add a method copy from toURL -> toURI,
> add a console.log, tag for 1.5, done.
>
> As for updating the error codes - can we shelve that for 1.6?
>
> On 12-02-17 11:52 AM, "Simon MacDonald" <si...@gmail.com> wrote:
>
> >For the 1.5.0 release can we support <Entry>.toURI() and <Entry>.toURL()?
> >We'll mark toURI as deprecated and remove it in 1.6.0 or 1.7.0. What do
> >you
> >think?
> >
> >As for the FileError codes. Grrrrr...why did they have to change them.
> >
> >Simon Mac Donald
> >http://hi.im/simonmacdonald
> >
> >
> >On Fri, Feb 17, 2012 at 2:36 PM, Becky Gibson
> ><gi...@gmail.com>wrote:
> >
> >> I was running the mobile-spec after Shaz completed and checked in the
> >>iOS
> >> name change (THANKS, Shaz!) and found that several file tests fail. The
> >> issue is the name change of the <Entry>.toURI() api to <Entry>.toURL().
> >> Checking on the W3C File API: Directories and Systems spec. this API was
> >> indeed renamed from the October, 2010, version of the spec that we
> >> implemented to the April and May, 2011 versions. The FileError codes
> >>have
> >> also been reassigned - although that has not been updated in the
> >>unified-js
> >> implementation.
> >>
> >> Other than the API name change and FileError code reassignments, I don't
> >> see major changes in the specification. However, this will certainly
> >>break
> >> existing apps and I question making that change. I realize it has to
> >>be
> >> made sooner or later, but it might be best to wait for the api to be
> >> finalized. If we are going to make this api change, then we should
> >> probably also make the FileError changes to be consistent. And update
> >>the
> >> docs and make sure this is well documented.
> >>
> >> my two cents,
> >> -becky
> >>
>
>
Re: Changes to File API
Posted by Filip Maj <fi...@adobe.com>.
I like that idea, Simon. Simple to add a method copy from toURL -> toURI,
add a console.log, tag for 1.5, done.
As for updating the error codes - can we shelve that for 1.6?
On 12-02-17 11:52 AM, "Simon MacDonald" <si...@gmail.com> wrote:
>For the 1.5.0 release can we support <Entry>.toURI() and <Entry>.toURL()?
>We'll mark toURI as deprecated and remove it in 1.6.0 or 1.7.0. What do
>you
>think?
>
>As for the FileError codes. Grrrrr...why did they have to change them.
>
>Simon Mac Donald
>http://hi.im/simonmacdonald
>
>
>On Fri, Feb 17, 2012 at 2:36 PM, Becky Gibson
><gi...@gmail.com>wrote:
>
>> I was running the mobile-spec after Shaz completed and checked in the
>>iOS
>> name change (THANKS, Shaz!) and found that several file tests fail. The
>> issue is the name change of the <Entry>.toURI() api to <Entry>.toURL().
>> Checking on the W3C File API: Directories and Systems spec. this API was
>> indeed renamed from the October, 2010, version of the spec that we
>> implemented to the April and May, 2011 versions. The FileError codes
>>have
>> also been reassigned - although that has not been updated in the
>>unified-js
>> implementation.
>>
>> Other than the API name change and FileError code reassignments, I don't
>> see major changes in the specification. However, this will certainly
>>break
>> existing apps and I question making that change. I realize it has to
>>be
>> made sooner or later, but it might be best to wait for the api to be
>> finalized. If we are going to make this api change, then we should
>> probably also make the FileError changes to be consistent. And update
>>the
>> docs and make sure this is well documented.
>>
>> my two cents,
>> -becky
>>
Re: Changes to File API
Posted by Simon MacDonald <si...@gmail.com>.
For the 1.5.0 release can we support <Entry>.toURI() and <Entry>.toURL()?
We'll mark toURI as deprecated and remove it in 1.6.0 or 1.7.0. What do you
think?
As for the FileError codes. Grrrrr...why did they have to change them.
Simon Mac Donald
http://hi.im/simonmacdonald
On Fri, Feb 17, 2012 at 2:36 PM, Becky Gibson <gi...@gmail.com>wrote:
> I was running the mobile-spec after Shaz completed and checked in the iOS
> name change (THANKS, Shaz!) and found that several file tests fail. The
> issue is the name change of the <Entry>.toURI() api to <Entry>.toURL().
> Checking on the W3C File API: Directories and Systems spec. this API was
> indeed renamed from the October, 2010, version of the spec that we
> implemented to the April and May, 2011 versions. The FileError codes have
> also been reassigned - although that has not been updated in the unified-js
> implementation.
>
> Other than the API name change and FileError code reassignments, I don't
> see major changes in the specification. However, this will certainly break
> existing apps and I question making that change. I realize it has to be
> made sooner or later, but it might be best to wait for the api to be
> finalized. If we are going to make this api change, then we should
> probably also make the FileError changes to be consistent. And update the
> docs and make sure this is well documented.
>
> my two cents,
> -becky
>
Re: Changes to File API
Posted by Becky Gibson <gi...@gmail.com>.
Yes, it isn't a huge change but could be a gotcha for many folks. Also, the
new toURL() API no longer takes the mimetype parameter. So we need to
modify the entry.js one way or another.
-b
On Fri, Feb 17, 2012 at 2:48 PM, Filip Maj <fi...@adobe.com> wrote:
> Yeah I made the change in cordova-js to the new API as I was going over
> our File API implementation with a magnifying glass and make sure it was
> doing the right things.
>
> I'm ambivalent either way, really.
>
> On 12-02-17 11:36 AM, "Becky Gibson" <gi...@gmail.com> wrote:
>
> >I was running the mobile-spec after Shaz completed and checked in the iOS
> >name change (THANKS, Shaz!) and found that several file tests fail. The
> >issue is the name change of the <Entry>.toURI() api to <Entry>.toURL().
> >Checking on the W3C File API: Directories and Systems spec. this API was
> >indeed renamed from the October, 2010, version of the spec that we
> >implemented to the April and May, 2011 versions. The FileError codes
> >have
> >also been reassigned - although that has not been updated in the
> >unified-js
> >implementation.
> >
> >Other than the API name change and FileError code reassignments, I don't
> >see major changes in the specification. However, this will certainly
> >break
> >existing apps and I question making that change. I realize it has to be
> >made sooner or later, but it might be best to wait for the api to be
> >finalized. If we are going to make this api change, then we should
> >probably also make the FileError changes to be consistent. And update the
> >docs and make sure this is well documented.
> >
> >my two cents,
> >-becky
>
>
Re: Changes to File API
Posted by Filip Maj <fi...@adobe.com>.
Yeah I made the change in cordova-js to the new API as I was going over
our File API implementation with a magnifying glass and make sure it was
doing the right things.
I'm ambivalent either way, really.
On 12-02-17 11:36 AM, "Becky Gibson" <gi...@gmail.com> wrote:
>I was running the mobile-spec after Shaz completed and checked in the iOS
>name change (THANKS, Shaz!) and found that several file tests fail. The
>issue is the name change of the <Entry>.toURI() api to <Entry>.toURL().
>Checking on the W3C File API: Directories and Systems spec. this API was
>indeed renamed from the October, 2010, version of the spec that we
>implemented to the April and May, 2011 versions. The FileError codes
>have
>also been reassigned - although that has not been updated in the
>unified-js
>implementation.
>
>Other than the API name change and FileError code reassignments, I don't
>see major changes in the specification. However, this will certainly
>break
>existing apps and I question making that change. I realize it has to be
>made sooner or later, but it might be best to wait for the api to be
>finalized. If we are going to make this api change, then we should
>probably also make the FileError changes to be consistent. And update the
>docs and make sure this is well documented.
>
>my two cents,
>-becky