cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tommy Williams <to...@devgeeks.org>
Subject Re: Transitioning to a better File API implementation
Date Wed, 11 Dec 2013 19:18:33 GMT
Changing where PERSISTENT is located sounds like a very very bad idea.

I know that would cause me personally a lot of grief with existing user
data.
On 11/12/2013 8:58 am, "Ian Clelland" <iclelland@chromium.org> wrote:

> On Tue, Dec 10, 2013 at 4:37 PM, Michael Gauthier <mike@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 <
> mike@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 <
> >>>> 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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message