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