Re: File API - where are the missing parts?

On Tue, Feb 23, 2016 at 7:06 PM, Joshua Bell <jsbell@google.com> wrote:

> On Tue, Feb 23, 2016 at 7:12 AM, Florian Bösch <pyalot@gmail.com> wrote:
>
>> On Tue, Feb 23, 2016 at 2:48 AM, Jonas Sicking <jonas@sicking.cc> wrote:
>>
>>> Is the last bullet here really accurate? How can you use existing APIs
>>> to listen to file modifications?
>>>
>> I have not tested this on all UAs, but in Google Chrome what you can do
>> is to set an interval to check a files.lastModified date, and if a
>> modification is detected, read it in again with a FileReader and that works
>> fine.
>>
>
> Huh... we should probably specify and/or fix that.
>
Specify rather than fix, please.


> There are also APIs implemented in several browsers for opening a whole
>>> directory of files from a webpage. This has been possible for some time in
>>> Chrome, and support was also recently added to Firefox and Edge. I'm not
>>> sure how interoperable these APIs are across browsers though :(
>>>
>>
> IIRC, Edge's API[1] mimics Chrome's, and you can polyfill Firefox's API
> [2] on top of Chrome/Edge's[3]. So in theory if Firefox's pleases
> developers they can adopt the polyfill, and other browsers can transition
> to native support.
>
> [1] https://lists.w3.org/Archives/Public/public-wicg/2015Sep/0000.html
> [2] https://wicg.github.io/directory-upload/proposal.html
> [3] https://github.com/WICG/directory-upload/blob/gh-pages/polyfill.js
>
> ... or just read Ali's excellent summary:
>
> https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0245.html
>
> (But that's all a tangent to Florian's main use cases...)
>
It's good to know this on a standards track.

True, but if we determine that permissions must be granted then the API
> needs to be designed to handle it, e.g. entry points to the API surface are
> through a requestPermission() API, everything is async, etc.
>

Ack


> One concern is: what capabilities are granted by this action? Can the
> web-app re-save the file? Can it re-read the file? Does that permission
> persist across sessions? For example, if I save a document template from a
> site I would not expect the site to be able to read the file after I've
> edited with an unrelated file editor.
>
>>
>>    - Save many files to a user pickable folder: same as above
>>    - Working directory: this is more something that would go on in the
>>    background of a UA, it would have to establish a "working directory" per
>>    tab rather than UA-wide. No UX issues with that.
>>
>> Agreed. Likely doesn't even need to be specified - it'd just be a "least
> surprise" behavior by the UA.
>
The save to directory case is less easy to handle because it impinges on
overwrite. After some thought, I'd move that to the more difficult UX cases.


> * Since "File > Open" is supported today (via <input type=file>) we must
> be careful about exposing functionality that has similar UX (i.e. a native
> file open dialog) but that implicitly grants extra permissions (e.g. being
> able to modify the file). This points to either additional UX during the
> action, UX when the app wants to write, or a more general permission
> granted to the origin for some scope (file? directory?).
>
I'd think this to be a non formative note on implementation for UAs. The
mechanism of denying an action by the API should be fairly straightforward.


> * Should permissions persist? If you're working in an editor and reload
> the tab, being hit with a flurry of permission prompts is less than ideal.
> But if you visit it again in a day or a year? And, similar to the
> "template" case above, what if you use a web-based editor to modify a file,
> then revisit the site a year later.
>
I don't think long persistence on file-location is a feasible idea. But the
option to choose persistence within a session seems a viable compromise.
You'll still need to click the dialog away once, but then you can work
uninterrupted.