cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From purplecabbage <purplecabb...@gmail.com>
Subject Re: Transitioning to a better File API implementation
Date Fri, 15 Nov 2013 18:40:04 GMT
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. 

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