Awesome stuff Ian. Our community is going to love this.
On Fri, Nov 15, 2013 at 11:19 AM, Ian Clelland <iclell...@chromium.org>wrote: > On Fri, Nov 15, 2013 at 1:40 PM, purplecabbage <purplecabb...@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 <iclell...@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 <iclell...@chromium.org > > >wrote: > > > > > >> > > >> On Fri, Nov 15, 2013 at 10:03 AM, Marcel Kinard <cmarc...@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 <iclell...@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.) > > >> > > >> > > >
