On Tue, Dec 10, 2013 at 4:37 PM, Michael Gauthier <m...@silverorange.com>wrote:
> On 10/12/13 05:02 PM, Ian Clelland wrote:
>
>> 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.
>>
>> 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?
Exactly. I'd hate for developers to update their plugins, and push a new
version of their app that seems fine -- everything works great when you
start from scratch -- but users with existing data find themselves
completely locked out of it.
>
> 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.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 <
>>>>> 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.)
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
