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:33:39 GMT
+1
On 12/12/2013 6:26 am, "Ian Clelland" <iclelland@chromium.org> wrote:

> Yeah, it would definitely require some kind of migration support. Not
> suggesting that this is something that we ever actually do, but we could
> give developers a bit of code that automatically looks in both places, and
> moves files to the new location on open. Or we do it under a flag that is
> off for existing apps (off-on-upgrade) and only enabled-by-default for new
> apps.
>
> I agree with you: this could cause worlds of pain, with developers, and
> worse with users. We shouldn't take any steps in that direction without a
> lot of very careful thought. For now, /Documents, sub-optimal though it may
> be, is where Cordova puts persistent files.
>
> Ian
>
> On Wed, Dec 11, 2013 at 2:18 PM, Tommy Williams <tommy@devgeeks.org>
> wrote:
>
> > 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