Re: [whatwg] Accessing local files with JavaScript portably and securely

[Yay295]

Maybe a solution then would be to provide a way to request more storage
space?

On Wed, Apr 19, 2017 at 1:35 PM, Joshua Bell  wrote:

> On Wed, Apr 19, 2017 at 8:23 AM, Roger Hågensen 
> wrote:
>
> > On 2017-04-19 11:28, Anne van Kesteren wrote:
> >
> >> I already pointed to https://wicg.github.io/entries-api/ as a way to
> >> get access to a directory of files and  as a way to
> >> get access to a sequence of files. Both for read access. I haven't
> >> seen any interest to go beyond that.
> >>
> >
> > Is this the Filesystem & FileWriter API ?
> >
>
> A small subset of the functionality specified in FileSystem was used by
> Chrome to expose directory upload. Support for that subset necessary for
> interop of directory upload has been implemented by Firefox and Edge. I put
> up the entries-api spec to try and re-specify just that subset. (It's a
> work in progress.)
>
>
> > This was added to Chrome/Opera under the webkit prefix 7 years ago, Edge
> > and Firefox has not picked this up yet (just the Reader part).
> > (as shown by http://caniuse.com/#search=file )
> >
>
> The market apparently demonstrates that a sandboxed file system storage API
> isn't high priority for browser vendors to implement.
>
>
> >
> > I avoid prefixed features, and try to use only features that latest
> > Edge/Chrome/Firefox support so that end users are more likely to not end
> up
> > in a situation where their browser do not support a app.
> >
> > And unless I remember wrong Firefox did support this at some point then
> > removed it again.
> >
> >
> > Take for example my soundbank app.
> >
> > A end user would want to either use a file selector or drag'n'drop to the
> > app (browser) window to add files to the soundboard.
> >
> > Let us assume that 30+ sounds are added (I don't even think the
> > filerequester handles multiselection properly in all browsers today)
> >
> > Would it be fair to expect the user to have to re-add these each time
> they
> > start/open the app? During a week that is a lot of pointless work.
> > Saving filenames is not practical, and even if it was there would be no
> > paths.
> >
> > And storing the sounds in IndexDB or localStorage is out of the question
> > as that is limited to a total of 5MB or even less in most browsers, 30+
> > samples easily consumes that.
> >
>
> You may want to check again. An origin typically gets an order of magnitude
> more storage than that for Indexed DB across browsers and devices.
>
> >
> > The ideal here is to make a html soundboard app locally (i.e file://)
> then
> > copy it as is to a webserver. Users can either use it from there (http://
> > or https:// online and/or offline) or "Save As" the document and use it
> > locally (file://) for preservation or offline use without server
> dependency.
> >
> > The only way to make this work currently is to make the user hand write
> > the path (full or relative) to each sound and store that in localStorage
> > along with volume and fade in/out.
> > But fade in and out is "faked" by adjusting the  volume as CORS
> > prevents processing the audio and doing a proper crossfade between sounds
> > which is possible but locked down due to CORS.
> >
> > I can understand limitations due to security concerns, but arbitrary
> > limitations to functionality baffles me.
> >
> > I do not see much difference between file:// http(s):// besides one
> > allowing serverside data processing and http headers, but these days most
> > apps are entirely clientside. A sample editor can be written that is
> fully
> > clientside, even including mic recording normalizing, FX, the server is
> not
> > involved in any stage except delivering the .html file + a few lines of
> > headers. The web app itself is identical (i.e. hash/checksum identical)
> be
> > it http(s): or file:
> >
> > The benefit is that "the app is the source code" which is a ideal goal of
> > open source as anyone can review and copy and modify as they please.
> > And in theory it could run just as well truly offline/standalone as it
> > could online without the need for a local webserver or similar.
> >
> > I'd dare say that thinking of a web app as something hosted only from a
> > server via http(s) is a antiquated idea.
> > These days a "web" app can be hosted via anything, want to open a webapp
> > that is served from a cloud storage like Dropbox? Not a problem.
> > Well, almost not a problem. a cloud storage probably do not have the
> > proper CORS header to allow a sample editor to process sound from local
> > files or files stored on a different cloud service.
> >
> > And a soundboard or a sample editor is just two examples, a image or
> video
> > edit would have similar issues. OR what about a game with mod support?
> > Being able to drag'n'drop a mod onto a game and then have the game load
> it
> > the next time you start the game would be a huge benefit.
> > But currently this can not be done, the mod would have to be uploaded to
> 

Re: [whatwg] Accessing local files with JavaScript portably and securely

[Joshua Bell]

On Wed, Apr 19, 2017 at 8:23 AM, Roger Hågensen 
wrote:

> On 2017-04-19 11:28, Anne van Kesteren wrote:
>
>> I already pointed to https://wicg.github.io/entries-api/ as a way to
>> get access to a directory of files and  as a way to
>> get access to a sequence of files. Both for read access. I haven't
>> seen any interest to go beyond that.
>>
>
> Is this the Filesystem & FileWriter API ?
>

A small subset of the functionality specified in FileSystem was used by
Chrome to expose directory upload. Support for that subset necessary for
interop of directory upload has been implemented by Firefox and Edge. I put
up the entries-api spec to try and re-specify just that subset. (It's a
work in progress.)


> This was added to Chrome/Opera under the webkit prefix 7 years ago, Edge
> and Firefox has not picked this up yet (just the Reader part).
> (as shown by http://caniuse.com/#search=file )
>

The market apparently demonstrates that a sandboxed file system storage API
isn't high priority for browser vendors to implement.


>
> I avoid prefixed features, and try to use only features that latest
> Edge/Chrome/Firefox support so that end users are more likely to not end up
> in a situation where their browser do not support a app.
>
> And unless I remember wrong Firefox did support this at some point then
> removed it again.
>
>
> Take for example my soundbank app.
>
> A end user would want to either use a file selector or drag'n'drop to the
> app (browser) window to add files to the soundboard.
>
> Let us assume that 30+ sounds are added (I don't even think the
> filerequester handles multiselection properly in all browsers today)
>
> Would it be fair to expect the user to have to re-add these each time they
> start/open the app? During a week that is a lot of pointless work.
> Saving filenames is not practical, and even if it was there would be no
> paths.
>
> And storing the sounds in IndexDB or localStorage is out of the question
> as that is limited to a total of 5MB or even less in most browsers, 30+
> samples easily consumes that.
>

You may want to check again. An origin typically gets an order of magnitude
more storage than that for Indexed DB across browsers and devices.

>
> The ideal here is to make a html soundboard app locally (i.e file://) then
> copy it as is to a webserver. Users can either use it from there (http://
> or https:// online and/or offline) or "Save As" the document and use it
> locally (file://) for preservation or offline use without server dependency.
>
> The only way to make this work currently is to make the user hand write
> the path (full or relative) to each sound and store that in localStorage
> along with volume and fade in/out.
> But fade in and out is "faked" by adjusting the  volume as CORS
> prevents processing the audio and doing a proper crossfade between sounds
> which is possible but locked down due to CORS.
>
> I can understand limitations due to security concerns, but arbitrary
> limitations to functionality baffles me.
>
> I do not see much difference between file:// http(s):// besides one
> allowing serverside data processing and http headers, but these days most
> apps are entirely clientside. A sample editor can be written that is fully
> clientside, even including mic recording normalizing, FX, the server is not
> involved in any stage except delivering the .html file + a few lines of
> headers. The web app itself is identical (i.e. hash/checksum identical) be
> it http(s): or file:
>
> The benefit is that "the app is the source code" which is a ideal goal of
> open source as anyone can review and copy and modify as they please.
> And in theory it could run just as well truly offline/standalone as it
> could online without the need for a local webserver or similar.
>
> I'd dare say that thinking of a web app as something hosted only from a
> server via http(s) is a antiquated idea.
> These days a "web" app can be hosted via anything, want to open a webapp
> that is served from a cloud storage like Dropbox? Not a problem.
> Well, almost not a problem. a cloud storage probably do not have the
> proper CORS header to allow a sample editor to process sound from local
> files or files stored on a different cloud service.
>
> And a soundboard or a sample editor is just two examples, a image or video
> edit would have similar issues. OR what about a game with mod support?
> Being able to drag'n'drop a mod onto a game and then have the game load it
> the next time you start the game would be a huge benefit.
> But currently this can not be done, the mod would have to be uploaded to
> the server the game is served from, even if the game itself does not use or
> need any serverside scripting.
>
> Or imagine a medical app that needs to read in CSV data, such a app could
> work fully offline/local and load up the data each time it's started.
> Storing the data in localstorage/indexDB would be limited to whatever else
> is stored as far as size 

Re: [whatwg] Accessing local files with JavaScript portably and securely

[Roger Hågensen]

On 2017-04-19 11:28, Anne van Kesteren wrote:

I already pointed to https://wicg.github.io/entries-api/ as a way to
get access to a directory of files and  as a way to
get access to a sequence of files. Both for read access. I haven't
seen any interest to go beyond that.


Is this the Filesystem & FileWriter API ?
This was added to Chrome/Opera under the webkit prefix 7 years ago, Edge 
and Firefox has not picked this up yet (just the Reader part).

(as shown by http://caniuse.com/#search=file )

I avoid prefixed features, and try to use only features that latest 
Edge/Chrome/Firefox support so that end users are more likely to not end 
up in a situation where their browser do not support a app.


And unless I remember wrong Firefox did support this at some point then 
removed it again.



Take for example my soundbank app.

A end user would want to either use a file selector or drag'n'drop to 
the app (browser) window to add files to the soundboard.


Let us assume that 30+ sounds are added (I don't even think the 
filerequester handles multiselection properly in all browsers today)


Would it be fair to expect the user to have to re-add these each time 
they start/open the app? During a week that is a lot of pointless work.
Saving filenames is not practical, and even if it was there would be no 
paths.


And storing the sounds in IndexDB or localStorage is out of the question 
as that is limited to a total of 5MB or even less in most browsers, 30+ 
samples easily consumes that.


The ideal here is to make a html soundboard app locally (i.e file://) 
then copy it as is to a webserver. Users can either use it from there 
(http:// or https:// online and/or offline) or "Save As" the document 
and use it locally (file://) for preservation or offline use without 
server dependency.


The only way to make this work currently is to make the user hand write 
the path (full or relative) to each sound and store that in localStorage 
along with volume and fade in/out.
But fade in and out is "faked" by adjusting the  volume as CORS 
prevents processing the audio and doing a proper crossfade between 
sounds which is possible but locked down due to CORS.


I can understand limitations due to security concerns, but arbitrary 
limitations to functionality baffles me.


I do not see much difference between file:// http(s):// besides one 
allowing serverside data processing and http headers, but these days 
most apps are entirely clientside. A sample editor can be written that 
is fully clientside, even including mic recording normalizing, FX, the 
server is not involved in any stage except delivering the .html file + a 
few lines of headers. The web app itself is identical (i.e. 
hash/checksum identical) be it http(s): or file:


The benefit is that "the app is the source code" which is a ideal goal 
of open source as anyone can review and copy and modify as they please.
And in theory it could run just as well truly offline/standalone as it 
could online without the need for a local webserver or similar.


I'd dare say that thinking of a web app as something hosted only from a 
server via http(s) is a antiquated idea.
These days a "web" app can be hosted via anything, want to open a webapp 
that is served from a cloud storage like Dropbox? Not a problem.
Well, almost not a problem. a cloud storage probably do not have the 
proper CORS header to allow a sample editor to process sound from local 
files or files stored on a different cloud service.


And a soundboard or a sample editor is just two examples, a image or 
video edit would have similar issues. OR what about a game with mod 
support? Being able to drag'n'drop a mod onto a game and then have the 
game load it the next time you start the game would be a huge benefit.
But currently this can not be done, the mod would have to be uploaded to 
the server the game is served from, even if the game itself does not use 
or need any serverside scripting.


Or imagine a medical app that needs to read in CSV data, such a app 
could work fully offline/local and load up the data each time it's 
started. Storing the data in localstorage/indexDB would be limited to 
whatever else is stored as far as size goes, and browsers can just wipe 
the local storage/indexDB without warning. At least a local file stored 
on d:\docs\ is safe from vanishing.


Even if the app itself is online and served from a server you still 
can't have it load a list.CSV from d:\docs\ when starting it for 
example. And IndexDB/localStorage is limited to around 5MB total for 
that domain. Maybe there is a desire to switch between datasets 
list1.csv and list2.csv and list3.csv and before you know it you open 
xray.png enhance a area and save that change (in localStorage as you can 
save the path and a zoomvalue you have to save the entire image instead) 
and suddenly list1.csv get deleted from localStorage for that domain. 
And these are limitations to http(s): and not just file:



--
Unless specified 

Re: [whatwg] Accessing local files with JavaScript portably and securely

[duanyao]

在 2017年04月19日 17:28, Anne van Kesteren 写道:

On Wed, Apr 19, 2017 at 11:08 AM, duanyao  wrote:

This is really not intended. I just don't quite understand some of those
points. For example,
Is "the web being fundamentally linked to HTTP" just the current status of
the industry, or
the inherent philosiphy of the web? If the latter, some explanation or
document would be very
appreciated.

I suspect it's actually a little higher-level than HTTP, with that
indeed being the current state, but the web is about the exchange of
data between computers and definitely sits at a higher level of
abstraction than the particulars of the Linux or Windows file system.
It's hard to define concretely I think, but being platform-independent
and having data addressable from anywhere are important principles.


It's quite helpful, thanks.
If "addressable from anywhere" is a hard requirement then file: url is 
doomed with the web,
and further discussion would be unnecessary. Though 
platform-independency could be achieved technically.





Doesn't file: protocol also abstract away much of the file system? What
parts make it a bad abstraction?
You mentioned casing and unicode normalization.

File URLs (it's not a protocol really) are still fundamentally tied to
the file system, including how it's hierarchical and such. And then
indeed there's all the legacy implications of file URLs.



I'm not particularly eager to write access myself. Maybe we can seperately
discuss read and write cases.

I already pointed to https://wicg.github.io/entries-api/ as a way to
get access to a directory of files and  as a way to
get access to a sequence of files. Both for read access. I haven't
seen any interest to go beyond that.


Well, I meant accessing local files from local files without user 
actions (e.g. XHR/fetch), mainly used


to load a web app's own assets.

Re: [whatwg] Accessing local files with JavaScript portably and securely

[Anne van Kesteren]

On Wed, Apr 19, 2017 at 11:08 AM, duanyao  wrote:
> This is really not intended. I just don't quite understand some of those
> points. For example,
> Is "the web being fundamentally linked to HTTP" just the current status of
> the industry, or
> the inherent philosiphy of the web? If the latter, some explanation or
> document would be very
> appreciated.

I suspect it's actually a little higher-level than HTTP, with that
indeed being the current state, but the web is about the exchange of
data between computers and definitely sits at a higher level of
abstraction than the particulars of the Linux or Windows file system.
It's hard to define concretely I think, but being platform-independent
and having data addressable from anywhere are important principles.


> Doesn't file: protocol also abstract away much of the file system? What
> parts make it a bad abstraction?
> You mentioned casing and unicode normalization.

File URLs (it's not a protocol really) are still fundamentally tied to
the file system, including how it's hierarchical and such. And then
indeed there's all the legacy implications of file URLs.


> I'm not particularly eager to write access myself. Maybe we can seperately
> discuss read and write cases.

I already pointed to https://wicg.github.io/entries-api/ as a way to
get access to a directory of files and  as a way to
get access to a sequence of files. Both for read access. I haven't
seen any interest to go beyond that.


-- 
https://annevankesteren.nl/

Re: [whatwg] Accessing local files with JavaScript portably and securely

[duanyao]

在 2017年04月19日 16:09, Anne van Kesteren 写道:

On Wed, Apr 19, 2017 at 5:45 AM, duanyao  wrote:

These have been a lot of discussion on that in this thread. Do you think 
writing a more formal document would be helpful?

Perhaps. Fundamentally, I don't think you've made a compelling enough
case for folks to become interested and wanting to work in this space
and help you solve your problem. You've also have been fairly
dismissive of the alternative points of view, such as the web being
fundamentally linked to HTTP and that distributing (offline)
applications over HTTP is the goal. That might make folks less
compelled to engage with you.


I'm sorry to make you feel that I have been dismissive of the 
alternative points of view.
This is really not intended. I just don't quite understand some of those 
points. For example,
Is "the web being fundamentally linked to HTTP" just the current status 
of the industry, or
the inherent philosiphy of the web? If the latter, some explanation or 
document would be very

appreciated.



I suspect no browser, and I'm pretty certain about Mozilla since I
work there, is interested in furthering file URLs.


It is very helpful to hear clear a signals from browser vendors, 
positive or not. Thanks.



Most new operating
systems abstract away the file system and the web as browsers see it
has always done that. There's ways to pull files in, but there's not
much use for letting applications write them out again (other than
downloads, which are quite a bit different).




Doesn't file: protocol also abstract away much of the file system? What 
parts make it a bad abstraction?

You mentioned casing and unicode normalization.

I'm not particularly eager to write access myself. Maybe we can 
seperately discuss read and write cases.

Re: [whatwg] Accessing local files with JavaScript portably and securely

[Anne van Kesteren]

On Wed, Apr 19, 2017 at 5:45 AM, duanyao  wrote:
> These have been a lot of discussion on that in this thread. Do you think 
> writing a more formal document would be helpful?

Perhaps. Fundamentally, I don't think you've made a compelling enough
case for folks to become interested and wanting to work in this space
and help you solve your problem. You've also have been fairly
dismissive of the alternative points of view, such as the web being
fundamentally linked to HTTP and that distributing (offline)
applications over HTTP is the goal. That might make folks less
compelled to engage with you.

I suspect no browser, and I'm pretty certain about Mozilla since I
work there, is interested in furthering file URLs. Most new operating
systems abstract away the file system and the web as browsers see it
has always done that. There's ways to pull files in, but there's not
much use for letting applications write them out again (other than
downloads, which are quite a bit different).


-- 
https://annevankesteren.nl/