cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Gauthier <m...@silverorange.com>
Subject Re: Transitioning to a better File API implementation
Date Tue, 10 Dec 2013 19:39:37 GMT
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 <mike@silverorange.com>wrote:
>
>> 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 <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
View raw message