cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian LeRoux...@brian.io>
Subject Re: Transitioning to a better File API implementation
Date Fri, 15 Nov 2013 20:52:43 GMT
Awesome stuff Ian. Our community is going to love this.


On Fri, Nov 15, 2013 at 11:19 AM, Ian Clelland <iclelland@chromium.org>wrote:

> On Fri, Nov 15, 2013 at 1:40 PM, purplecabbage <purplecabbage@gmail.com
> >wrote:
>
> > Considering the magnitude of the changes I would have expected that this
> > was just a new file plugin. The previous version was based on a spec, and
> > if we are deviating from it we should probably maintain both, and
> possibly
> > even make a recommendation to the w3c.
> > I hope we at least do a major version update for this if APIs have
> changed.
> >
>
> Yes, definitely a major version bump, at least so that devs aren't caught
> by the URL-format-change.
>
> There aren't any changes to external APIs; I've been very careful to
> maintain conformance with the existing tests, except where those tests have
> been for undocumented implementation details. The only app-visible change
> is that URLs returned by the .toURL() method will look like
>
> filesystem://localhost/persistent/my/file.jpg
>
> rather than
>
> file:///var/mobile/Applications/<app id>/Documents/my/file.jpg
>
> We are still following the spec -- in fact, this brings us closer in line
> with the W3C File API spec, on these points:
>
> http://www.w3.org/TR/file-system-api/#widl-Entry-fullPath -- The fullPath
> of an entry should be the path from the root (of the HTML filesystem, not
> the underlying device file system).
>
> http://www.w3.org/TR/file-system-api/#widl-Entry-toURL-DOMString -- This
> is
> a note, rather than a requirement, but a filesystem url scheme is mentioned
> there.
>
> We're considering extending the spec in one way, which should be compatible
> with the spirit of the spec, and backwards-compatible with the previous
> API. That is the ability to declare new filesystem types, beyond
> "temporary" and "persistent", so that we can access things like device
> media and app bundle assets using the same APIs that we use for accessing
> user-defined files. If we're happy with the way that works, then we should
> definitely propose it for inclusion in the standard (not the specific
> filesystems, perhaps, but the mechanism for requesting and interacting with
> them)
>
> Ian
>
>
> >
> > Sent from my iPhone
> >
> > > On Nov 15, 2013, at 8:36 AM, Ian Clelland <iclelland@chromium.org>
> > wrote:
> > >
> > > I've created CB-5403 as the ├╝ber-ticket for this; various bits of it
> are
> > in
> > > subtasks.
> > >
> > > Once I have the tests and the JS updated, then platform owners can
> take a
> > > look and see whether they have anything to do to support their own
> > schemes.
> > >
> > > As general guidelines, I would say:
> > >
> > > * If you can intercept filesystem://* URLs in native code, and return
> > > arbitrary responses, then do it! It will let your platform support new
> > > filesystems in the future as we come up with them. Add a couple of
> > subtasks
> > > for CB-5403 for your platform and go.
> > >
> > > * If you can't do that, but you *can* provide access to things like
> media
> > > through special urls, then try that! You should be able to create a
> > > FileSystem object that uses that URL as its root, and everything should
> > > work. Add a subtask for that, and see what you can do.
> > >
> > > * If you can't do that either, and you just want to stick with the
> > file:///
> > > urls that we are currently using, then don't do anything; nothing
> should
> > > change for you.
> > >
> > >
> > >
> > > On Fri, Nov 15, 2013 at 10:36 AM, Ian Clelland <iclelland@chromium.org
> > >wrote:
> > >
> > >>
> > >> On Fri, Nov 15, 2013 at 10:03 AM, Marcel Kinard <cmarcelk@gmail.com
> > >wrote:
> > >>
> > >>> Ian, will there be changes that app developers will need to do? If
> so,
> > >>> those should be clearly documented in a migration guide. If not, it
> > sounds
> > >>> like the [improved] tests should pass on both the old and new
> versions,
> > >>> which would be sweet.
> > >>
> > >> The filesystem URLs themselves will change as a result of this. The
> > tests
> > >> should pass on both old and new versions, but the tests mint their own
> > URLs
> > >> for testing against -- each version is internally consistent, but if
> an
> > app
> > >> is saving internal URLs and tries to dereference an old (file:///) url
> > with
> > >> the new plugin, it will probably not resolve.
> > >>
> > >> Maybe there's a transition path here -- it might be possible to allow
> > >> window.resolveLocalFileSystemURL to access files with the old URL, but
> > >> never actually generate URLs.
> > >>
> > >> That would mean that
> > >>
> > >> (resolveLocalFileSystemURL(a)).toURL() !== a,
> > >>
> > >> but I don't think that we depend on that as an identity.
> > >>
> > >> Is there work which needs to be done on the other platforms (BB, WP8,
> > >>> Win8, FFOS, etc) so that those platforms don't get left behind? If
> so,
> > >>> would it make sense to reach out to those platform owners and at
> least
> > get
> > >>> Jira items created with some notes?
> > >>
> > >> Yes. I'm going to create a ticket for this, and we can add
> > >> platform-specific tasks to it.
> > >>
> > >> Other platforms shouldn't *have* to do anything, and some platforms
> > >> *can't* do anything, because they cannot access anything other than
> > >> file:/// urls anyway.
> > >>
> > >> However, if the other platforms want to get in on the goodness, and
> > start
> > >> supporting their own URL schemes (I think the BB folks can use
> something
> > >> like local:// for their filesystem access), then that'll be the place
> to
> > >> keep everything organized.
> > >>
> > >> I'll post back once I have that issue set up.
> > >>
> > >> Ian
> > >>
> > >>
> > >>> Sounds like you've built some very significant improvements. Thanks!
> > >>>
> > >>>> On Nov 15, 2013, at 9:29 AM, Ian Clelland <iclelland@chromium.org>
> > wrote:
> > >>>>
> > >>>> After working with the File plugin for a week or so, I've gotten
it
> > >>> more or
> > >>>> less where I want it to be on iOS, and am working through Android.
> > >>> Looking
> > >>>> at the end result, though, I expect that over 90% of the code has
> been
> > >>>> touched in some way. (It's a huge diff.)
> > >>
> > >>
> >
>

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