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.
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.) >> >>
