incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dave Johnson <dave.c.john...@gmail.com>
Subject Re: Changes to File API
Date Fri, 17 Feb 2012 20:33:13 GMT
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
> >>
>
>

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