On 10/12/13 05:02 PM, Ian Clelland wrote:
I'm fine with a BC break, but I don't have to maintain any legacy applications. /Library does make more sense as the default for PERSISTENT. The big problem with BC is for installed apps with existing data on the filesystem, right?Yep.I think that Library is the more natural place for the HTML persistent filesystem, since it's used by an app for whatever persistent storage it needs, without exposing all of it's implementation details to the user. (There's lots of room for debate on this, I'm sure) The trouble is that we've historically used /Documents for persistent storage, and changing that will break apps.
One idea is to allow something like requestFilesystem(DOCUMENT), in
addition to PERSISTENT and TEMPORARY. Another suggestion has been to add
extra arguments -- hints -- such as "{sync: true}", or maybe in this case
"{purpose: documents}" to specify the attributes of the filesystem that is
returned.
>{sync: true} is a bit tricky because /Library/Cache is not synced but /Library/Application Data is synced. Having a DOCUMENT type would match /tmp and /Library as the top-level dirs mapping to file-system constants.
All my feedback is only from the iOS perspective though. Not sure if these ideas make other platforms more or less complicated.
Cheers, Mike
On Tue, Dec 10, 2013 at 2:39 PM, Michael Gauthier <m...@silverorange.com>wrote:Hmm.. The two directories have different defined roles on iOS and both are normal targets for applications to read/write files. Library is for cache data or app-specific resources. Documents is for saving/loading actual things created by users within apps. See https://developer.apple.com/library/ios/documentation/ FileManagement/Conceptual/FileSystemProgrammingGuide/FileSystemOverview/ FileSystemOverview.html#//apple_ref/doc/uid/TP40010672-CH2-SW14 Supporting both should be a goal. Cheers, Mike On 2013-12-10 14:39, Ian Clelland wrote:If you could do that before, it was probably a bug :) (You shouldn't be able to use getParent on the filesystem root, and the native code was supposed to be checking for the correct path prefix before allowing access to any files on the device) At the moment, it's not possible to do that -- the filesystems should be properly isolated, and only allow access to correctly formed urls, like filesystem://localhost/persistent/some-file-here.txt. What we *can* do easily, though, is allow a new URL scheme for library assets; something like filesystem://localhost/library/some-file-here.txt, and we can have a filesystem handler for those URLs. That'll work if your use case is just "I need access to files in /Library", rather than "I need to get to them via string manipulation". I've also had some discussions about making /Library the default place for the persistent filesystem, and leaving /Documents either just for legacy apps, or making *that* the target of the special URL scheme. That's a proposal for a different day, though. There are some pretty big backwards-compatibility issues there. On Tue, Dec 10, 2013 at 11:54 AM, Michael Gauthier <m...@silverorange.comwrote:Ian,With the new URLs will it be possible to write to both /Documents and /Library for iOS apps? In the old version, the filesystem root resolved as /Documents but it was possible to get to /Library by navigating the the parent dir. Cheers, Mike On 2013-11-15 15:19, Ian Clelland wrote: On Fri, Nov 15, 2013 at 1:40 PM, purplecabbage <purplecabb...@gmail.comwrote: Considering the magnitude of the changes I would have expected that thiswas 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'tcaught 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 iPhoneOn 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 insubtasks.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 subtasksfor 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; nothingshould 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.comwrote: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 soundslike the [improved] tests should pass on both the old and newversions,which would be sweet.The filesystem URLs themselves will change as a result of this. The testsshould pass on both old and new versions, but the tests mint their ownURLsfor testing against -- each version is internally consistent, but ifanappis saving internal URLs and tries to dereference an old (file:///) urlwiththe 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? Ifso, would it make sense to reach out to those platform owners and at least getJira 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 startsupporting their own URL schemes (I think the BB folks can usesomethinglike 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.orgwrote:After working with the File plugin for a week or so, I've gotten itmore orless where I want it to be on iOS, and am working through Android.Lookingat the end result, though, I expect that over 90% of the code hasbeen touched in some way. (It's a huge diff.)
